linux-kernel - Re: [RFC PATCH 1/2] fs: introduce FALLOC_FL_FORCE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b964a57a-0237-4cbd-9aae-457527a44440@huaweicloud.com>
Date: Tue, 7 Jan 2025 22:05:47 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: "Darrick J. Wong" <djwong@...nel.org>,
 Christoph Hellwig <hch@...radead.org>
Cc: Theodore Ts'o <tytso@....edu>, linux-fsdevel@...r.kernel.org,
 linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
 viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
 adilger.kernel@...ger.ca, yi.zhang@...wei.com, chengzhihao1@...wei.com,
 yukuai3@...wei.com, yangerkun@...wei.com,
 Sai Chaitanya Mitta <mittachaitu@...il.com>, linux-xfs@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] fs: introduce FALLOC_FL_FORCE_ZERO to fallocate

On 2025/1/7 1:31, Darrick J. Wong wrote:
> On Mon, Jan 06, 2025 at 08:27:49AM -0800, Christoph Hellwig wrote:
>> On Mon, Jan 06, 2025 at 11:17:32AM -0500, Theodore Ts'o wrote:
>>> Yes.  And we might decide that it should be done using some kind of
>>> ioctl, such as BLKDISCARD, as opposed to a new fallocate operation,
>>> since it really isn't a filesystem metadata operation, just as
>>> BLKDISARD isn't.  The other side of the argument is that ioctls are
>>> ugly, and maybe all new such operations should be plumbed through via
>>> fallocate as opposed to adding a new ioctl.  I don't have strong
>>> feelings on this, although I *do* belive that whatever interface we
>>> use, whether it be fallocate or ioctl, it should be supported by block
>>> devices and files in a file system, to make life easier for those
>>> databases that want to support running on a raw block device (for
>>> full-page advertisements on the back cover of the Businessweek
>>> magazine) or on files (which is how 99.9% of all real-world users
>>> actually run enterprise databases.  :-)
>>
>> If you want the operation to work for files it needs to be routed
>> through the file system as otherwise you can't make it actually
>> work coherently.  While you could add a new ioctl that works on a
>> file fallocate seems like a much better interface.  Supporting it
>> on a block device is trivial, as it can mostly (or even entirely
>> depending on the exact definition of the interface) reuse the existing
>> zero range / punch hole code.
> 
> I think we should wire it up as a new FALLOC_FL_WRITE_ZEROES mode,
> document very vigorously that it exists to facilitate pure overwrites
> (specifically that it returns EOPNOTSUPP for always-cow files), and not
> add more ioctls.
> 

Sorry. the "pure overwrites" and "always-cow files" makes me confused,
this is mainly used to create a new written file range, but also could
be used to zero out an existing range, why you mentioned it exists to
facilitate pure overwrites?

For the "always-cow files", do you mean reflinked files? Could you
please give more details?

Thanks,
Yi.

> (That said, doesn't BLKZEROOUT already do this for bdevs?)
> 
> --D