[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A898BC4.70704@hp.com>
Date: Mon, 17 Aug 2009 12:56:36 -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:
>
> 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.
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/
Powered by blists - more mailing lists