[Tux3] Tux3 kernel port - about ext2_get_inode

[Daniel Phillips]

>From here on we will be trying to stick somewhat close to the design
factoring typical of Linux filesystems, as exemplified by Ext2 and
Ext3.  The immediate effort is to make Tux3's open_inode fill the role
of Ext2's ext2_get_inode.

We see that ext2_get_inode is called from only two places:

   http://lxr.linux.no/linux+v2.6.26.3/+ident=14702139

References:
	fs/ext2/inode.c, line 1104 <- definition
	fs/ext2/inode.c, line 1205 <- called from ext2_iget
	fs/ext2/inode.c, line 1316 <- called from ext2_update_inode

In general, *_iget is used to create or retrieve an inode from backing
store and *_update_inode is used to sync an inode to backing store.  In
the first case a new, empty vfs struct inode is created immediately at
the beginning of the process and in the second, the struct inode
already exists.  This suggests a slightly different factoring than Ext2
uses that better reflects the fact that Tux3's method of finding its
way to an inode on disk is considerably more involved than Ext2's, and
that Ext2 has separate bitmaps dedicated to allocating inodes which
allow it to avoid reading the any actual inode table blocks until later
when the new inode has to be synced to disk.

A quick tour of ext2 functions that create inodes:

Look up an inode:

   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/namei.c#L66
   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/namei.c#L73

Get the root directory

   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/super.c#L1044

Weird NFS hack:

   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/super.c#L330

Create a new inode

   ext2_new_inode(dir, mode);

which uses ialloc, looking only at the inode bitmaps, to create a new inode.
But in Tux3 we dive down into the inode btree itself to allocate an inode,
just as we do when we look it up or update it.  We want a somewhat different
factoring to reflect this.

Skeleton code for Ext2:

   inode = ext2_<various creates>
      inode = ext2_new_inode(dir, mode)
         inode = new_inode(sb)
         inum = ialloc(dir)
      ext2_add_link(...)

   inode = ext2_iget(sb, name, len)
      inode = iget_locked(sb, ino)
      <return cached inode unless inode is marked new>
      ext2_get_inode(inum, &buffer)

   ext2_update_inode(inode)
      ext2_get_inode(inum, &buffer)
         <write attrs to buffer data>
      <sync buffer>

Skeleton code for Tux3:

   inode = tux3_<various creates>
      inode = tux3_create(sb, name, len, iattrs)
         inode = new_inode(sb)
         tux3_get_inode(inum, &buffer, iattrs)
            <encode new attrs to buffer>
         tux3_create_entry(dir, name, len...))

   inode = tux3_iget(sb, name, len)
      inode = iget_locked(sb, ino)
       <return cached inode unless inode is marked new>
      inode = tux3_open(sb, name, len)
         tux3_get_inode(inum, &buffer, NULL)

   tux3_isync(inode)
      tux3_get_inode(inum, &buffer, NULL)
         <decode saved attrs from buffer
         <compare to attrs in inode
         <encode changed attrs to buffer>
      <sync buffer>

So tux3_get_inode is to combine functionality of three ext2 functions:
ext2_new_inode, ext2_get_inode and ext2_update_inode.  This places the
inode btree handling logic (lookup, create and update) in exactly one
place, and also centralizes the attribute encoding and decoding, which
is considerably more complex than Ext2's.  Still, we stay quite close
to Ext2's structure.  If we can keep achieving small victories like
that then the kernel port should be pretty easy.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3