Hi Clemens, On Wed, 2014-02-05 at 21:47 +0100, Clemens Eisserer wrote: > > Moreover, if you have FTL then you > > expect that block layer will operate with 4 KB block sizes. Otherwise, > > it means that you sell bad storage devices. > > Efficient block sizes as small as 4K are only doable with a (DRAM) > cache, which isn't a viable solution for small/cheap devices - even > the best SD cards can't handle that efficiently. So those "bad storage > devices" are unfortunately a common reality (sd/mmc cards, usb pen > drives, ...). > > When looking through the raspberry pi forums, you'll find a lot > reports about dead SD cards, worn out where the ext4 journal or > metadata was placed. I admit this is a very specific example, but > quite a lot of embedded linux-powered solutions exist - and all of > them I know boot from (micro-)SD cards. So an improvement in this > situation (such as the mount option proposed by Andreas) could lower > the pain for this quite wide-spread use-case, without altering the > experience for present use-cases where nilfs2 does fine. Ok. I think that one of the possible another approach can be such. [1] We can place static superblock information (it is small size info) at the begin of every segment. It will be more FTL-friendly than static superblock at the begin and at the end of a volume. [2] We can use delayed mount. I mean that it is possible to make preliminary mount immediately without long searching or recovering. And to start recovering thread in the background for the search of latest log. Of course, in such way we haven't enough knowledge about whole volume state immediately and we need some time for searching last log in background. But, theoretically, we can access to information in RO mode on reliable portion of volume before ending of recovering process in background. But I understand that delayed mount is really arguable suggestion. :) [3] We can divide NILFS2 volume on allocation groups that it will contain several segments. And we can make searching of latest log on the basis of such allocation group, firstly. Then it will be used usual way of searching latest log inside a latest allocation group. [4] We can have special area, in likewise way as I suggested previously, that it can store special structures for more efficient search. This area(s) will store information about allocation groups. It will be recorded only on umount. This area information will be modified only in memory between mount and umount. And this area can be divided and saved by means of portions with size adequate to physical erase block size. I think it is possible to have configuration parameter of such portion size that can be used by user for tuning on mkfs or tunefs phases. Of course, it is really raw considerations. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
