From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 23 09:23:05 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 D3B66106566C for ; Fri, 23 Apr 2010 09:23:05 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 5DED18FC1C for ; Fri, 23 Apr 2010 09:23:04 +0000 (UTC) Received: by ewy24 with SMTP id 24so2763156ewy.33 for ; Fri, 23 Apr 2010 02:23:04 -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=CvuXbmPk9uUImhZ5t9i+pDUVuezZdj4LFLNiQ/yo2Yc=; b=YVD6hg5JyIZMP7X60DUSr1J2zCPnlMcVhyM5DIHiFkBX5xmZn8pqvzjqlh6JjVIvZr Jk9IrZTycfCDztjwlh3QJEmReRe2RenotmZrMrN3rEML1kk7DFIFSSBT1tt0vBoIgWZh NI0JshJOh9VSBhyBFMuntSf091Hj+eRy5GnSY= 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=ZbwCDoTewVgQOfRRdhK7MvOf2GreMXLA/FJVnJIvKgGSowZpZGRmOjpKp9RBTy4QEf TLLDV8i18DQ6SVMvW6r5l2agfmDGtmINdB8rQERkIzfTc7BnjX8QXLIVyT5A7QnekE8T 6EcwuGAx+naKnRsjtPU6LgK9ZPAn+HUCYIzjM= Received: by 10.102.237.35 with SMTP id k35mr3171720muh.72.1272014583981; Fri, 23 Apr 2010 02:23:03 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id 18sm1572693fkq.34.2010.04.23.02.23.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 02:23:03 -0700 (PDT) Date: Fri, 23 Apr 2010 12:22:57 +0300 From: Gleb Kurtsou To: =?utf-8?B?THVrw6HFoQ==?= Czerner Message-ID: <20100423092257.GA2446@tops> References: <20100422191849.GA9895@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: Fri, 23 Apr 2010 09:23:05 -0000 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. Thanks, Gleb. > Thanks. > -Lukas