[Top] [All Lists]

Re: XFS write cache flush policy

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS write cache flush policy
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Thu, 20 Dec 2012 02:40:14 +0100
Cc: Lin Li <sdeber@xxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20121219224328.GN15182@dastard>
References: <20121215221622.GF9806@dastard> <20121216103025.GA14880@xxxxxxx> <20121216111046.GA16756@xxxxxxx> <20121216204847.GN9806@dastard> <20121216232251.GA20370@xxxxxxx> <20121217232441.GA5031@dastard> <20121218003438.GB30736@xxxxxxx> <20121218202914.GC15182@dastard> <20121219010445.GA24313@xxxxxxx> <20121219224328.GN15182@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On 20.12.2012 09:43, Dave Chinner wrote:
> On Wed, Dec 19, 2012 at 02:04:45AM +0100, Matthias Schniedermeyer wrote:
> > At least i'd count a dropped connection or power failure (The only 
> > difference is that in the latter case the cache MAY get dropped, 
> > otherwise i'd say both cases are basically the same) among the basic 
> > functionality that should be assured by a journaling fileystem.
> A journalling filesystem doesn't guarantee that you won't lose any
> data on crash, power fail or permanent IO errors. All journalling
> guarantees is that the filesystem is *consistent* after recovery.
> i.e. you don't have to run xfs_repair after such a failure to
> ensure it is not corrupted. In all your testing, you have not seen
> the filesystem become corrupted, so the journalling has fulfilled
> it's guarantee.

I know that the basic property of the Journaling is to prevent 
corruption of the metadata, IOW to prevent exessive time to check fs 
after for e.g. a power-failure.

I'm not arguing that a Journaling FS can't loose any data, only that it 
stays "within reason". I think you can agree that hunderds of files 
containing hundreds of gigabytes of data is well outside "reasonable 
looses". It doesn't have to be a pony or unicorn, but it should at least 
be a mule. :-)

Overall i'm quite satisfied with the performance of XFS over the years, 
otherwise it wouldn't be the filesystem for over 99.999% of all the 
storage capacity i have. The only thing for which i don't use XFS are 
"/boot"-partitions, which amount to a few hundreds of MB, whereas XFS 
accounts for well over 100TB.

About corruptions: I haven't had any corruption in my dozens of tests, 
BUT once my metdadata got corrupted by this bug! (Or mayby the 
umount-thing that you meantioned)

It was the first time ever that i had to use xfs_repair (XFS refused to 
mount the fs) and i have been using XFS pretty much since it got ported 
to Linux.

I "lost" a few files that i had to recover from my last backup (i didn't 
bother to look through lost+found). Which luckily i made just minutes 
before rebooting the machine in question. I had thought about issuing a 
'sync', because the previous incarnation of the bug flashed before my 
inner eye. But by the time i had shutdown X and got to the 
command-prompt i had already forgotten to type 'sync' and went straight 
for 'reboot' and was slightly irritated when my machine did finished 
booting correctly, because a secondary-filesystem was MIA. (The 
root-filesystem was OK, but my /home was MIA)

The most "pain" i can remeber before this episode was the 0-fill 
"thing", which bit me at least once. Other than that it's been smooth 
sailing all these years.

I other words: Overall it's still very good work and i will rely on XFS 
for the forseable future.



<Prev in Thread] Current Thread [Next in Thread>