Re: [PATCH 3/5] vfs: add a zero-initialization mode to fallocate

From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jane Chu <jane.chu@oracle.com>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 3/5] vfs: add a zero-initialization mode to fallocate
Date: Tue, 21 Sep 2021 21:13:54 -0700	[thread overview]
Message-ID: <20210922041354.GE570615@magnolia> (raw)
In-Reply-To: <20210922035907.GR1756565@dread.disaster.area>

On Wed, Sep 22, 2021 at 01:59:07PM +1000, Dave Chinner wrote:
> On Tue, Sep 21, 2021 at 07:38:01PM -0700, Darrick J. Wong wrote:
> > On Tue, Sep 21, 2021 at 07:16:26PM -0700, Dan Williams wrote:
> > > On Tue, Sep 21, 2021 at 1:32 AM Christoph Hellwig <hch@infradead.org> wrote:
> > > >
> > > > On Tue, Sep 21, 2021 at 10:44:31AM +1000, Dave Chinner wrote:
> > > > > I think this wants to be a behavioural modifier for existing
> > > > > operations rather than an operation unto itself. i.e. similar to how
> > > > > KEEP_SIZE modifies ALLOC behaviour but doesn't fundamentally alter
> > > > > the guarantees ALLOC provides userspace.
> > > > >
> > > > > In this case, the change of behaviour over ZERO_RANGE is that we
> > > > > want physical zeros to be written instead of the filesystem
> > > > > optimising away the physical zeros by manipulating the layout
> > > > > of the file.
> > > >
> > > > Yes.
> > > >
> > > > > Then we have and API that looks like:
> > > > >
> > > > >       ALLOC           - allocate space efficiently
> > > > >       ALLOC | INIT    - allocate space by writing zeros to it
> > > > >       ZERO            - zero data and preallocate space efficiently
> > > > >       ZERO | INIT     - zero range by writing zeros to it
> > > > >
> > > > > Which seems to cater for all the cases I know of where physically
> > > > > writing zeros instead of allocating unwritten extents is the
> > > > > preferred behaviour of fallocate()....
> > > >
> > > > Agreed.  I'm not sure INIT is really the right name, but I can't come
> > > > up with a better idea offhand.
> > > 
> > > FUA? As in, this is a forced-unit-access zeroing all the way to media
> > > bypassing any mechanisms to emulate zero-filled payloads on future
> > > reads.
> 
> Yes, that's the semantic we want, but FUA already defines specific
> data integrity behaviour in the storage stack w.r.t. volatile
> caches.
> 
> Also, FUA is associated with devices - it's low level storage jargon
> and so is not really appropriate to call a user interface operation
> FUA where users have no idea what a "unit" or "access" actually
> means.
> 
> Hence we should not overload this name with some other operation
> that does not have (and should not have) explicit data integrity
> requirements. That will just cause confusion for everyone.
> 
> > FALLOC_FL_ZERO_EXISTING, because you want to zero the storage that
> > already exists at that file range?
> 
> IMO that doesn't work as a behavioural modifier for ALLOC because
> the ALLOC semantics are explicitly "don't touch existing user
> data"...

Well since you can't preallocate /and/ zerorange at the same time...

/* For FALLOC_FL_ZERO_RANGE, write zeroes to pre-existing mapped storage. */
#define FALLOC_FL_ZERO_EXISTING		(0x80)

/* For preallocation, allocate written extents and set the contents to
 * zeroes. */
#define FALLOC_FL_ALLOC_WRITE_ZEROES	(0x80)

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com