linux-ext4 - Re: [PATCH RFC] fs: add FIEMAP_FLAG

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: <20131104100343.GA10004@infradead.org>
Date:	Mon, 4 Nov 2013 02:03:43 -0800
From:	Christoph Hellwig <hch@...radead.org>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-fsdevel@...r.kernel.org,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] fs: add FIEMAP_FLAG_DISCARD support

On Sat, Nov 02, 2013 at 07:45:30PM -0400, Theodore Ts'o wrote:
> Add the ability for a user who has write access to a file to issue a
> discard request for blocks belonging to a file.  This can be done via
> a new flag to the FIEMAP ioctl, or via the BLKDISCARD ioctl (which
> previously only worked on block devices).

As Dave already pointed out overloading a data manipulating operation
over FIEMAP is a no-go.  

Besides that I really miss an explanation what the intended use cases
are.  What does this buy us over punching a hole on an actual real
workload?  Where is the overhead?  Is it our shitty discard
implementation? If so there's tons of low hanging fruit to fix there
anyway that we shouldn't work around by interfaces taking shortcuts.
Is it problems in ext4's extent management on hole punch?  Is the
bit of metadata created when doing an actual hole punch too much for
that very specific workload?

Also you really need to restrict this to devices that set the
discard_zeroes_data flag, without that you'll expose random
uninitialized data.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html