Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757470AbcCRPPc (ORCPT <rfc822;w@1wt.eu>);
	Fri, 18 Mar 2016 11:15:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51320 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754285AbcCRPP2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 18 Mar 2016 11:15:28 -0400
From: Jeff Moyer <jmoyer@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Chris Mason <clm@fb.com>, Andreas Dilger <adilger@dilger.ca>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Gregory Farnum <greg@gregs42.com>, Eric Sandeen <sandeen@redhat.com>,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        Dave Chinner <david@fromorbit.com>, Ric Wheeler <rwheeler@redhat.com>,
        Andy Lutomirski <luto@amacapital.net>,
        One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
        Martin Petersen <martin.petersen@oracle.com>,
        Christoph Hellwig <hch@infradead.org>, Jens Axboe <axboe@kernel.dk>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux API <linux-api@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        shane.seymour@hpe.com, Bruce Fields <bfields@fieldses.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Jeff Layton <jlayton@poochiereds.net>
Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks
References: <20160315225224.GD23848@thunk.org>
	<20160316015139.GC5826@birch.djwong.org>
	<7674C689-C07E-4D38-85EB-4FD9B55CBB35@dilger.ca>
	<20160317001502.GF23593@thunk.org> <56E9FB73.6040803@redhat.com>
	<CAC6JEv-CGaphHj6hVXUhFS+Dc4jS46nO1yOfKF5yA8AnDwqgOw@mail.gmail.com>
	<CA+55aFzbzXb9ApP5FnVZihWRpWGO1-YnJj_Giip5LfD6=uvf0w@mail.gmail.com>
	<20160317183512.GA76233@clm-mbp.thefacebook.com>
	<819F38A3-51A7-4874-8314-8A6004495716@dilger.ca>
	<20160317210018.GA78710@clm-mbp.thefacebook.com>
	<20160318032023.GK23593@thunk.org>
X-PGP-KeyID: 1F78E1B4
X-PGP-CertKey: F6FE 280D 8293 F72C 65FD  5A58 1FF8 A7CA 1F78 E1B4
X-PCLoadLetter: What the f**k does that mean?
Date: Fri, 18 Mar 2016 11:15:23 -0400
In-Reply-To: <20160318032023.GK23593@thunk.org> (Theodore Ts'o's message of
	"Thu, 17 Mar 2016 23:20:23 -0400")
Message-ID: <x491t7795ro.fsf@segfault.boston.devel.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 622
Lines: 15

"Theodore Ts'o" <tytso@mit.edu> writes:

> I do think that using TRIM in various causes where we are doing an
> fallocate does make sense for non-rotational devices.  In general TRIM
> should be fast enough that that I'd be surprised that people would be
> complaining --- especially since most of the time, fallocate isn't on
> the timing-critical path of most applications.

TRIM/UNMAP isn't just supported on solid state devices, though.  I do
recall some enterprise thinly provisioned storage that would take ages
to discard large regions.  I think that caused us to change the defaults
for mkfs, right?

Cheers,
Jeff