On Tue, 2008-10-21 at 18:18 -0400, Ric Wheeler wrote: > Eric Anopolsky wrote: > > On Tue, 2008-10-21 at 09:59 -0400, Chris Mason wrote: > > > >>> - power loss at any time must not corrupt the fs (atomic fs > >>> modification) > >>> (new-data loss is acceptable) > >>> > >> Done. Btrfs already uses barriers as required for sata drives. > >> > > > > Aren't there situations in which write barriers don't do what they're > > supposed to do? > > > > Cheers, > > Eric > > > > > If the drive effectively "lies" to you about flushing the write cache, > you might have an issue. I have not seen that first hand with recent > disk drives (and I have seen a lot :-))
That does not match the understanding I get from reading the notes/caveats section of Documentation/block/barrier.txt: "Note that block drivers must not requeue preceding requests while completing latter requests in an ordered sequence. Currently, no error checking is done against this." and perhaps more importantly: "[a technical scenario involving disk writes] The problem here is that the barrier request is *supposed* to indicate that filesystem update requests [2] and [3] made it safely to the physical medium and, if the machine crashes after the barrier is written, filesystem recovery code can depend on that. Sadly, that isn't true in this case anymore. IOW, the success of a I/O barrier should also be dependent on success of some of the preceding requests, where only upper layer (filesystem) knows what 'some' is. This can be solved by implementing a way to tell the block layer which requests affect the success of the following barrier request and making lower lever drivers to resume operation on error only after block layer tells it to do so. As the probability of this happening is very low and the drive should be faulty, implementing the fix is probably an overkill. But, still, it's there." Cheers, Eric
signature.asc
Description: This is a digitally signed message part
