Re: [PATCH 2/2] pnfs/blocklayout: report data lost to a failed LAYOUTCOMMIT

[Christoph Hellwig <hch@lst.de>]

On Fri, Oct 16, 2026 at 07:36:39AM -0400, Benjamin Coddington wrote:
> From: Benjamin Coddington <bcodding@hammerspace.com>
> 
> Data written through a block or SCSI layout into PNFS_BLOCK_INVALID_DATA
> extents stays unwritten on the server until a LAYOUTCOMMIT converts
> those extents.  When the LAYOUTCOMMIT fails, ext_tree_mark_committed()
> tags the extents written again so that a later LAYOUTCOMMIT can cover
> them, and reports nothing.  nfs4_layoutcommit_done() also zeroes the
> task status for NFS4ERR_BADLAYOUT, NFS4ERR_BADIOMODE,
> NFS4ERR_DELEG_REVOKED and NFS4ERR_GRACE, so a synchronous LAYOUTCOMMIT
> returns 0 for those.  A server that has revoked the layout answers
> NFS4ERR_BADLAYOUT; once the client drops that layout its extent tree
> goes with it, and fsync() and close() have returned 0 for data that
> reads back as zeroes.
> 
> When ext_tree_mark_committed() puts extents back, record -EIO in the
> mapping's writeback error and the superblock's, and have
> pnfs_generic_sync(), which only the block and SCSI layouts use, return
> an error recorded during its LAYOUTCOMMIT.  The files and flexfiles
> layouts, whose LAYOUTCOMMIT does not decide what a read of the file
> returns, are unchanged.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Should pnfs_generic_sync move into the blocklayout code as that is
the only user and it thus isn't exactly overly generic?