Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 14 Aug 2020 09:06:35 +0100
From:   Christoph Hellwig <hch@infradead.org>
To:     tytso@mit.edu
Cc:     Andreas Dilger <adilger@dilger.ca>,
        Wang Shilong <wangshilong1991@gmail.com>,
        Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Wang Shilong <wshilong@ddn.com>, Shuichi Ihara <sihara@ddn.com>
Subject: Re: [PATCH v3 1/2] ext4: introduce EXT4_BG_WAS_TRIMMED to optimize
 trim
Message-ID: <20200814080635.GA14827@infradead.org>
References: <1592831677-13945-1-git-send-email-wangshilong1991@gmail.com>
 <20200806044703.GC7657@mit.edu>
 <CAP9B-Qnv2LXva_szv+sDOiawQ6zRb9a8u-UAsbXqSqWiK+emiQ@mail.gmail.com>
 <20200808151801.GA284779@mit.edu>
 <9789BE11-11FB-42B2-A5BE-D4887838ED10@dilger.ca>
 <20200810132457.GA14208@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200810132457.GA14208@mit.edu>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 10, 2020 at 09:24:57AM -0400, tytso@mit.edu wrote:
> Part of the problem here is that discard is being used for different
> things for different use cases and devices with different discard
> speeds.  Right now, one of the primary uses of -o discard is for
> people who have fast discard implementation(s and/or people who really
> want to make sure every freed block is immediately discard --- perhaps
> to meet security / privacy requirements (such as HIPPA compliance,
> etc.).   I don't want to break that.

Note that discard does not provide any security whatsover.  For one
none of the underlying primitives actually gurantee any action, the
device is free to always ignore parts or all of a discard request.

And even if it didn't that doesn't mean that data couldn't easily
recovered from the media.

> 
> We now have a requirement of people who have very slow discards --- I
> think at one point people mentioned something about for devices using
> HDD, probably in some kind of dm-thin use case?  One solution that we
> can use for those is simply use fstrim -m 8M or some such.  But it
> appears that part of the problem is people do want more precision than
> that?

Device managed SMR drivers usually support TRIM.  But it actually
should be a decently fast operation usually, as those drives have a
remapping layer just like a FTL.