Re: very large mount time after unxepected power down

[Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html