# [EXT4] Filesystem bug?

## hadogenes

Hi,

I have a problem: I had a clean system (right after install) and because of one of my config files I had to restart my computer manually (by pressing power on button for 5 sec, and turn it on - I have a laptop) and after my system turn on  I had corrupted filesystem (whole etc folder has disappeared and a lot of files from various folders). I tried to run e2fsck but it didn't work (it only found some problems, but it didn't fixed it correctly).

I have tried install system two times, but with the same effect.

Hadogenes

----------

## NeddySeagoon

hadogenes,

Thats what backups are for.

ext4 is not ready for everyday use yet. I remember the introduction of ext3, that took a year or two to settle down.

There will be bugs to be found in ext4 yet.

----------

## hadogenes

Ok, but I supposed that ext4 has basic protection.

----------

## saellaven

I switched a few non-critical partitions over to ext4 as a testing measure back in December when it first went stable, including /usr/portage. Turns out there was a race condition that was causing corruption similar to yours. I reported it and, in fact, there was already a patch fixing it when I had done so. Those patches just finally made it into the official kernel (I've been running a self patched kernel in the meantime). I haven't hit any other bugs, though some others have and still are.

At this point, ext4 seems stable for non-critical stuff that you can replicate easily (like the portage directory, where I've seen a massive speed improvement over ext3), but I'm not quite ready to trust my important data with it yet. I seem to remember waiting about 6 months before I fully switched from ext2 to ext3 and I'll probably do the same again this time.

----------

## NeddySeagoon

hadogenes,

No filesystem has protection against 'dirty' shutdowns.  That is, being unmounted without the data in RAM being flushed to disk.

Normally the higher performance the filesystem, the longer the period between syncs to disk and the more information only in RAM.

Consequently, more is lost.

If your data survives a 'dirty' shutdown, its pure luck. fsck only makes sure the metadata is self consistant, it says nothing about your data in the filesystem. Thats true of all filesystems.

----------

## KarolisL

I think, next time You should try to umount the filesystem first via SysRq calls (Alt+SysRQ+S[ync]&&U[mount]&&[re]B[oot]).  :Smile: 

----------

## szczerb

 *KarolisL wrote:*   

> I think, next time You should try to umount the filesystem first via SysRq calls (Alt+SysRQ+S[ync]&&U[mount]&&[re]B[oot]). 

 Do I need to enable anything in the kernel for this to work?

----------

## pdw_hu

 *szczerb wrote:*   

>  *KarolisL wrote:*   I think, next time You should try to umount the filesystem first via SysRq calls (Alt+SysRQ+S[ync]&&U[mount]&&[re]B[oot]). :-) Do I need to enable anything in the kernel for this to work?

 

"Magic SysRq Key" under Kernel Hacking.

----------

## mv

 *NeddySeagoon wrote:*   

> No filesystem has protection against 'dirty' shutdowns. If your data survives a 'dirty' shutdown, its pure luck.

 

I had argued similarly before ext4 was released. But since ext4 finally has journal checksums (and barriers enabled by default without which the whole journaling idea was plain nonsense), it shouldn't really be possible anymore to loose any existing files (or even a whole previously existing directory) unless there is a bug in the filesystem code itself. Of course you can loose modifications of files since the last flush (and since ext4 AFAIK still has no atomic operations certain inconsistencies might occur), but this is not surprising. Losing the whole /etc directory (unless it was only created during the session) certainly means a bug in the filesystem code.

----------

## ok

There is a bug report for ubuntu (Ext4 data loss): https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781

----------

