Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Apr 2010 12:26:45 +0200 (CEST)
From:      "=?ISO-8859-15?Q?Luk=E1=A8_Czerner?=" <czerner.lukas@gmail.com>
To:        Gleb Kurtsou <gleb.kurtsou@gmail.com>
Cc:        freebsd-hackers@freebsd.org, =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= <czerner.lukas@gmail.com>
Subject:   Re: How to change vnode operations ?
Message-ID:  <alpine.DEB.1.10.1004241215530.7101@a04-0215a.kn.vutbr.cz>
In-Reply-To: <20100423092257.GA2446@tops>
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> <20100423092257.GA2446@tops>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-978661209-1272104807=:7101
Content-Type: TEXT/PLAIN; charset=utf-8
Content-Transfer-Encoding: 8BIT

On Fri, 23 Apr 2010, Gleb Kurtsou wrote:

> Date: Fri, 23 Apr 2010 12:22:57 +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 (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.

This is exactly how I feel about it and I am glad that you actually
confirm that, so thank you. Now I am convinced to use stacked
filesystem.

But I have one last question, though. It may be stupid, but when I
am looking at your pefs I can not figure out how you manage to mount
directory above itself. I am staring at the code and just do not see
that. It seems to me, like the check is done before the
{pefs|nullfs}_mount is even called. Can you point me out to the
right direction ?

Thanks again!
-Lukas.
--8323329-978661209-1272104807=:7101--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.DEB.1.10.1004241215530.7101>