[clug] EXT4 Reliability

Anshul Gupta email.agupta at gmail.com
Tue Sep 29 18:19:01 MDT 2009


On 30/09/2009, at 12:24 AM, Daniel Pittman wrote:

> Anshul Gupta <email.agupta at gmail.com> writes:
>
>> Performance wise ext4 filesystem is better because of extents and  
>> persistent
>> preallocation which improves performance slightly. Somebody might  
>> argue it's
>> better for movie files because of contiguous allocation and will  
>> wear the
>> disk less thereby reduce the risk of disk failure.
>
> Anybody who argued that would, rightly, be looked at very strangely;  
> the
> difference that makes in practice is zero, for all practical purposes.
>
> Extents do make access to large data less seek-heavy, though, which  
> can be
> a significant performance advantage.

I guess for the difference to be visible you have to simulate  
simultaneous write of several files using CFQ on ext3 and ext4 file  
system and see how contiguous large files look on ext4 using some disk  
visualizer. The power of extents come from single allocation of up to  
128M and not wasting time managing and looking up block allocation in  
triple indirect block maps for large files. Also the argument above  
will be valid for heavily fragmented filesystems which can cause the  
disk to wear faster.

>
>> However I prefer ext3 just because it has been around for many  
>> years and
>> it's rock solid. Ext4 is still new. Also ext4 filesystem are not as  
>> reliable
>> due to delayed allocation.
>
> That is a poorly supported statement.  I presume you mean that ext4  
> has
> a higher risk of data loss in the event of a catastrophic system  
> failure, when
> faced with incompetently written software.

Not because of the software but because of ext4 code. Under ext3 you  
will have either the old version of the file or new; using ext4 you  
might have none in the above situation unless the app forces fsync()  
after writes.

>
> (Which, sadly, apparently /still/ includes both GNOME and KDE, since  
> both love
> to rewrite their configuration files all too often.  Oh, well.   
> Maybe that
> got fixed since ext4 made it visible again.)
>
> Anyway, by the time you are having the system hang, panic, or facing  
> power
> failures you have more or less already lost in the data integrity  
> stakes;
> using ext3 helps, in the same way that stabbing yourself with a  
> *short* skewer
> is better than stabbing yourself with a long skewer.
>
>> Also if ext3 disk fails you will find many tools to recover data.
>
> What, debugfs and e2fsck, which also work for ext3 and ext4?  I  
> don't think
> you will find substantially changed recovery tools for ext4, generally
> speaking.
>
All tools will need ext4 extensions to understand and debug ext4  
filesystem structure. ext3->ext4 update is more then just adding a  
journal to ext2. The last time I used fsck.ext4dev on ext4dev  
filesystem, it corrupted the filesystem beyond repair (turned all  
directories into symlinks pointing to other symlinks pointing  
nowhere). For a backup disk you want proven filesystem and tools.

>> That being said, for your important data you should always use some  
>> sort of
>> RAID.
>
> This doesn't protect you from several of the failure modes of ext4,  
> and can
> make things significantly worse by exposing you to additional  
> complexity, and
> additional sources of failure.

I was merely suggesting Ian to use redundant disks and not rely  
entirely on single copy for important data. You are assuming that I am  
referring to software RAID. Even using software RAID additional  
complexity is worth the protection.

>
>> And you can always migrate ext3 filesystem to ext4 in future.
>
> ...this loses many of the performance benefits, however.

After the migration the old structures will not be rewritten but the  
new data will use the new data structures. Also you can rewrite the  
old data using new structures if you want.

>
>> FAT32 is the most portable filesystem but not as stable and  
>> reliable as
>> ext[34].
>
> I am surprised you suggest this.  Are you referring to the issues  
> that the FAT
> structure introduces WRT the Unix [id]node convention, or the  
> renaming issues,
> or something else?
>
FAT is good as multi-os filesystem but not very good with large files  
and certainly the last option when you are choosing Linux native  
filesystems. I have used FAT as backup filesystem for backup in the  
past and I won't recommend it to anyone. Inefficient access, file size  
limitation, fragmentation, file corruption, locking etc are just a few  
issues.

>> And using FAT32 filesystem you might not be able to import directly  
>> on the
>> USB disk as the write speed will be limited by the filesystem. NTFS  
>> for
>> Linux host doesn't make sense.
>
> This I agree with.
>
>
> Anyway, personally, if I wanted something faster than ext3 I would  
> look to XFS
> which has a much longer history and much better understood failure  
> modes than
> the relatively new ext4 — regardless that I have nothing but the  
> highest
> respect for the approach, implementation and design of ext4 or its  
> maintainers.
>
> For a backup disk, though, favouring robustness over performance  
> generally
> makes sense, so I would likely choose ext3.
>

Hence we come to the same conclusion.

>        Daniel
>
> Well, I actually chose XFS, but my backup model is quite different  
> from the
> one being discussed; external disks just land an xfsdump of the  
> filesystem
> snapshot at a suitable time.
>
> -- 
> ✣ Daniel Pittman            ✉ daniel at rimspace.net> +61 401 155 707
>               ♽ made with 100 percent post-consumer electrons
>   Looking for work?  Love Perl?  In Melbourne, Australia?  We are  
> hiring.
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux



More information about the linux mailing list