Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4646500imm; Wed, 30 May 2018 09:16:07 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL1jGR7ngQHQ/a9nrntZ+aVAR4tkM5w2vlXeltj5O1u+J0+KT4pX4oZ6Xr56y93yVUUiLjh X-Received: by 2002:a62:a09c:: with SMTP id p28-v6mr3380162pfl.9.1527696967842; Wed, 30 May 2018 09:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527696967; cv=none; d=google.com; s=arc-20160816; b=LYasMH+zBaQ6V1T4IzglIhdzOe0o3edkaFo1/gi1QeCitJnupEM3pTI+IEvXV8qkf2 HNbuw2F/FswHUVcxQWdEOTqQ7Q0ufyjnR7Wbpcw7jbAyz+HYcVfOepElMlZMaCuntC8A OrUbQXtzLDh+iQ5iHu7jPShnFykiNWJ5tkCbVOLcjBkxKsdunv5TP2/5YgHCLXy0E64A R3x7cllk1+FQh1XDDdwAZE4tI9Pj53IfWv3s7Nym5E+jsl9MEyIOqytqa30Gd4/4+GMG 4TBRqVzep20tyUc24olZDYkuJs1EbYN76/MaBeWxCwrgVrzvaGXPdfZ/VB1Zeseh9uwL RPuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=BuQlB+ZoJZWiBuPjAGjkkmcr3AVax57G2upDSH2+Ee0=; b=vROMhzFly/egzpT5yPr5y8o4TZHen3Ud08T83zIjLdvlSQ6ZprEnB6t5YMJrqCOvYa T3DJJqnBT2s/4vLrD4C01tFgqpauwLrANbiIkdBxTZWN48xtvLqBKGvNmLPVJz2cV+Ia VFrE1felgLQ7eFiEQd+Fg1RfjJ5Cwi9vG08eAJJl8iEPJ/Evl5vWZx1nS2EGgjce6bRW 2hu5CJwKWqw8b0GIGSz7pCP1QDKXiFZKPEPpZfwVNjJNQ5llCJdwescBpvlEQ1gACF2T 0eyHQd9m+p7jaa7MAIz+ef1x+prz78FSuIZgE0+hLOQ0iJHfBXVhTQZo+JUcE/x3Kovz OsyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=jtxXhXC5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a12-v6si27678431pgw.578.2018.05.30.09.15.52; Wed, 30 May 2018 09:16:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=jtxXhXC5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbeE3QPV (ORCPT + 99 others); Wed, 30 May 2018 12:15:21 -0400 Received: from imap.thunk.org ([74.207.234.97]:46690 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753075AbeE3QPR (ORCPT ); Wed, 30 May 2018 12:15:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BuQlB+ZoJZWiBuPjAGjkkmcr3AVax57G2upDSH2+Ee0=; b=jtxXhXC5l9mtsGjYcF9HofKD6y RxbQvcDCcQ0MnrbzIuyUCDGwXbJAZPdLqllQFDQn+vzM6iS5JpSCk0ihqWy8suKG06Qh3fz+oi4QS 0+X5GUhFJ7zXyNI3P7K22DbXHBAuGcWDsqMR1CHVL3UQrcM3iWT06BWBaVq8tQnsGaLc=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fO3ki-0002yI-Cp; Wed, 30 May 2018 16:15:08 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 9A1037A60AF; Wed, 30 May 2018 12:15:07 -0400 (EDT) Date: Wed, 30 May 2018 12:15:07 -0400 From: "Theodore Y. Ts'o" To: Adrian Hunter Cc: Christoph Hellwig , Faiz Abbas , "linux-kernel@vger.kernel.org" , linux-omap , linux-mmc , linux-block , Ulf Hansson , Jens Axboe , linux-ext4@vger.kernel.org Subject: Re: mmc filesystem performance decreased on the first write after filesystem creation Message-ID: <20180530161507.GA14279@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Adrian Hunter , Christoph Hellwig , Faiz Abbas , "linux-kernel@vger.kernel.org" , linux-omap , linux-mmc , linux-block , Ulf Hansson , Jens Axboe , linux-ext4@vger.kernel.org References: <20180528062618.GA4196@lst.de> <43d4164f-5dda-b49a-6008-1f5bf4b08547@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43d4164f-5dda-b49a-6008-1f5bf4b08547@intel.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 30, 2018 at 11:51:41AM +0300, Adrian Hunter wrote: > > And discards are not enabled by default by mount so, at least on ext4, > adding "-o discard" is needed in the mount options. This is because doing discards right away is not always a win from performance reasons. There are some flash devices where discards are super-slow and some devices where issuing discards too quickly would cause them to trigger internal FTL race conditions and turn them into paperweights. There was at least one engineer from a Linux distribution who argued for making discard not the default because back then, there were a lot of SSD's floating out there (by a manufacturer who thankfully has since gone bankrupt :-) for which they didn't want to deal with the support requests from people who were angry about lost data or destroyed SSD's --- because guess who they would blame? Also, please note that for many devices it's much better to periodically run fstrim (once a day or once a week) out of cron. If someone wants to do a survey of available hardware and demonstrate: * there is significant value from enabling -o discard by default (instead of using fstrim) * there are no (or at least very, very few) devices for which enabling -o discard results in a major performance regression, and * if there are any devices left that turn into paperweights, they can be managed using blacklists, I'm certainly open to changing the default. There was, however, a really good *reason* why the default was chosen to be the way it is. - Ted