Linked by Thom Holwerda on Sat 6th Oct 2012 13:59 UTC, submitted by robojerk
Permalink for comment 537748
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2005-07-08
A log-structured filesystem is not necessarily a bad design choice for FTL volumes. You don't need to worry about wear-leveling, but you don't need to worry about spatial locality either, and you know that the FTL will override any attempts to do in-place updates.
So you can only really optimize two things: allocating free (logical) blocks for writes, and indexing file extents for reads. Log-structured filesystems are as good as it gets for allocating free space (just continue writing where we left off), and they also avoid the fragmentation of files across many extents.
The only thing one might want to do differently than a classic log-structured filesystem is to update the superblocks and inodes in-place and defer to the FTL's wear-leveling algorithm. These are fixed block-sized structures, so in-place updates are simple and copy-on-write is an unnecessary overhead.