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]

 



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
--
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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux