Re: Further optimising mount time.

David Woodhouse <[email protected]>
Newsgroups gmane.linux.file-systems.jffs
Message-ID <[email protected]>
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
appropriately.

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.

-- 
dwmw2


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.