Re: munmap, msync: synchronization

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

 



On Mon, Apr 21, 2014 at 11:14:31AM -0700, Christoph Hellwig wrote:
> > 6. On Linux, MS_ASYNC is also a no-op. That's fine on a unified 
> >    cache system. Filesystem I/O always sees a consistent view,
> >    and MS_ASYNC never undertook to give a guarantee about *when*
> >    the update would occur. (The Linux buffer cache logic will 
> >    ensure that it is flushed out sometime in the near future.)
> 
> Right.  It's a fairly inefficient noop, though - it actually loops
> over all vmas to do nothing with them.

This will probably change for Persistent Memory.  The reason it
works today is that we have a page cache which tracks dirty bits and
periodically writes dirty pages to storage.  If we bypass the page cache,
we have to ensure that everything does still eventually get synced.

I don't quite know how this is going to work yet ... I have a number of
ideas in my head.  It probably won't be asynchronous though!

> > 7. On Linux (and probably many other modern systems), the only
> >    call that has any real use is msync(MS_SYNC), meaning
> >    "flush the buffers *now*, and I want to wait for that to 
> >    complete, so that I can then continue safe in the knowledge
> >    that my data has landed on a device". That's useful if we
> >    want insurance for our data in the event of a system crash.
> 
> Right.  It's basically another way to call fsync, which is used to
> implement it underneath.  It actually should be a ranged-fdatasync
> but right it's it's implemented horribly inefficiently in that it
> does a fsync call for each vma that it encounters in the range
> specified.

See also: 

From: Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>
To: linux-mm@xxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Cc: Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>, willy@xxxxxxxxxxxxxxx
Subject: [PATCH] Sync only the requested range in msync
Date: Thu, 27 Mar 2014 19:02:41 -0400
Message-Id: <1395961361-21307-1-git-send-email-matthew.r.wilcox@xxxxxxxxx>

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