From owner-freebsd-fs@FreeBSD.ORG Thu Feb 15 12:09:20 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A20D16A476 for ; Thu, 15 Feb 2007 12:09:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id B34D913C49D for ; Thu, 15 Feb 2007 12:09:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HHfQE-000CEm-4a for freebsd-fs@freebsd.org; Thu, 15 Feb 2007 14:09:18 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l1FC8u4G001261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2007 14:08:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l1FC8uJa086319; Thu, 15 Feb 2007 14:08:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l1FC8tA3086318; Thu, 15 Feb 2007 14:08:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Feb 2007 14:08:55 +0200 From: Kostik Belousov To: Tomas Olsson Message-ID: <20070215120855.GE39168@deviant.kiev.zoral.com.ua> References: <20070213192906.U726@chrishome.localnet> <20070214162938.GA96725@keira.kiwi-computer.com> <20070214173211.L1054@chrishome.localnet> <20070214170808.GC96725@keira.kiwi-computer.com> <20070215044707.GA39168@deviant.kiev.zoral.com.ua> <20070215104537.GC39168@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: 9f090f397804869cf00fade203417d62 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 775 [Feb 15 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-fs@freebsd.org, arla-drinkers@stacken.kth.se Subject: Re: Arla on FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 12:09:20 -0000 --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 15, 2007 at 12:59:04PM +0100, Tomas Olsson wrote: > Kostik Belousov writes: > > On Thu, Feb 15, 2007 at 11:16:00AM +0100, Tomas Olsson wrote: > > > The interesting part is how we open and access the cache files, and f= rom > > > what context. arlad is in chroot() to avoid recursive lookups across = /, and > > > it seems like a good idea to avoid such lookups now too. > > >=20 > > > So the main question is how to properly do VOP_{LOOKUP,CREATE,WRITE} = etc on > > > cache files in this dual context world, without mixing identities in = bad > > > ways or confusing the OS too much. > > >=20 > > > The currently messed up code lives in > > > http://cvsweb.stacken.kth.se/cvsweb.cgi/arla/nnpfs/bsd/ > > >=20 > > > Most interesting is nnpfs_vnodeops-common.c (nnpfs_write_common()) and > > > nnpfs_blocks.c (open_file()) > >=20 > > I made really quick look at the places you mentioned. I have some > > comment for open_file(). For FreeBSD >=3D 6.x, the right way to open vn= ode > > from the kernel code is to use vn_open() (and then vn_close()) API. > > > Great! Sounds reasonable. >=20 > We currently open the cache files from nnpfs' VOPs, are there any risks > (deadlock?) involved if one passes an absolute path to vn_open() in such a > context? I'd have liked to do use arlad's thread for this, but vput() There, you already have nnpfs vnode locked. The right lock order for vnodes is from root down by the tree. As such, you may end up with reversals, that would result in deadlocks, IMHO. > explicitly uses curthread deep down in namei. Also, users are not normally > allowed to access the cache files directly so some OSes complain on such a > lookup with user creds; would that be a problem here? How is the user access to cache is disabled ? And what is the cache itself ? Local filesystem (UFS) that stores your blocks in regular files ? > Of course, we wouldn't have to worry about such things if we just kept the > vnode handy for each cache block file. Maybe it's a price worth paying. Then, you need to take some care of cached vnode lifecircle (e.g., even keeping the vnode vref'ed would not prevent it from being recycled, so you may end with dead vnode). Also, as Robert pointed out in his email, you probably need to decide about MP-safeness of nnpfs. --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF1E1WC3+MBN1Mb4gRAjHwAKD3lgPzIH72g875WHdlUurV/1V+6ACfU8Tr kelnnlG00zwmCocrwlHGy70= =xmly -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk--