xfs
[Top] [All Lists]

Re: [PATCH, RFC] xfs: batched discard support

To: Mark Lord <liml@xxxxxx>
Subject: Re: [PATCH, RFC] xfs: batched discard support
From: Ric Wheeler <rwheeler@xxxxxxxxxx>
Date: Thu, 20 Aug 2009 09:48:50 -0400
Cc: Ingo Molnar <mingo@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, Paul Mackerras <paulus@xxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, jens.axboe@xxxxxxxxxx, IDE/ATA development list <linux-ide@xxxxxxxxxxxxxxx>, Neil Brown <neilb@xxxxxxx>
In-reply-to: <4A8CA956.2060406@xxxxxx>
References: <20090816004705.GA7347@xxxxxxxxxxxxx> <20090819203916.GA25296@xxxxxxx> <4A8CA956.2060406@xxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
On 08/19/2009 09:39 PM, Mark Lord wrote:
[resending, after fixing the Cc: list; somebody trimmed it earlier]

Jamie Lokier wrote:
..
I don't remember - does TRIM guarantee the blocks read zeros afterwards?
..

No, it doesn't.

A drive can optionally support "deterministic TRIM", whereby it will return consistent data for any given trimmed sector afterwards, but that doesn't mean zeros.

-ml

Note that returning consistent data is critical for devices that are used in a RAID group since you will need each RAID block that is used to compute the parity to continue to return the same data until you overwrite it with new data :-)

If we have a device that does not support this (or is misconfigured not to do this), we should not use those devices in an MD group & do discard against it...

ric

<Prev in Thread] Current Thread [Next in Thread>