[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Further optimising mount time.

On Thu, 2003-07-10 at 13:02, David Woodhouse wrote:
> Other than forcing the mount to wait while we go through the entire
> dirent tree, I see two possibilities for dealing with this. Either we
> could just deal with it being inaccurate briefly, or we try to keep
> nlink as part of the _inode_ metadata, which I'm slightly reluctant to
> do for two reasons:
>    - It involves an incompatible change to the datanode struct.
>    - It's redundant information and can hence be inconsistent. Whether
>      write the metadata node with changed nlink before or after the 
>      dirent pointing to the inode in question, if you lose power in
>      between you still have an inconsistent state on the medium. So 
>      we'd still need to do the tree-walk _anyway_ to ensure complete
>      consistency.

Another possibility is to add sufficient information to the eraseblock
'tailer' to recreate this. Each dirent node will affect the nlink of
either one or two children -- it may cause a new link to an inode, and
it may obsolete a previous link to a different inode. For each dirent in
an eraseblock, you record in the 'tailer' the ino# of the two inodes
which are affected. 

At mount time, you can therefore construct for each inode on the system
a list of the inode numbers of any directories which _may_ contain links
to it and hence affect its nlink.

We're already said that read_inode() on a directory would sort out all
the dirents belonging to that directory and adjust nlink on the children
appropriately, so it follows that upon read_inode() for _any_ given
inode, you can calculate its nlink _accurately_ by calling first calling
read_inode() for every directory which may contain a link to it. 

There's a slight problem if you have eraseblocks _without_ a tailer,
since the physical dirent node on the medium doesn't actually contain
information about which, if any, inode the {pino,name} pair _used_ to
refer to. But you can fix this up in the second stage of the mount --
after the physical scan has completed, you then call read_inode() for
each directory which had any dirents in an eraseblock _without_ a
tailer, and the nlink of its children is therefore adjusted

You can further optimise this if necessary -- you don't actually have to
call read_inode() for any 'potential parent directory'; you only need to
do the part of read_inode() which sanifies the directory tree and
adjusts the nlink on the children -- in particular you don't have to
recurse and calculate nlink for the parent directory _too_ all the way
back up to the root of the tree.


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com