[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160207083814.GA695@infradead.org>
Date: Sun, 7 Feb 2016 00:38:14 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Ross Zwisler <ross.zwisler@...ux.intel.com>,
Jan Kara <jack@...e.cz>,
Dan Williams <dan.j.williams@...el.com>,
Dave Chinner <david@...morbit.com>,
Matthew Wilcox <willy@...ux.intel.com>,
Christoph Hellwig <hch@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-nvdimm <linux-nvdimm@...1.01.org>
Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
On Fri, Feb 05, 2016 at 03:25:00PM -0700, Ross Zwisler wrote:
> According to the standard specification (e.g., POSIX.1-2001), sync()
> schedules the writes, but may return before the actual writing
> is done. However, since version 1.3.20 Linux does actually wait.
> (This still does not guarantee data integrity: modern disks have large
> caches.)
>
> Based on this I don't believe that it is a requirement that sync and syncfs
> actually flush the data durably to media before they return - they just need
> to make sure it has been sent to the device, which is always true for all
> writes PMEM via DAX, even without any calls to dax_writeback_mapping_range().
For Linux there is a requirement to not return before the data is on disk,
and our users rely on it. The man page is rather confusing, and I'll see
if I can fix it up.
Powered by blists - more mailing lists