xfs
[Top] [All Lists]

Re: XFS write cache flush policy

To: Ric Wheeler <rwheeler@xxxxxxxxxx>
Subject: Re: XFS write cache flush policy
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Fri, 14 Dec 2012 17:19:35 +0100
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Lin Li <sdeber@xxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <50CB3037.90003@xxxxxxxxxx>
References: <CAA_rkDfFUmZzT_kMznsTSNVxdfqfmz=bmJ400wdBOzocgP32eA@xxxxxxxxxxxxxx> <20121208192927.GA17875@xxxxxxx> <20121210005820.GG15784@dastard> <20121210091239.GA21114@xxxxxxx> <50C64C17.9080206@xxxxxxxxxxx> <20121214111924.GA4762@xxxxxxx> <50CB3037.90003@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On 14.12.2012 13:57, Ric Wheeler wrote:
> On 12/14/2012 11:19 AM, Matthias Schniedermeyer wrote:
> >>>>http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> >>>>
> >>>>Basically, you have an IO error situation, and you have dm-crypt
> >>>>in-between buffering an unknown about of changes. In my experience,
> >>>>data loss eventsi are rarely filesystem problems when USB drives or
> >>>>dm-crypt is involved...
> >>>I don't know the inner workings auf dm-*, but shouldn't it behave
> >>>transparent and rely on the block-layer for buffering.
> >>I think that's partly why Dave asked you to test it, to check
> >>that theory ;)
> >To test that theory.
> >
> >Technically this is an other machine than the original but i tried to
> >recreate as much from the original cirumstances as possible.
> >Kernel is 3.6.7
> >
> >First i recreated the circumstances.
> >I plugged a HDD i'm throwing out into the enclosure that was the most
> >problematic, created the dm-crypt-layer & filesystem as reported and
> >started copying.
> >
> >In all testes i didn't supply any mount-options!
> >
> >1)
> >After a few minutes i "emulated" the problem by unplugging the cable.
> >At that point about 40 files were copied, but only 25 where there after
> >i replugged the cable.
> 
> Just a note - depending on the drive and its firmware, unplugging a
> cable is *not* the same as a power loss since the firmware detects
> the loss of link and immediately writes back any volatile cache data
> to platter (and it has power, so that is easy for it to do :)).
> 
> You really should drop power to the enclosure to get a "mean" test :)

The Power loss case is irrelevant for me.

I know what i can expect for a power-loss, all my drives have 
'write-cache on' and (up to) 64MB of cache. As a disabled write cache 
isn't an option (performance sucks) the ensuing data-loss would be 
expected and there are procedures in place to prevent any permanent 
data-losses (Except for the right 2 discs dying at the same time).






-- 

Matthias

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