linux-ext4 - Re: [PATCH 2/2] Add batched discard support for ext4.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yq1wrvweklj.fsf@sermon.lab.mkp.net>
Date:	Sat, 24 Apr 2010 15:06:32 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Lukas Czerner <lczerner@...hat.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Mark Lord <kernel@...savvy.com>, linux-ext4@...r.kernel.org,
	Edward Shishkin <eshishki@...hat.com>,
	Eric Sandeen <esandeen@...hat.com>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 2/2] Add batched discard support for ext4.

>>>>> "Greg" == Greg Freemyer <greg.freemyer@...il.com> writes:

Greg> Is it also agreed by all that the current ext4 kernel
Greg> implementation of calling discard is a poor solution for most
Greg> hardware / block layers stacks / workloads and therefore is not
Greg> worth retaining nor performing further benchmarks?

Our discard implementation is meant to accommodate a wide range of
devices.  Just because some of the currently shipping low-end consumer
SSDs implement TRIM poorly does not mean we're going to scrap what we
have.

We are not in the business of designing for the past.  Especially not
when the past can be handled by a shell script.

For future devices TRIM/UNMAP is going to be an inherent part of the
command set.  And that's what our kernel support is aimed at.  There are
some deficiencies right now because the block layer was not built to
handle what is essentially a hybrid between a filesystem and a blk_pc
type request.  I'm working on fixing that.

Greg> I've not seen anyone arguing to keep the current kernel
Greg> implementation and I for one accept the previously posted
Greg> benchmarks that show it is not adding any value relative to the
Greg> traditional non-discard case.

For enterprise storage the cost of sending discards is limited to the
overhead of sending the command.  I.e. negligible.

Eventually that's going to be the case for ATA devices as well.  And let
me just reiterate that Windows 7 does issue TRIM like we do (at
runtime).  And consequently Windows 7 will help weed out the crap SSD
implementations from the market.  That's already happening.

There is also work underway to make TRIM a queueable command which would
further alleviate the situation.

Greg> Therefore benchmarks between the current hdparm/wiper.sh userspace
Greg> implementation and a proposed new kernel implementation would be
Greg> the most beneficial?

I don't know what you mean by "new" kernel implementation.  We're
working on tweaking what we have so that we can split, merge, and
coalesce requests.

I'm also not sure why you're so hung up on benchmarks.  The purpose of
TRIM is to increase longevity of a flash-based device.  For dumb devices
there's currently a tradeoff - do you want speed or endurance?  Once
devices get smarter that tradeoff will disappear.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html