Re: [RFC] relaxed barrier semantics

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

 



Jan Kara, on 07/31/2010 04:47 AM wrote:
On Fri 30-07-10 16:20:25, Christoph Hellwig wrote:
On Fri, Jul 30, 2010 at 05:44:08PM +0400, Vladislav Bolkhovitin wrote:
Yes, but why not to make step further and allow to completely eliminate
the waiting/draining using ORDERED requests? Current advanced storage
hardware allows that.

There is a few caes where we could do that - the fsync without metadata
changes above would be the prime example.  But there's a lot lower
hanging fruit until we get to the point where it's worth trying.
   Umm, I don't understand you. I think that fsync in particular is an
example where you have to wait and issue cache flush if the drive has
volatile write cache. Otherwise you cannot promise to the user data will be
really on disk in case of crash. So no ordering helps you.

Isn't there the second wait for journal update?

   And if you are speaking about a drive without volatile write caches, then
fsync without metadata changes is just trivial and you don't need any
ordering.

A drive can reorder queued SIMPLE requests at any time doesn't matter if it has volatile write caches or not. So, if you expect in-order requests execution (with journal updates you do?), you need to enforce that order either by ORDERED requests or (local) queue draining.

Vlad
--
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