Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965557AbcCQVBN (ORCPT ); Thu, 17 Mar 2016 17:01:13 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:38258 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965007AbcCQVBK (ORCPT ); Thu, 17 Mar 2016 17:01:10 -0400 Date: Thu, 17 Mar 2016 14:00:18 -0700 From: Chris Mason To: Andreas Dilger CC: Linus Torvalds , Gregory Farnum , Eric Sandeen , "Theodore Ts'o" , "Darrick J. Wong" , Dave Chinner , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , Martin Petersen , Christoph Hellwig , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , , Bruce Fields , linux-fsdevel , Jeff Layton Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160317210018.GA78710@clm-mbp.thefacebook.com> Mail-Followup-To: Chris Mason , Andreas Dilger , Linus Torvalds , Gregory Farnum , Eric Sandeen , Theodore Ts'o , "Darrick J. Wong" , Dave Chinner , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , Martin Petersen , Christoph Hellwig , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton References: <20160315223313.GH30721@dastard> <20160315225224.GD23848@thunk.org> <20160316015139.GC5826@birch.djwong.org> <7674C689-C07E-4D38-85EB-4FD9B55CBB35@dilger.ca> <20160317001502.GF23593@thunk.org> <56E9FB73.6040803@redhat.com> <20160317183512.GA76233@clm-mbp.thefacebook.com> <819F38A3-51A7-4874-8314-8A6004495716@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <819F38A3-51A7-4874-8314-8A6004495716@dilger.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-17_08:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2800 Lines: 65 On Thu, Mar 17, 2016 at 02:49:06PM -0600, Andreas Dilger wrote: > On Mar 17, 2016, at 12:35 PM, Chris Mason wrote: > > > > On Thu, Mar 17, 2016 at 10:47:29AM -0700, Linus Torvalds wrote: > >> On Wed, Mar 16, 2016 at 10:18 PM, Gregory Farnum wrote: > >>> > >>> 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. > > > 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