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 -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer Preservation and Forensic processing of Exchange Repositories White Paper - <http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html> The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
