On Mon, Jan 26, 2009 at 12:51 PM, Mark Lord <liml@xxxxxx> wrote: > Greg Freemyer wrote: >> >> Seems to introduce some huge layering violations for Raid 5 / 6 >> implementations using next generation SSDs to comprise the raid >> volumes. > > .. > > Possibly so. But having stripe layouts known to the fs layer > is a *good* thing, and is pretty much already necessary for decent > filesystem performance. It would be better even, if the filesystem > would just automatically pick up that information, rather than > relying upon mkfs parameters (maybe they already do now ?). > >> Allowing data to change from the SATA / SAS interface layer and not >> implementing a signaling mechanism that allows the kernel (or any OS / >> software tool) to ask which sectors / blocks / erase units have >> undergone data changes is just bizarre to me. > > .. > > I think that's just blowing smoke. The only sectors/blocks/erase-units > which > even *might* undergo such changes, are already restricted to those exact > units which the kernel itself specificies (by explicitly discarding them). > If we care about knowing which ones later on (and we don't, generally), > then we (kernel) can maintain a list, just like we do for other such > entities. > > I don't see much of a downside here for any normal users of filesystems. > This kind of feature is long overdue. > > Cheers > Just so I know and before I try to find the right way to comment to the T13 and T10 committees: What is the negative of adding a ATA/SCSI command to allow the storage device to be interrogated to see what sectors/blocks/erase-units are in a mapped vs. unmapped state? For T13 (ATA), it would actually be a tri-state flag I gather: Mapped - last data written available unmapped - no data values assigned unmapped - deterministic data values Surely the storage device has to be keeping this data internally. Why not expose it? For data recovery and computer forensics purposes I would actually prefer even finer grained info, but those 3 states seem useful for several layers of the filesystem stack to be able to more fully optimize what they are doing. Greg -- Greg Freemyer 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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
