| From | Subject | Date |
|---|---|---|
| Eric Sandeen | Re: e2fsck doesn't repair broken ext4
I'm sorry, I haven't made further progress on this yet.
--
| Apr 16, 8:22 am 2010 |
| Jörg Sommer | Re: e2fsck doesn't repair broken ext4
Hi,
I would like to ask, if there was any result from this issue? Did you
found a bug in e2fsck?
Bye, Jörg.
--
< Mr X.> jo: contact an admin to mount it for you
< jo> The admin is not, well how should I say it, he isn't very familiar with
the system. What should I tell my admin, what he should do?
< Mr X.> taking a sun solaris administration course.
| Apr 16, 3:11 am 2010 |
| Eric Sandeen | Re: quota reservation fixes for -stable?
Hm, I see this in your tree now, but isn't __DQUOT_PARANOIA defined by
default anyway?
fs/quota/dquot.c:
1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 83)#define
__DQUOT_PARANOIA
-Eric
--
| Apr 16, 1:37 pm 2010 |
| bugzilla-daemon | [Bug 15768] Incorrectly calculated free blocks result in ...
https://bugzilla.kernel.org/show_bug.cgi?id=15768
Rafael J. Wysocki <rjw@sisk.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rjw@sisk.pl
Blocks| |15310
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching ...
| Apr 16, 2:44 pm 2010 |
| tytso | Re: [PATCH 2/2] ext4: fix inode bitmaps manipulation in ...
Here's my -V3 respin of this patch, which further cleans up the code
and removes some duplicated code by only calling ext4_clear_bit() from
one call site.
I think I'm about done for this, so if you agree with my improvements
as improvements, it might be useful to port this back to ext3 version
of this patch.
- Ted
ext4: clean up inode bitmaps manipulation in ext4_free_inode
From: Dmitry Monakhov <dmonakhov@openvz.org>
- Reorganize locking scheme to batch two atomic operation in ...
| Apr 15, 6:06 pm 2010 |
| tytso | Re: ext34_free_inode's mess
Agreed. The reason you're seeing me respin this patch a few times is
because we recently added some additional qualification testing for
ext4 in $DAYJOB, and we've found that running dbench followed by fsck
-fy also seems to be a good way of tickling this bug --- and applying
the patch which you wrote does seem to make it go away.
Like you, I can't reproduce the problem once the patch has been
applied; and like you and Jan, I can't see how this patch would
actually fix a race or some other ...
| Apr 16, 6:33 am 2010 |
| Andre Noll | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
Yes, that does not result in any errors.
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
| Apr 16, 8:57 am 2010 |
| Andre Noll | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
Yes, or a problem with the qla2xxx driver. However, it's a bit
surprising that the hardware survived the stress test for more than
one day and went south just at the moment the fs was completely filled.
My first guess was that the problem might be caused by a reported
device size which is slightly larger than the actual size. But then
ddrescue -i 7440Gi /dev/zero /dev/sda
would have resulted in a similar error. This command completed without
errors though.
Thanks
Andre
--
The only ...
| Apr 16, 8:30 am 2010 |
| tytso | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
These look like hardware errors; it may not be the qla2xxx driver's
fault, but actually the fault of the hard disk....
- Ted
--
| Apr 16, 7:29 am 2010 |
| Andre Noll | ext4: (2.6.34-rc4): This should not happen!! Data will ...
Hi
I'm seeing the following errors when writing to an ext4 file system:
qla2xxx 0000:06:09.0: scsi(0:0:0): Abort command issued -- 1 fa6a73 2002.
end_request: I/O error, dev sda, sector 7812771880
Aborting journal on device sda-8.
EXT4-fs (sda): delayed block allocation failed for inode 752 at logical offset 1982464 with max blocks 17588 with error -30
This should not happen!! Data will be lost
EXT4-fs error (device sda) in ext4_da_writepages: Journal has aborted
EXT4-fs error ...
| Apr 16, 5:35 am 2010 |
| Eric Sandeen | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
ext4 is just the messenger here, I think.
--
| Apr 16, 8:02 am 2010 |
| Eric Sandeen | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
Hm, that's true.
Well, the error was on sector 7812771880 of the device ...
can you reliably write directly to that sector w/o the filesystem in
between?
--
| Apr 16, 8:43 am 2010 |
| Andrew Vasquez | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
The driver here is simply reporting that the a command's timeout value
had been exceeded and the mid-layer began error-recovery with a request
to 'abort' the command. The abort-request completed successfully:
qla2xxx 0000:06:09.0: scsi(0:0:0): Abort command issued -- 1 fa6a73 2002.
I can't explain why the storage did not complete the request in the
allotted time.
-- av
--
| Apr 16, 8:52 am 2010 |
| Andre Noll | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
Ah, that's valuable information, thanks. The underlying Infortrend
Raid System is rather old but worked without any problems for several
years. We recently replaced its 400G disks by new 2T WD disks. Maybe
the new disks have longer response times, could that be the reason? And
is there a way to increase the timeout value?
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
| Apr 16, 9:08 am 2010 |
| Andrew Vasquez | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
To update the default timeout value (30 seconds) for commands
submitted to /dev/sdn to 60 seconds:
$ echo 60 > /sys/block/sdn/device/timeout
-- av
--
| Apr 16, 9:36 am 2010 |
| Andre Noll | Re: ext4: (2.6.34-rc4): This should not happen!! Data w ...
I will re-run the stress test with a 60 seconds timeout value and follow
up if this did not help.
Thanks again
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe
| Apr 16, 10:07 am 2010 |
| Western Union Fore ... | Be Officially Inform(Final Notification)
This is the second email am sending youin the past two weeks, if you
get this i one, I write to inform you that we have already sent you
$5000.00USD dollars through Western Union as we have been given the
mandate to transfer your full compensation payment of $800,000.00USD
via Western Union by this government.
So, I decided to email you the MTCN and sender name, so you can pick up
this $5000.00USD to enable us send another $5000.00USD by tomorrow as
you know we will be sending you
--
| Apr 16, 8:17 am 2010 |
| previous day | today | next day |
|---|---|---|
| April 15, 2010 | April 16, 2010 | April 17, 2010 |
