Hi Vyacheslav, > But, anyway, how 128 KB correlates with physical erase blocks or > physical writing units size? :) Physical sizes can be much more and 128 KB > unable to defend from all possible situations. Sure, there isn't good > approach for all cases of real life. I agree that modifying filesystem-code to work arround every single firmware quirk isn't a good idea. My enthusiasm stems from the fact that nilfs2 by design is as good as you can get on devices with weak FTL implementations - except for the frequent superblock updates. > 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. Rgerdas, Clemens -- 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
