| |||||||||||||
|
| |||||||||||||
Log-structured file systems: There's one in every SSDLog-structured file systems: There's one in every SSDPosted Sep 19, 2009 19:55 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: Log-structured file systems: There's one in every SSD by butlerm Parent article: Log-structured file systems: There's one in every SSD
the only problem I have heard of is the fact that trim is not a NCQ command. what are the other problems?
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?
(Log in to post comments)
Log-structured file systems: There's one in every SSD Posted Sep 20, 2009 6:55 UTC (Sun) by butlerm (guest, #13312) [Link]
The other major problem is effective control over when blocks physically hit
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.
I don't think do-it-yourself has anything to do with it - the question is
|
|
||||||||||||