Re: [LSF/MM/BPF TOPIC] Implementing the NFS v4.2 WRITE_SAME operation: VFS or NFS ioctl() ?

[Chuck Lever <chuck.lever@oracle.com>]

On 1/16/25 10:36 AM, Theodore Ts'o wrote:
> On Thu, Jan 16, 2025 at 08:59:19AM -0500, Chuck Lever wrote:
>>
>> See my previous reply in this thread: WRITE_SAME has a long-standing
>> existing use case in the database world. The NFSv4.2 WRITE_SAME
>> operation was designed around this use case.
>>
>> You remember database workloads, right? ;-)
> 
> My understanding is that the database use case maps onto BLKZEROOUT
> --- specifically, databases want to be able to extend a tablespace
> file, and what they want to be able to do is to allocate a contiguous
> range using fallocate(2), but then want to make sure that the blocks
> in the block are marked as initialized so that future writes to the
> file do not require metadata updates when fsync(2) is called.
> Enterprise databases like Oracle and db2 have been doing this for
> decades; and just in the past two months recently I've had
> representatives from certain open source databases ask for something
> like the FALLOC_FL_WRITE_ZEROES.
> 
> So yes, I'm very much aware of database workloads --- but all they
> need is to write zeros to mark a file range that was freshly allocated
> using fallocate to be initialized.  They do not need the more
> expansive features which as defined by the SCSI or NFSv4.2.  All of
> the use cases done by enterprise Oracle, db2, and various open source
> databases which have approached me are typically allocating a chunk
> of aligned space (say, 32MiB) and then they want to initalize this
> range of blocks.
> 
> This then doesn't require poison sentinals, since it's strictly
> speaking an optimization.  The extent tree doesn't get marked as
> initalized until the zero-write has been commited to the block device
> via a CACHE FLUSH.  If we crash before this happens, reads from the
> file will get zeros, and writes to the blocks that didn't get
> initialized will still work, but the fsync(2) might trigger a
> filesystem-level journal commit.  This isn't a disaster....
> 
> Now, there might be some database that needs something more
> complicated, but I'm not aware of them.  If you know of any, is that
> something that you are able to share?

Any database that uses a block size that is larger than the block
size of the underlying storage media is at risk of a torn write.
The purpose of WRITE_SAME is to demark the database blocks with
sentinels on each end of the database block containing a time
stamp or hash.

If, when read back, the sentinels match, the whole database
block is good to go. If they do not, then the block is torn
and recovery is necessary.


-- 
Chuck Lever