Hey Herbert, On Sat, Jun 10, 2006 at 02:32:53PM +0200, Herbert Poetzl wrote: > did a first hack on adding the iattrs (ext2) to OCFS2. it is currently for > Linux-VServer patched kernels and I need to clean it up a little more (and > of course test it), but I thought I'd ask you folks what you think about > the general idea and the implementation. Well it definitely looks like things are going in a good direction :) How many of these attributes were you planning to implement by the way? I'm thinking we probably want to cover at least some of the basics - immutable, appends... Maybe the vfs already handles those for us - I'll have to read more code to figure that out. Patch comments below.
> here is a link to the patch, if there is some > interest from your side, I'll prepare one for > mainline ... > > http://vserver.13thfloor.at/Experimental/delta-ocfs2-feat01.diff You probably want to move the cluster lock in the OCFS2_IOC_SETFLAGS case up a bit so that you can be sure your inode image is up to date within the cluster. Similarly, you'll probably want to take a read-only meta data lock in the OCFS2_IOC_GETFLAGS case. OCFS2 makes use of a small area associated with locks (called a Lock Value Block) to stuff commonly used inode information. This helps the file system avoid a disk read when updating inode information due to a new lock acquiry - ocfs2_meta_lock_update() is the function responsible for this. These new attributes should be put in the lvb as we'll want to be able to test their existence by checking the struct inode under cluster lock (as opposed to having to read off disk and checking the disk inode flags). Luckily this is pretty easy - you already handled the disk cases by updating ocfs2_populate_inode() and ocfs2_refresh_inode(). The lvb is a similar process. I'll outline the steps below. At the top of dlmglue.h you'll see the ocfs2_meta_lvb structure definition. Just go ahead and take some of the reserved fields for our purposes. Be sure to bump the value of OCFS2_LVB_VERSION so that node which don't understand the new field know just to ignore the lvb. The next step is to update __ocfs2_stuff_meta_lvb() to understand how to write the values into the lvb, and ocfs2_refresh_inode_from_lvb() to take them from the lvb into the inode. We only need to stuff these new flags into the lvb btw, so don't worry about the other ocfs2_dinode->i_flags - they're not nearly as dynamic and aren't really checked anywhere we won't already be using the disk. I'm thinking about whether we want to mark the existence of this feature in the superblock (probably as a compat flag). More on this later I suppose. > note: some attributes (like the noatime) do not (yet) make sense for > OCFS2, It's just a generic approach ... Right. What's up with the OCFS2_BARRIER_FL and OCFS2_IUNLINK flags? Am I correct when I don't notice those in ext3? Thanks! --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
