linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	willy@linux.intel.com
Subject: Re: [PATCH] Sync only the requested range in msync
Date: Tue, 13 May 2014 09:31:01 -0400	[thread overview]
Message-ID: <x49y4y54xgq.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20140512163948.0b365598e1e4d0b06dea3bc6@linux-foundation.org> (Andrew Morton's message of "Mon, 12 May 2014 16:39:48 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 23 Apr 2014 07:11:15 -0700 Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Thu, Mar 27, 2014 at 07:02:41PM -0400, Matthew Wilcox wrote:
>> > [untested.  posted because it keeps coming up at lsfmm/collab]
>> > 
>> > msync() currently syncs more than POSIX requires or BSD or Solaris
>> > implement.  It is supposed to be equivalent to fdatasync(), not fsync(),
>> > and it is only supposed to sync the portion of the file that overlaps
>> > the range passed to msync.
>> > 
>> > If the VMA is non-linear, fall back to syncing the entire file, but we
>> > still optimise to only fdatasync() the entire file, not the full fsync().
>> > 
>> > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
>> 
>> Looks good,
>> 
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> I worry that if there are people who are relying on the current
> behaviour (knowingly or not!) then this patch will put their data at
> risk and nobody will ever know.  Until that data gets lost, that is.
> At some level of cautiousness, this is one of those things we can never
> fix.
>
> I suppose we could add an msync2() syscall with the new behaviour so
> people can migrate over.  That would be very cheap to do.
>
> It's hard to know what's the right thing to do here.

FWIW, I think we should apply the patch.  Anyone using the API properly
will not get the desired result, and it could have a negative impact on
performance.  The man page is very explicit on what you should expect,
here.  Anyone relying on undocumented behavior gets to keep both pieces
when it breaks.  That said, I do understand your viewpoint, Andrew,
especially since it's so hard to get people to sync their data at all,
much less correctly.

Acked-by: Jeff Moyer <jmoyer@redhat.com>

-Jeff

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-05-13 13:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 23:02 [PATCH] Sync only the requested range in msync Matthew Wilcox
2014-04-23 14:11 ` Christoph Hellwig
2014-05-12 23:39   ` Andrew Morton
2014-05-13 13:31     ` Jeff Moyer [this message]
2014-05-15 11:24       ` Christoph Hellwig
2014-05-15 12:50       ` Chris Mason
2014-05-20 22:58       ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x49y4y54xgq.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.r.wilcox@intel.com \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).