Date: Mon, 8 Nov 2010 16:07:29 +0100 From: Ivan Voras <ivoras@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: The state of Giant lock in the file systems? Message-ID: <AANLkTi=B3D=tv81ewPQbWMm4xH5sYzWFX3hbPY72R=ug@mail.gmail.com> In-Reply-To: <201011081004.59640.jhb@freebsd.org> References: <ib8qda$nat$1@dough.gmane.org> <201011081004.59640.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 November 2010 16:04, John Baldwin <jhb@freebsd.org> wrote: > On Monday, November 08, 2010 7:28:26 am Ivan Voras wrote: >> I was looking at fusefs sources and there is a dance it does with the >> Giant lock which looks fishy. >> >> Grepping for "-ir giant" in /sys/fs on 8-stable shows only a handful of >> mentionings, but if I understand it correctly only these "active" instan= ces: >> >> 1) one set of mtx_assert() calls on it in pseudofs, which I can't figure >> out what they're guarding >> 2) some manual locking and unlocking in nfsclient which appears to only >> guard printf() (???) >> 3) some more locking in nfsserver which apparently is only there to >> guard the underlying local file system >> 4) coda, which appears to be the only one marked with D_NEEDGIANT, but >> doesn't do much of its own interfacing with it >> >> Except for these, is there any more magic that would need to be resolved >> to excise Giant from VFS? >> >> Would it be correct to think that coda is the single biggest obstacle? > > Err, all the VFS_LOCK_GIANT() stuff for filesystems that do not have > MNTK_MPSAFE set. =C2=A0I believe the currently MPSAFE fs's are UFS, ZFS, = MSDOSFS, > CD9660, UDF, NFS client, and devfs. =C2=A0I think all others are !MPSAFE = still. Thanks! It seemed too easy to be true.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=B3D=tv81ewPQbWMm4xH5sYzWFX3hbPY72R=ug>