Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Thu, Mar 17, 2016 at 02:49:06PM -0600, Andreas Dilger wrote:

On Mar 17, 2016, at 12:35 PM, Chris Mason [off-list ref] wrote:

quoted

On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote:

quoted

On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum [off-list ref] wrote:

quoted

So we've not asked for NO_HIDE_STALE on the mailing lists, but I think
it was one of the problems Sage had using xfs in his BlueStore
implementation and was a big part of why it moved to pure userspace.
FileStore might use NO_HIDE_STALE in some places but it would be
pretty limited. When it came up at Linux FAST we were discussing how
it and similar things had been problems for us in the past and it
would've been nice if they were upstream.

Hmm.

So to me it really sounds like somebody should cook up a patch, but we
shouldn't put it in the upstream kernel until we get numbers and
actual "yes, we'd use this" from outside of google.

We haven't had internal tiers yelling at us for fallocate performance,
so I'm unlikely to suggest it, just because its a potential
privacy leak we'd have to educate people about.  What I'd be more likely
to use is code inside the filesystem like this:

somefs_fallocate() {
	if (trim_can_really_zero(my_device)) {
		trim
		allocate a regular extent
		return
	} else {
		do normal fallocate
	}
}

We were discussing almost this very same thing in the ext4 concall today.

Ted initially didn't think it was worthwhile to implement, but after looking
at the whitelist for SATA SSDs it seems that there are enough devices on the
market that support the ATA_HORKAGE_ZERO_AFTER_TRIM to make this approach
worthwhile to implement.

We'll end up with people complaining it makes fallocate slower because
of the trims, so it's not a perfect solution.  But I much prefer it to
fallocate-stale.

Also, if the ext4 extent size was limited it might even be possible to do
this efficiently enough with write_same on HDD devices.

quoted

Then the out of tree patch (for google or whoever) becomes a hack to
flip trim_can_really_zero on a given block device.  The rest of us can
use explicit interfaces from the hardware when deciding what we want
preallocation to mean.

This might be a bit trickier, since this would affect all zero/trim
operations, not just ones for uninitialized data extents.

Thinking more, my guess is that google will just keep doing what they
are already doing ;)  But there could be a flag in sysfs dedicated to
trim-for-fallocate so admins can see what their devices are reporting.
readonly in mainline, if someone wants to patch it in their large data
center it wouldn't be hard.

-chris