Date: Fri, 23 Apr 2010 12:22:57 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: =?utf-8?B?THVrw6HFoQ==?= Czerner <czerner.lukas@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to change vnode operations ? Message-ID: <20100423092257.GA2446@tops> In-Reply-To: <alpine.DEB.1.10.1004230756190.7101@a04-0215a.kn.vutbr.cz> References: <alpine.DEB.1.10.1004221559270.7101@a04-0215a.kn.vutbr.cz> <20100422191849.GA9895@tops> <alpine.DEB.1.10.1004230756190.7101@a04-0215a.kn.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On (23/04/2010 08:10), Lukáš Czerner wrote: > On Thu, 22 Apr 2010, Gleb Kurtsou wrote: > > > Date: Thu, 22 Apr 2010 22:18:49 +0300 > > From: Gleb Kurtsou <gleb.kurtsou@gmail.com> > > To: Lukáš Czerner <czerner.lukas@gmail.com> > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: How to change vnode operations ? > > > > On (22/04/2010 16:02), Lukáš Czerner wrote: > > > Hi all, > > > > > > this may sound a little odd, since I have noticed that there is much > > > work done to not allow such a thing ($SUBJ). But may be you can help > > > me and point me to the right direction. > > > > > > I am writing a kernel module with somewhat similar functionality > > > like nullfs has, BUT it has to have some features which nullfs > > > itself does not provide : > > > > > > 1. I need the new layer to completely hide underlaying layer so no > > > one can bypass it. > > Is hypothetic 'mount -t mynullfs /a /a' good enough for you? I'm not sure > > what your goals are but completely finding underlaying filesystem won't > > be easy because of VFS_GET, getfh and other stuff operating with inode > > numbers. > > Well, it may be good enough, or not. Thats what I am trying to find > out. Obviously there are problems, as you mentioned, which will not > exist when I change the vop_vector of the vnode, but as I thought > and you mentioned it as well, this is not very clean way. Why don't you like stacked filesystem approach? It's designed to solve the problem you are describing if I get it right. Although creating pefs-like filesystem altering data and names is not so easy within existing framework. > > > 2. Nullfs allows me to to overlay just one directory, but i want to > > > include another directories and/or exclude subdirectories/files. > > > 3. Nullfs just redirects vnode operations to lower layer, I need to > > > catch that operation, do something (for example alter the arguments > > > somehow etc..), pass the operation (with possibly altered arguments) > > > to the lower layer, get the result and then return the result. > > I'd suggest to take a look at pefs: http://github.com/glk/pefs > > It's cryptographic stacked filesystem for FreeBSD. It changes file > > names, hides directory entries, modifies data from lower layer > > (encrypts or decrypts), supports mounting on same directory, etc. > > Thats great, thanks! I will look at it. > > > > > > The best way to do that (I think) is to change vnode operations of > > > particular vnodes to point to functions defined in that module. At > > > this point, I can catch any operations with the vnode and this is > > > the base of what i want. > > > > > > So my question is. I there any "clean" way to chande vnode > > > operations ? If not, is there any "not so clean" way ? Anyway I will > > > appreciate any good idea how to do what I have described. > > Imho, stacked filesystem is the only right way to do it (see null, > > unionfs, pefs). > > OK. Thanks for pointing me to the pefs, it is interesting and looks > like a good start. But I would appreciate more comment on the side > of the whole idea about changing vnode operations from the kernel > module. It is a little hacky, but aside this I do not see any bigger > problems, do you ? Changing vop_vector is too hackish for me. Basically, changing vnode operations is what stacked filesystems are about. Vnode operations are the top of the problem, you would also have to deal with parent lookup, namecache consistency and buffering, which is going to be complicated. I.e. you'd have to partially reimplement part of VFS layer. nullfs and unionfs pass vnode vobject (buffering layer) from lower layer, adding your own vobject to vnode would complicate filesystem significantly. Besides you won't be able to assign 2 vobjects (original and your own) to a single vnode if you decide to change operations vector. Thanks, Gleb. > Thanks. > -Lukas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100423092257.GA2446>