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]

Date:	Mon, 4 Nov 2013 19:51:46 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Christoph Hellwig <hch@...radead.org>
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 Mon, Nov 04, 2013 at 02:03:43AM -0800, Christoph Hellwig wrote:
> 
> 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?

The an application in question wants to treat a large file as if it
were a block device --- that's hardly unprecedented; enterprise
databases tend to prefer using raw block devices (at least for
benchmarking purposes), but system administrators like to
administrative convenience of using a file system.

The goal here is get the performace as close to a raw block device as
possible.  Especially if you are using fast flash, the overhead of
deallocating blocks using punch, only to reallocate the blocks when we
later write into them, is just unnecessary overhead.  Also, if you
deallocate the blocks, they could end up getting grabbed by some other
block allocation, which means the file can end up getting very
fragmented --- which doesn't matter that much for flash, I suppose,
but it means the extent tree could end up growing and getting nasty
over time.  The bottom line is why bother doing extra work when it's
not necessary?

If people don't like exposing this via FIEMAP, we could just simply
make it available via the BLKDISCARD ioctl, which already exists
(although currently it is only implemented for block devices).

					- Ted
--
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