Re: SSD data reliable vs. unreliable [Was: Re: Data Recovery from SSDs - Impact of trim?]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux