On 11/23/2009 11:54 AM, Greg Freemyer wrote:
On Mon, Nov 23, 2009 at 11:37 AM, Ric Wheeler<rwheeler@xxxxxxxxxx> wrote:
On 11/21/2009 09:43 PM, Mark Lord wrote:
Matthew Wilcox wrote:
On Sat, Nov 21, 2009 at 05:13:56AM -0500, Christoph Hellwig wrote:
On Fri, Nov 20, 2009 at 09:45:21PM -0500, Martin K. Petersen wrote:
The discard ioctl is used by mkfs utilities to clear a block device
prior to putting metadata down. However, not all devices return zeroed
blocks after a discard. Some drives return stale data, potentially
containing old superblocks. It is therefore important to know whether
discarded blocks are properly zeroed.
At least for mkfs.xfs we make sure to still zero the important areas
after the TRIM ioctl anyway.
Could you change that to zero _before_ the TRIM?
..
Hopefully not for the drives that *don't* guarantee zeros after TRIM.
Eg. most existing ones, including all of the Indilinx chipset drives.
Cheers
Note that writing to a block after a discard (write or trim) changes the
state of that block back to allocated (mapped) in the target. Basically,
that would seem to make the trim redundant and irrelevant.
You can zero before the discard but that can still fail is the device
returns garbage for a trim'ed block I think,
Ric
I understood the mkfs process to be:
- discard / trim 100% of the block device
- write zeros to the relatively small group of blocks that the
filesystem assumes will be zero'd.
Seems like the only reasonable way to handle it.
Greg
I agree - the discard of the whole device is a good idea.
I just want to make clear that "discard block X; write block X with zeroed data"
undoes the discard in general :-)
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
