All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Lukas Herbolt <lukas@herbolt.com>,
	yi.zhang@huaweicloud.com, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3] xfs: add FALLOC_FL_WRITE_ZEROES to XFS code base
Date: Thu, 30 Oct 2025 00:27:29 -0700	[thread overview]
Message-ID: <aQMTYZTZIA2LF4h0@infradead.org> (raw)
In-Reply-To: <20251029182255.GK3356773@frogsfrogsfrogs>

On Wed, Oct 29, 2025 at 11:22:55AM -0700, Darrick J. Wong wrote:
> > +	if (mode & FALLOC_FL_WRITE_ZEROES) {
> > +		if (xfs_is_cow_inode(ip) || !bdev_write_zeroes_unmap_sectors(
> 
> xfs_is_cow_inode() only tells us if the inode is capable of doing out of
> place writes.  Why would a regular reflinked inode be ineligible for
> WRITE_ZEROES?

Yes, this shoyuld be xfs_is_always_cow_inode.

> I don't understand why this bdev_write_zeroes_unmap_sectors check is
> here and not in xfs_alloc_file_space.  Shouldn't other callers of
> xfs_alloc_file_space be restricted from passing in XFS_BMAPI_ZERO if the
> block device doesn't support unmap_sectors?

Othere callers are fine with the software fallback for the block zeroing
helpers.  But this is a good question that should probably be documented
in a comment.


  reply	other threads:[~2025-10-30  7:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-21 14:17 [PATCH 0/2] Add FL_WRITE_ZEROES to XFS, fix krealloc on xfs_uuid_table Lukas Herbolt
2025-10-21 14:17 ` [PATCH] xfs: add FALLOC_FL_WRITE_ZEROES to XFS code base Lukas Herbolt
2025-10-21 15:55   ` Darrick J. Wong
2025-10-22  5:00   ` Christoph Hellwig
2025-10-22  7:13     ` Zhang Yi
2025-10-22  7:15       ` Christoph Hellwig
2025-10-22  7:27         ` Zhang Yi
2025-10-29 17:53           ` [PATCH v3] " Lukas Herbolt
2025-10-29 18:22             ` Darrick J. Wong
2025-10-30  7:27               ` Christoph Hellwig [this message]
2025-11-12 21:02                 ` [PATCH v4] " Lukas Herbolt
2025-11-13  6:59                   ` Christoph Hellwig
2025-11-14  8:55                     ` [PATCH v5] " Lukas Herbolt
2025-11-14  8:57                       ` Christoph Hellwig
2025-11-14 16:44                       ` Darrick J. Wong
2025-11-14 16:45                         ` Christoph Hellwig
2025-11-18  9:05                           ` lukas
2025-12-15 11:48                           ` [PATCH v6] " Lukas Herbolt
2025-12-15 14:28                             ` Christoph Hellwig
2025-10-30  7:29             ` [PATCH v3] " Christoph Hellwig
2025-10-21 14:17 ` [PATCH 2/2] xfs: Remove WARN_ONCE if xfs_uuid_table grows over 2x PAGE_SIZE Lukas Herbolt
2025-10-21 15:56   ` Darrick J. Wong
2025-10-21 22:02   ` Dave Chinner
2025-10-26 17:49     ` lukas
2025-10-22  4:53   ` Christoph Hellwig

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=aQMTYZTZIA2LF4h0@infradead.org \
    --to=hch@infradead.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lukas@herbolt.com \
    --cc=yi.zhang@huaweicloud.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.