[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq18w8ae0mq.fsf@sermon.lab.mkp.net>
Date: Mon, 26 Apr 2010 10:42:21 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Mark Lord <kernel@...savvy.com>
Cc: Ric Wheeler <rwheeler@...hat.com>,
Greg Freemyer <greg.freemyer@...il.com>,
Eric Sandeen <sandeen@...hat.com>,
Lukas Czerner <lczerner@...hat.com>,
Jeff Moyer <jmoyer@...hat.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.
>>>>> "Mark" == Mark Lord <kernel@...savvy.com> writes:
Mark> So.. again.. in an ideal kernel, I'd like to see use of larger
Mark> ranges (and _multiple_ ranges) per TRIM command. And options for
Mark> the kernel to do it automatically (-o discard), as well as an
Mark> ioctl() interface for userspace to "scrub" (or "wipe") all free
Mark> ranges in a gradual fashion.
Again: Discard splitting, merging, and coalescing is coming. I'm
working on it. It's not exactly trivial.
My objection was purely wrt. nuking realtime discard in favor of
scrubbing. We absolutely need both approaches.
But I'm not going to let crappy SSD firmware implementations set the
direction for what I'm working on. It is much more interesting to
ensure that we work well for the devices that'll be shipping 6-12 months
from now (at the time where this stuff will realistically end up in
distro kernels).
--
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
Powered by blists - more mailing lists