Date: Thu, 15 Feb 2007 14:08:55 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Tomas Olsson <tol@it.su.se> Cc: freebsd-fs@freebsd.org, arla-drinkers@stacken.kth.se Subject: Re: Arla on FreeBSD Message-ID: <20070215120855.GE39168@deviant.kiev.zoral.com.ua> In-Reply-To: <lsrhctn6393.fsf@kashyyyk.ite.kth.se> References: <eqsut3$6a3$1@sea.gmane.org> <20070213192906.U726@chrishome.localnet> <20070214162938.GA96725@keira.kiwi-computer.com> <20070214173211.L1054@chrishome.localnet> <20070214170808.GC96725@keira.kiwi-computer.com> <lsrvei45pq1.fsf@kashyyyk.ite.kth.se> <20070215044707.GA39168@deviant.kiev.zoral.com.ua> <lsrmz3f680v.fsf_-_@kashyyyk.ite.kth.se> <20070215104537.GC39168@deviant.kiev.zoral.com.ua> <lsrhctn6393.fsf@kashyyyk.ite.kth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070215120855.GE39168>