From owner-freebsd-fs@FreeBSD.ORG Fri May 16 10:33:54 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA33237B401 for ; Fri, 16 May 2003 10:33:54 -0700 (PDT) Received: from sbcs.cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id E015343F75 for ; Fri, 16 May 2003 10:33:53 -0700 (PDT) (envelope-from harikesa@cs.sunysb.edu) Received: from compserv2 (compserv2 [130.245.1.58]) by sbcs.cs.sunysb.edu (8.12.3/8.12.3) with ESMTP id h4GHUmXY021427 for ; Fri, 16 May 2003 13:30:48 -0400 (EDT) Date: Fri, 16 May 2003 13:30:50 -0400 (EDT) From: Harikesavan Krishnan X-X-Sender: harikesa@compserv2 To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Problem with Flags on fist X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 17:33:55 -0000 Hi, We're working on porting fistgen (stackable templates) from freebsd 4.x to FreeBSD 5.0. I'm facing a small problem while renaming inside any of my stackable file systems (such as cryptfs, rot13fs, etc.). To achieve full stacking transparency, we keep a componentname structure in our layer, as well as the lower layer. We have some code that tries to check the cnp->cn_flags fields in the two layers. We found that the flags differ in both 4.x and 5.x: we're not sure why, or whether this is a bug. It doesn't cause anything bad that we've noticed, and we ran a large compile, fsx, bonnie, etc. repeatedly. Here's the code snippet: static int cryptfs_rename(ap) struct vop_rename_args *ap; { vnode_t *thisfdvp = ap->a_fdvp; vnode_t *thistdvp = ap->a_tdvp; // some code follows thisfcnp = ap->a_fcnp; lowerfcnp = cryptfs_new_cnp((thisfdvp), thisfcnp); ap->a_fcnp = lowerfcnp; error = cryptfs_bypass((struct vop_generic_args *) ap); if ((thisfcnp->cn_flags & PARAMASK) != (lowerfcnp->cn_flags & PARAMASK)) { printk("%s: FLAGS CHANGED fthis:0x%x flower:0x%x", __FUNCTION__, (int)thisfcnp->cn_flags, (int) lowerfcnp->cn_flags); } ... } The flag values of the upper and lower layers are as follows: thisfcnp->cn_flags = 0x209410 which is: (PDIRUNLOCK | ISLASTCN | SAVESTART | HASBUF ) lowerfcnp->cn_flags = 0x940c which is: (ISLASTCN | SAVESTART | HASBUF) These are the same flag values that we've noticed when running stackable f/s based on our 4.x templates. However, in fbsd 4.x, the flags always match, and the above printk "FLAGS CHANGED" is never printed. Once we ported the templates to 5.0, this printk started showing up. We did notice that the value of PARAMASX in 5.0 is different. Fortunately, the bug is quite reproducible: mount the f/s, and rename a file inside of it (same result whether the file existed or not). So our questions are: 1. Is it ok to leave the code as is, or is there something wrong we're doing that may bite us later? 2. what could be causing the change in flags? Are we doing something wrong in ->rename, or somewhere else we're not setting something right? 3. any advise on how to fix the code? BTW, this is the last issue we have left before we can release a new version of fistgen that includes fully working, brand new, templates for freebsd 4.x and 5.0. Thanks, Hari and Erez.