Hi Clemens, On Jan 30, 2014, at 5:03 PM, Clemens Eisserer wrote: > Hi Vyacheslav, > >> The result of unclean shutdown and big update timeout will be a long >> mount. And such issue was reported earlier and it was fixed. I don't >> think that Andreas's patch can resolve long mount principally. Maybe >> this approach can slightly reduce mount time in such situation. > > So even without Andreas' patch there is no risk for data loss with a > very outdated superblock - but recovery would be slower? > Yes, recovery will be really slower. And recovery mechanisms defend from data loss in reasonable way. I mean that some data can be lost during unsuccessful flushes. But I am afraid that current state of Andreas's patch breaks some recovery mechanisms (but maybe I am wrong). >> In such case NILFS2 at whole is in trouble. Because partial segments can >> have different size. And these sizes doesn't correlate with sizes of >> physical erase block or physical writing units. And the whole COW >> approach is useless. > > Sure, NILFS won't cure the horrible write-amplification of those > devices, but it will spread the wear evenly over the whole device > thanks to COW. > So it won`t wear out the meadia faster where it`s metadata is stored > (with exception of the superblock) like ext4 does. > Btw. isn't nilfs's minimal writing size 128kb (I remember I read it in > a paper somewhere)? 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. 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. Thanks, Vyacheslav Dubeyko. > > Regards, 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
