linux-kernel - Re: Discard support (was Re: [PATCH] swap: send callback when swap slot is freed)

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: <4A899559.8020200@hp.com>
Date:	Mon, 17 Aug 2009 13:37:29 -0400
From:	jim owens <jowens@...com>
To:	Bill Davidsen <davidsen@....com>
CC:	Mark Lord <liml@....ca>, Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Chris Worley <worleys@...il.com>,
	Matthew Wilcox <matthew@....cx>,
	Bryan Donlan <bdonlan@...il.com>, david@...g.hm,
	Greg Freemyer <greg.freemyer@...il.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Nitin Gupta <ngupta@...are.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-scsi@...r.kernel.org, linux-ide@...r.kernel.org,
	Linux RAID <linux-raid@...r.kernel.org>
Subject: Re: Discard support (was Re: [PATCH] swap: send callback when swap
 slot is freed)

Bill Davidsen wrote:
> jim owens wrote:
>> Bill Davidsen wrote:
>>>
>>> I assume that it really is artificial, rather than the device really 
>>> being ready for another operation (other than another TRIM). I lack 
>>> the hardware, but the test would be the time to complete a read, trim 
>>> and read, and two trim and read operations. Just my thought that the 
>>> TRIM in progress may only block the next TRIM, rather than other 
>>> operations.
>>
>> I don't know his test sequence but READ is not the likely command
>> before and after TRIM unless we are talking about TRIM being issued
>> only in delayed host garbage collection.  Filesystems send WRITES
>> during delete.
> 
> My idea is to test using a command which will definitely not need to 
> prepare the media before completion, thus read. If TRIM doesn't block 
> reads, then NCQ may allow reads to take place. Because of buffering slow 
> reads hurt more than slow writes in terms of user perception.
> 

The filesystem must send at least one unbuffered synchronous write
before it can send a trim for those blocks so the drive will not
release the blocks until we are certain they will not be needed again.

AKA the metadata consistency problem for crash recovery.

So non-delayed trim must at least be preceded by a write, but you
are correct that reads could be after the trim if the filesystem
does not have a multi-stage delete that requires a second synchronous
write, or if the trim can be held until all filesystem writes occur.

How hard it will be to "send the trim last" will be different for
each filesystem and some developers are already working on that.

jim
--
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/