On Mon, May 11, 2009 at 8:09 AM, Theodore Tso > All of the web browsing I've doen confirms that the ATA folks expect > trim to work on 512-sector granularity. Ted, That implies that the SSD folks are not treating erase blocks as a contiguous group of sectors. For some reason, I thought their was only one mapping per erase block and within the erase block the sectors were contiguous.. If I'm right, then the ata spec may allow you to send sub-erase block trim commands down, but the spec does not prevent the (blackbox) hardware from clipping the size of the trim to be on erase block boundaries and ignoring the sub-erase block portions on each end. Or ignoring the whole command if your trim command does not span a whole erase block. Also the mdraid people plan to clip at the stripe width boundary for raid 5, 6, etc. Their expectation is that discards will be coalesced into bigger blocks before it gets to the mdraid layer. I still think reshaping a raid 5 online will be next to impossible when some of the stripes may contain indeterminate data. More realistic is to figure out a way to make it deterministic at least for the short term (by writing data to all the trimmed blocks?), then reshaping, then having a tool to scan the filesystem and re-issue all the trim commands. Obviously, if the ata spec had a signaling mechanism that differentiated between deterministic data and non-deterministic data then the above code excess could be simplified greatly. Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
