From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Zhang Yi <yi.zhang@huaweicloud.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-block@vger.kernel.org, dm-devel@lists.linux.dev,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, john.g.garry@oracle.com, bmarzins@redhat.com,
chaitanyak@nvidia.com, shinichiro.kawasaki@wdc.com,
brauner@kernel.org, yi.zhang@huawei.com, chengzhihao1@huawei.com,
yukuai3@huawei.com, yangerkun@huawei.com
Subject: Re: [RFC PATCH v4 07/11] fs: statx add write zeroes unmap attribute
Date: Mon, 5 May 2025 22:36:54 -0700 [thread overview]
Message-ID: <20250506053654.GA25700@frogsfrogsfrogs> (raw)
In-Reply-To: <20250506050239.GA27687@lst.de>
On Tue, May 06, 2025 at 07:02:39AM +0200, Christoph Hellwig wrote:
> On Mon, May 05, 2025 at 07:29:45AM -0700, Darrick J. Wong wrote:
> > attributes_mask contains attribute flags known to the filesystem,
> > whereas attributes contains flags actually set on the file.
> > "known_attributes" would have been a better name, but that's water under
> > the bridge. :P
>
> Oooh. I think I was very confused at what this patch does, and what
> it does seems confused as well.
>
> The patch adds a new flag to the STATX_ATTR_* namespace, which
> historically was used for persistent on-disk flags like immutable,
> not the STATX_* namespace where I assumed it, and which has no
> support mask. Which seems really odd for a pure kernel feature.
> Then again it seems to follow STATX_ATTR_WRITE_ATOMIC which seems
> just as wrongly place unless I'm missing something?
I think STATX_* (i.e. not STATX_ATTR_*) flags have two purposes: 1) to
declare that specific fields in struct statx actually have meaning, most
notably in scenarios where zeroes are valid field contents; and 2) if
filling out the field is expensive, userspace can elect not to have it
filled by leaving the bit unset. I don't know how userspace is supposed
to figure out which fields are expensive.
STATX_ATTR_* are supposed to be reflect persistent inode state. I think
STATX_ATTR_WRITE_ATOMIC is a (now unremovable) artifact of the era when
we were going to have a new iflag and feature bit for all the new
forcealign functionality. For XFS it's not necessary anymore because we
always have software fallback and the statx::atomic_write_* fields being
nonzero is sufficient to detect the functionality.
(I'm confused about the whole premise of /this/ patch -- it's a "fast
zeroing" fallocate flag that causes the *device* to unmap, so that the
filesystem can preallocate and avoid unwritten extent conversions?
What happens if the block device is thinp and it runs out of space?
That seems antithetical to fallocate...)
--D
next prev parent reply other threads:[~2025-05-06 5:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 2:14 [RFC PATCH v4 00/11] fallocate: introduce FALLOC_FL_WRITE_ZEROES flag Zhang Yi
2025-04-21 2:14 ` [RFC PATCH v4 01/11] block: introduce BLK_FEAT_WRITE_ZEROES_UNMAP to queue limits features Zhang Yi
2025-05-05 11:54 ` Christoph Hellwig
2025-05-06 4:21 ` Martin K. Petersen
2025-05-06 7:51 ` Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 02/11] nvme: set BLK_FEAT_WRITE_ZEROES_UNMAP if device supports DEAC bit Zhang Yi
2025-05-05 11:55 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 03/11] nvme-multipath: add BLK_FEAT_WRITE_ZEROES_UNMAP support Zhang Yi
2025-05-05 11:55 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 04/11] nvmet: set WZDS and DRB if device supports BLK_FEAT_WRITE_ZEROES_UNMAP Zhang Yi
2025-05-05 11:56 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 05/11] scsi: sd: set BLK_FEAT_WRITE_ZEROES_UNMAP if device supports unmap zeroing mode Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 06/11] dm: add BLK_FEAT_WRITE_ZEROES_UNMAP support Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 07/11] fs: statx add write zeroes unmap attribute Zhang Yi
2025-05-05 13:22 ` Christoph Hellwig
2025-05-05 14:29 ` Darrick J. Wong
2025-05-06 4:28 ` Zhang Yi
2025-05-06 4:39 ` Christoph Hellwig
2025-05-06 11:16 ` Zhang Yi
2025-05-06 12:11 ` Christoph Hellwig
2025-05-07 7:33 ` Zhang Yi
2025-05-07 21:03 ` Darrick J. Wong
2025-05-08 5:01 ` Christoph Hellwig
2025-05-08 12:17 ` Zhang Yi
2025-05-08 20:24 ` Theodore Ts'o
2025-05-09 12:35 ` Zhang Yi
2025-05-06 5:02 ` Christoph Hellwig
2025-05-06 5:36 ` Darrick J. Wong [this message]
2025-05-06 5:47 ` Christoph Hellwig
2025-05-06 11:25 ` Zhang Yi
2025-05-06 12:10 ` Christoph Hellwig
2025-05-06 15:55 ` Darrick J. Wong
2025-05-07 8:23 ` Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 08/11] fs: introduce FALLOC_FL_WRITE_ZEROES to fallocate Zhang Yi
2025-05-05 13:22 ` Christoph Hellwig
2025-04-21 2:15 ` [RFC PATCH v4 09/11] block: factor out common part in blkdev_fallocate() Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 10/11] block: add FALLOC_FL_WRITE_ZEROES support Zhang Yi
2025-04-21 2:15 ` [RFC PATCH v4 11/11] ext4: " Zhang Yi
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=20250506053654.GA25700@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bmarzins@redhat.com \
--cc=brauner@kernel.org \
--cc=chaitanyak@nvidia.com \
--cc=chengzhihao1@huawei.com \
--cc=dm-devel@lists.linux.dev \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.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.