On Tue, Jan 27, 2009 at 3:21 AM, Mark Lord <liml@xxxxxx> wrote: > Greg Freemyer wrote: >> >> 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? > > .. > > That's a good approach. One problem on the drive end, is that they > may not be maintain central lists of these. Rather, it might be stored > as local flags in each affected sector. > > So any attempt to query "all" is probably not feasible, > but it should be simple enough to "query one" sector at a time > for that info. If one wants them all, the just loop over > the entire device doing the "query one" for each sector. > > Another drawback to the "query all", is the size of data (the list) > returned is unknown in advance. We generally don't have commands > that work like that. > I'm not sure if the map/unmap flag will help the situation for the forensic examiner. What if SSD always returns zero for the unmapped area? (it's not violating the spec) Although the flag will tell you the exact state of the sectors, there is no hint for the forensic analysis if these are filled with zero. My personal opinion is that the flag for map/unmap will result in unnecessary overhead considering the common use cases. Please also consider that, although not directly related with trim, features like Full-Disk-Encryption are also making things difficult for you. -- Dongjun -- 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
