On Thu, 30 Jan 2014 07:29:14 +0100, Andreas Rohner wrote: > Hi Ryusuke, > > On 2014-01-30 06:29, Ryusuke Konishi wrote: >> Hi Andreas, >> On Thu, 30 Jan 2014 03:46:59 +0100, Andreas Rohner wrote: >>> Hi, >>> >>> This is only a hacky proof of concept implementation and probably >>> full of nasty bugs. I also havn't really tested it. I was >>> just interested how hard it would be to implement Clemens' suggestion >>> of writing the super block only at umount time and do a linear scan >>> of all the segments in case of file system failure. >>> The linear scan is only performed if the file system wasn't shut down >>> properly. So for normal operation there shouldn't be any slowdown. >> >> This premise is not acceptable. >> We have to avoid long mount time even after unexpected power failures. >> >> I prefer some sort of way which combines binary search of segment >> summary blocks and partial linear scan of logs. >> >> I don't know the latency of recent SSDs, however we should estimate >> the latency of disk I/O about 5ms~20ms per a separate block (in the >> case of hard drives). So the maximum number of scans of segment >> summary blocks seems to be roughly 10~100 times. >> >> Regards, >> Ryusuke Konishi > > Basically I agree with you. It was just a quick experiment. I just > thought Clemens suggestion, to have a mount option to turn on the linear > scan for users who want it, was worth a try. I see. For further discussion on this approach, it looks like we need some measurement data of the situation that this patch makes a difference (for example, for an SD card or some device). Anyway, I agree that the patch has a value for experiment purpose. Thanks, Ryusuke Konishi > br, > Andreas Rohner > >>> >>> I repurposed the ss_pad field of nilfs_segment_summary to contain the >>> crc seed, because I needed a way to distinguish left over segments >>> from previous nilfs2 volumes from real segments that are part of the >>> current file system. >>> >>> I don't really expect it to be merged or anything. Maybe it can spark >>> a discussion. Maybe somebody could try it out on an old SD-Card and >>> time the mount command or something. >>> >>> I tested it on a virtual machine. It seemed to recover fine when I >>> killed the VM and mounted it again. Clearly more testing is >>> necessary... >>> >>> br, >>> Andreas Rohner >>> >>> --- >>> Andreas Rohner (1): >>> nilfs2: add mount option that reduces super block writes >>> >>> fs/nilfs2/segbuf.c | 3 ++- >>> fs/nilfs2/segment.c | 3 ++- >>> fs/nilfs2/super.c | 10 +++++++-- >>> fs/nilfs2/the_nilfs.c | 54 ++++++++++++++++++++++++++++++++++++++++++++--- >>> include/linux/nilfs2_fs.h | 4 +++- >>> 5 files changed, 66 insertions(+), 8 deletions(-) >>> >>> -- >>> 1.8.5.3 >>> >>> -- >>> 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 >> -- >> 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 >> > > -- > 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 -- 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
