Re: [RFC] relaxed barrier semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 27, 2010 at 07:54:19PM +0200, Jan Kara wrote:
>   OK, let me understand one thing. So the storage arrays have some caches
> and queues of requests and QUEUE_ORDERED_DRAIN forces them flush all this
> to the platter, right?

Not quite.  QUEUE_ORDERED_DRAIN does not interact with the target at
all, it's entirely initiator (Linux) side.  What it does it to make
sure we drain the whole queue in the I/O scheduler (elevator) and in
flight to the device (command queueing) by waiting for all I/O before
the barrier to finish, the issue the barrier command and only then
allow any newly arriving requests to proceed.

>   So can it happen that they somehow lose the requests that were already
> issued to them (e.g. because of power failure)?

We can lose the requests already on the wire, but not completed yet.
That's why log write wait for all preceding log writes (or things like
the I/Os required to push the tail) and fsync waits for all I/O
completions manually.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux