Log-structured file systems: There's one in every SSD
Log-structured file systems: There's one in every SSD
Posted Sep 19, 2009 15:23 UTC (Sat) by butlerm (subscriber, #13312)In reply to: Log-structured file systems: There's one in every SSD by dlang
Parent article: Log-structured file systems: There's one in every SSD
of respects, one of which is particularly bad for SSDs. The other problems
are well described in the original article - a black box interface to obscure
what is definitely not a black box. Switch manufacturers, and you could have
entirely different performance characteristics in a manner that could take to
months to evaluate.
The only way SATA/SAS physical interface would work well for SSDs is to
develop an entirely new command set that allowed the off-loading of virtually
all the intelligence to the host, i.e. presenting a flash memory interface
rather than a disk interface over the serial bus. At that point you really
couldn't call it a SATA "disk" any more, it would be more like a large
capacity SATA "memory stick". That is the way it should be.
Posted Sep 19, 2009 19:55 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
the black box argument doesn't apply to a open DIY product like was being proposed.
I don't see why the host needs to address the raw flash. the problem is that there is currently zero visability to how the flash is being managed. if you had access to the source running on the device, why would you have to push all those details back to the OS?
Posted Sep 20, 2009 6:55 UTC (Sun)
by butlerm (subscriber, #13312)
[Link]
I don't think do-it-yourself has anything to do with it - the question is
Log-structured file systems: There's one in every SSD
Log-structured file systems: There's one in every SSD
the platter, and which ones. There are no write barriers, the command to
flush the cache can't be queued, and Force Unit Access write commands
generally flush all other dirty data as well, making them slow to the degree
that no one uses them. All this stuff is important for reliable operation of
modern filesystems and databases, especially in portable devices.
whether the person(s) concerned want to re-implement what other companies are
already doing with no obvious advantage, or do something that could
potentially run circles around current devices, if only due to the
flexibility and performance characteristics of the interface. A single level
filesystem ought to outperform one filesystem on top of another filesystem
every time.