I lost 15G from ext4 fsck failures tonight!

I lost 15G from ext4 fsck failures tonight!

[ed1989]

I moved some data off of a 115G ext4 filesystem on an LVM logical volume. 
Then I resized the ext4 filesystem.  Unfortunately, 15G of the remaining 95G
in data was lost to /lost+found due to repeated fsck errors.

I have also had the problem of ext4 destroying my kde4 configuration files
so that my kde4 desktop would revert back to the defaults occasionally.

I don't see what the benefit of ext4 really is, when data loss doesn't seem
to be a concern among ext4 developers.  I would expect that data loss should
be the primary concern.

I am most likely going to move back to ext3 or else to some other stable
filesystem like xfs.
-- 
View this message in context: http://www.nabble.com/I-lost-15G-from-ext4-fsck-failures-tonight%21-tp23774225p23774225.html
Sent from the linux-ext4 mailing list archive at Nabble.com.

Re: I lost 15G from ext4 fsck failures tonight!

[Christian Kujau]

On Thu, 28 May 2009, ed1989 wrote:
> I moved some data off of a 115G ext4 filesystem on an LVM logical volume. 
> Then I resized the ext4 filesystem.  Unfortunately, 15G of the remaining 95G
> in data was lost to /lost+found due to repeated fsck errors.

Did you run fsck (which version?) before or after the resizing process? 
IIRC resize2fs recommends running e2fsck before doing anything. Do you 
have a log of the errors reported by e2fsck? Also, were there any errors 
in your syslog (i.e. /var/log/messages, dmesg, etc.)
 
> I have also had the problem of ext4 destroying my kde4 configuration files
> so that my kde4 desktop would revert back to the defaults occasionally.

This has been discussed on this list (and elsewhere) before, in short: 
it's not really ext4 destroying but more like kde4 not really writing its 
configuration files. But this is an oversimplified version of the real 
issues, please search the archives for details.

> I am most likely going to move back to ext3 or else to some other stable
> filesystem like xfs.

Out of curiosity: why did you switch to ext4?

Christian.
-- 
BOFH excuse #310:

asynchronous inode failure

Re: I lost 15G from ext4 fsck failures tonight!

[Theodore Tso]

On Thu, May 28, 2009 at 09:55:42PM -0700, ed1989 wrote:
> 
> I moved some data off of a 115G ext4 filesystem on an LVM logical volume. 
> Then I resized the ext4 filesystem.  Unfortunately, 15G of the remaining 95G
> in data was lost to /lost+found due to repeated fsck errors.

What version of e2fsprogs and the kernel are you using?  Can you give
us details about what filesystem corruptions was reported by fsck?
Also, did the system crash, or did you reboot, between the resize and
when fsck showed errors?  Was there anything in the system logs?

Note that the data is not lost if the files are moved to /lost+found.
This happens when a containing directory has been destroyed or
corrupted.  But the files in the directory are still there; they've
just been moved to the lost+found directory.  Asssociating the names
with the inode numbers can be tricky --- although for directories that
get moved to lost+found, usually you can use the locatedb to figure
out the name of the parent directory.  (i.e., if the directory
contains files "bash", "ls", "rm", then the name of the directory was
likely "/bin"; if the directory contains file such as "motd",
"passwd", and "resolv.conf", then it it's likely that the directory
was originally named "/etc"; the locatedb can be used to figure this
out).  For other files, you'll have to figure out by using the "file"
command to determine the file type, and then looking at in-band data
(for example, the ID3 information in mp3 file).

> I have also had the problem of ext4 destroying my kde4 configuration files
> so that my kde4 desktop would revert back to the defaults occasionally.
> 
> I don't see what the benefit of ext4 really is, when data loss doesn't seem
> to be a concern among ext4 developers.  I would expect that data loss should
> be the primary concern.

A hueristic to work around bugs in KDE has been introduced in 2.6.29;
you may not know this, but I created the workaround because I know it
would take a long time to fix the broken applications, *before* I
started advocating that application programmers fix their broken
programs.  These workarounds were backported to both the Fedora 11 and
Ubuntu Jaunty kernels.  I don't know what version of the kernel you
are using, but I'm guessing it must be an older one.  In any case, I
care very much about data loss; that's why I *both* implemented a
workaround, *and* advocated that application programmers fix their
buggy programs.

But if you want to go back to ext3, or use some other filesystem,
please feel free.  It's all about free choice, after all.

Regards,

						- Ted