linux-kernel - Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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, 10 Dec 2012 13:13:28 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Steven Whitehouse <swhiteho@...hat.com>
Cc:	Dave Chinner <david@...morbit.com>,
	Chris Mason <chris.mason@...ionio.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ric Wheeler <rwheeler@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Martin Steigerwald <Martin@...htvoll.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate
 UAPI

On Mon, Dec 10, 2012 at 06:05:59PM +0000, Steven Whitehouse wrote:
> 
> If the block device can zero out blocks more efficiently than just
> writing zeros (i.e. via sb_issue_zeroout()) then this could be faster.
> In fact GFS2 already zeros out fallocate()d extents in this way because
> it has no way to mark unwritten extents in its metadata, and we did not
> want to leave them uninitialised,

Sure, but if the block device supports WRITE_SAME or persistent
discard, then rpesumably fallocate() should do this automatically all
the time, and not require a flag to request this behavior.  That is, a
seek plus writing 1MB does take more time than the amount of disk time
fraction that it consumes if you compare it to a seek plus writing 4k
or 32k.  It may be that 32k is too low, and there may be some
disagreement about whether people want to the system to automatically
tune for average throughput vs 99.9 percentile latency.

Regardless, this is actually something which I think the file system
should try to do automatically if at all possible, via some kind of
auto-tuning hueristic, instead of using an explicit fallocate(2) flag.
(See, I don't propose using a new fallocate flag for everything.  :-)

      	      	      	  	    	     - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/