From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 27 10:59:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0280106566C for ; Tue, 27 Apr 2010 10:59:01 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 48B448FC13 for ; Tue, 27 Apr 2010 10:59:00 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so2160982fge.13 for ; Tue, 27 Apr 2010 03:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BAT+oBei8w7+bCkMIQ4w6uedLsJEo3bHIDO4hZheBYQ=; b=vecnYtTHqi6Y9MzEOZWtU8ut4pQxKKtu2Z00w8lUa+Zsu+3PzVHeHxzQQxHe+tKI+l irFQurLd4xmRa6yUBPSAfdSRb6TR6EJMdiVode9PZTe/MPrhje7XQc1jJZGRQVfoWPMF kgw+IKE2fESqatzST3gjlnk1W57KvhluHz3I8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=YY6Tg9GLceNYVMmZBaYFHjqDeeqbot6xE82msLuytLOEc7vyF3f7g6xBmTr8dkSMXv lNDZDdh8g+izYYX5YHUv1x80n9q3Ilt9iFgruR4g+z+0QBJP+cnWVasLFPgstu4dCTS+ p2jDu25c/ldj8aa5/+ANfnKhAX677u6lVC/GA= Received: by 10.87.63.21 with SMTP id q21mr5161246fgk.52.1272365934903; Tue, 27 Apr 2010 03:58:54 -0700 (PDT) Received: from localhost ([91.187.8.184]) by mx.google.com with ESMTPS id 28sm5145871fkx.6.2010.04.27.03.58.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 03:58:53 -0700 (PDT) Date: Tue, 27 Apr 2010 13:58:48 +0300 From: Gleb Kurtsou To: =?utf-8?B?THVrw6HFoQ==?= Czerner Message-ID: <20100427105848.GA2003@tops> References: <20100422191849.GA9895@tops> <20100423092257.GA2446@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: How to change vnode operations ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 10:59:01 -0000 On (24/04/2010 12:26), Lukáš Czerner wrote: > On Fri, 23 Apr 2010, Gleb Kurtsou wrote: > > > Date: Fri, 23 Apr 2010 12:22:57 +0300 > > From: Gleb Kurtsou > > To: Lukáš Czerner > > 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 > > > > To: Lukáš Czerner > > > > 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 ? It's nullfs that forbids it. VFS is fine about mounting on top of the same directory. As far as I remember lower vnode should be unlocked to prevent locking against itself and pefs_lock and pefs_unlock had to be adjusted to support it. Do not remember specifics, sorry. I do 'pefs mount /home/gleb /home/gleb' since October, it works for me. > > Thanks again! > -Lukas.