--EuxKj2iCbKjpUGkD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 26, 2005 at 01:35:30PM +0200, Pavel Cahyna wrote:
> On Tue, Jul 26, 2005 at 01:24:12PM +0200, Zeljko Vrba wrote:
> > Pavel Cahyna wrote:
> > >
> > >You also said that you can't do even a ls -l when this happens. Where =
is
> > >that ls -l command blocked at that moment?
> > >
> > That 'ls -l blocks' is conditional. I have the large mmaped file on
> > /mnt/data (a separate filesystem). ls -l in /usr works, ls -l on

/mnt/data/foo is locked, so an ls -l on /mnt/data will block. Once that=20
happens, an ls -l on /mnt (or ls on /mnt/data) will lock /mnt/ Then an ls=
=20
-l on / or ls in /mnt will lock root. Then everything stops. It's called=20
the race for root and in why you never want to hang onto a vnode lock for=
=20
long.

> So, your previous claims that "everything just stops" was a bit exaggerat=
ed
> :-)

I've used systems like this, and even w/o the file system locking, things=
=20
can bog down. So it isn't too much of an exageration. ;-)

> > /mnt/data blocks. I guess because the large mmaped file is exactly in
> > /mnt/data. ls is also blocked in vnlock.
>=20
> Interesting. By "exacly in", you mean in the /mnt/data directory, right?
>=20
> What would happen if you did ls -l in the same filesystem, but in a
> different directory than /mnt/data?

If no lookup tried to grab or stat the DB file, things are fine. If a=20
lookup has blocked on it and holds another lock, the race for root is on.

Take care,

Bill

--EuxKj2iCbKjpUGkD
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFC5sh6Wz+3JHUci9cRAgUAAJwKvzdsbXHQJgfpNYDkPg7U7vxJ5QCcDAL1
6We97a/l4+nsqYEFQ7P0N7A=
=+Yog
-----END PGP SIGNATURE-----

--EuxKj2iCbKjpUGkD--