XFS In Dapper [previously posted to ubuntu-users]

Nick Webb nick at freelock.com
Thu Mar 6 15:43:33 UTC 2008


Daniel Pittman wrote:
> Michael Hipp <Michael at Hipp.com> writes:
>> David Kempe wrote:
>>> Nick Webb wrote:
>>>> I've got a couple projects coming up that will have a file systems >= 
>>>> 2TB and I'm thinking of using XFS for it.  Main feature of XFS I need is 
>>>> the lack of fsck at startup (fsck for ext2/3 will take many hours with a 
>>>> 2TB partition).  
> 
> Er, that fsck is for the sake of safety and can be disabled; feel free
> to do so and take the same risks that XFS exposes you to.  If that is
> your /only/ reason for preferring XFS then worry no more.
> 
> (See tune2fs for details; set the mount count and time for fsck to off)

Thanks for the very informed reply, Daniel.

I know I can do this, and I've actually done it in a few places with the 
idea that "someday" I'll fsck them when then can be down for hours. 
These systems have filesystems <= 1TB which is painful enough, but 
basically just inconvenient.

What is your experience with just not fscking ext3?  Is it safe to never 
do so unless you have hard crash (kernel panic, etc.)?

> 
>>>> The file system will also likely have many large files, so XFS seems
>>>> to be a good choice for this as well.
> 
> The benefits may be more mixed than you expect, unless you need good
> streaming write performance for those files.
> 

OK I've got mixed needs on different servers.  Some are more generic and 
other than the sheer size of the volumes I wouldn't hesitate to use 
ext3.  Sounds like sticking with ext3 for these volumes isn't a bad idea?

I have a few projects where the filesystem will store raw images and 
video, so XFS might have the leg up there.  However, so far there is no 
requirement to stream anything...

Where would you use XFS over ext3?

>>> Importantly, you can have data-loss on XFS if you lose power suddenly, 
>>> perhaps more so than ext3. When files get corrupted on XFS, I have 
>>> noticed they go to zero size, 
> 
> That is very odd.  XFS, up until the version in 2.6.24 (the Hardy
> kernel) had a combination of choices about security and performance that
> would result in file content replaced by NULL in some cases.[1]
> 
> None of these would result in "zero size" files.
> 
>>> whereas in messy situations with ext3 I have noticed you are more
>>> likely to loose metadata than data. I still would stick with XFS
>>> anyday though, even just because the sheer increase in format time.
> 
> Heh.  Formatting 1.4TB of ext3 today was certainly an exercise in
> patience. :)
> 
>> I've experienced this data loss on XFS more than once due to one kind
>> of abrupt shutdown or another. XFS seems fragile. Almost like it's not
>> a journaled filesystem at all.
> 
> I wouldn't use XFS on a machine where power loss was possible before
> 2.6.24, but wouldn't hesitate to recommend it at or after that point.
> 
> (In other words: not for a month or so, and not unless you want to run
>  the new software the first day.)
> 
>> XFS has several advantages over ext3. But I abandoned it because of
>> this fragility. Ext3 seems far more idiot proof and I prefer things
>> that "just work" even if they're not glamorous.
> 
> I agree: for a long time I wouldn't use XFS for much the same reason. 
> 
> The applications that fail are poorly written and will lose or corrupt
> data in plenty of other circumstances, sure[2], but I would rather cope
> than lose data I care about.[3]
> 
> Thankfully that has been changed by the upstream XFS team, so I am much
> happier now.
> 
> Regards,
>         Daniel
> 
> Footnotes: 
> [1]  These are poorly written applications; the situation was that
>      truncate would record the size change but not flush data to disk,
>      risking data exposure, resulting in the security decision to expose
>      only NULL bytes to the user.[4]
> 
> [2]  Hi, older sendmail, I am looking at your map utilities indeed.
> 
> [3]  Well, I actually keep data I care about well away from them, but
>      enough of them are convenient that...
> 
> [4]  ext3 made the opposite choice: to risk exposing potentially
>      security related (or otherwise undesirable) content in a file that
>      was treated that way, in return for preserving whatever content was
>      written successfully.
> 




More information about the ubuntu-server mailing list