Hi, On Tue, 2012-11-27 at 12:58 +0300, Сергей Александров wrote: > As I expected, no new info: > [57291.417113] NILFS warning: mounting unchecked fs > [57291.417125] NILFS: nilfs_search_super_root > [57291.417132] NILFS: pseg_start 115603456, seg_seq 4347757 > [57291.417137] NILFS: cno 1252241, segnum 56447 > [62768.349242] NILFS: recovery complete. > [62768.351804] segctord starting. Construction interval = 5 seconds, > CP frequency < 30 seconds > > So, I suppose, nilfs is searching for a super root for a very long > time and find's out that it is consistent. Currently, I have such picture of the issue's nature. The key details are: (1) long system uptime; (2) sudden power-off; (3) special case of interrelation of s_last_pseg fields in primary and secondary superblocks. This combination of factors leads to the situation when the issue takes place. The NILFS2 volume has two superblocks (primary and secondary). Only one superblock is active after filesystem mount and to keep actual superblock state. Another superblock keeps previous superblock's state and previous value of s_last_pseg field. When it is detected an invalid state of log for the value of s_last_pseg in actual superblock then it makes trying to search a previous valid supper root block. If we have previous value of s_last_pseg in another superblock then it is possible to find previous valid super root by means of passing through the chain of log starting from the s_last_pseg of backup superblock. Usually, all works fine for the case when the s_last_pseg field in actual superblock is greater than s_last_pseg field in backup superblock. So, if we have other situation (s_last_pseg field of actual superblock is lesser than s_last_pseg field of backup superblock) then it needs to pass through logs' chain from the end of volume to the volume begin. Such logic results in the issue only when we have s_last_pseg field of actual superblock is lesser than s_last_pseg field of backup superblock and a slightly small difference in values. So, for the case if s_last_pseg of actual superblock has 115603456 and s_last_pseg of backup superblock has 160163840 values then we need to passing through the whole volume starting from the end. I think that a proper fix of the issue is to make periodic flushing of backup superblock in the case of long system uptime with the purpose to have reasonable difference between of s_last_pseg field of actual superblock and s_last_pseg field of backup superblock. I am going to fix the issue in such way. With the best regards, 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
