linux-kernel - Re: about TRIM/DISCARD support and barriers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20081125032851.GC25548@parisc-linux.org>
Date:	Mon, 24 Nov 2008 20:28:52 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Tejun Heo <teheo@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>,
	Dongjun Shin <djshin90@...il.com>, chris.mason@...cle.com
Subject: Re: about TRIM/DISCARD support and barriers

On Mon, Nov 24, 2008 at 09:03:50AM +0000, David Woodhouse wrote:
> And _then_ we can think about special cases which let us merge
> non-contiguous discards.

I've been thinking about what a solution would look like that lets us
send non-contiguous discards down, and I don't like the look of any of
them.  Right now, discard bios get turned into discard requests and
those are handled by the block device drivers as being a discard of the
range (sector, sector + nr_sectors).

If we're going to allow discontiguous ranges to be merged into one
request, then we need somewhere to store the ranges.  The obvious answer
is in the ->bio list.  But then, an unconverted driver will discard the
wrong sectors (presuming nr_sectors gets updated to the length of all
discarded sectors).

There's also murmurings from vendors that they want to restrict the
number of ranges transmitted in a single UNMAP/TRIM command, and that's
more information to be passed to the elevator.

How about an interface that lets the driver's discard function scan back
through the queue and see if there are any more discard bios queued up?
If there are, (and it has room for them) it can retire them from the
queue early. 

I'm open to other ideas, of course.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/