Subject: Re: CVS commit: src
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/24/2004 20:11:02
Content-Type: text/plain; charset=us-ascii
On Fri, Jun 25, 2004 at 11:17:28AM +0900, YAMAMOTO Takashi wrote:
> > I'm not hearing, "I want to do X, but can't because of Y so I
> > want to change Y to Z." Those comments don't sound like the right way to
> > start out changing things.
> lfs sometimes need to wait for cleaning before starting
> an actual operation. it can't be done cleanly,
> because vnode lock is already held by upper layer.
> it's better to allow several operations for a directry concurrently.
> esp. for remote filesystems like nfs. it's not possible with mandatory
> vnode locks.
> so i want to change vnode locks (back) to advisory.
> or migrate to filesystem internal locks completely.
> (actually i don't want to do such changes for now.
> i'm just talking about the ideal world.)
> i thought that i said all of the above somewhere.
> sorry if it was not clear to you.
The what you want you'd said. The why had eluded (and from its absence,=20
concerned) me. Thank you.
> > If we didn't do the locking externally, we pretty much lock as soon as =
> > write starts, and unlock before exiting. Seems about the same to me. Ye=
> > we spend a few cycles fewer w/o the lock, but I don't think that, in an=
> > of itself, is much of a difference.
> consider synchronous writes.
> you can implement a simple VOP_WRITE as the following.
> 1. copy data to page cache and update some incore data.
> 2. start disk i/o.
> 3. wait for the i/o completion.
> for this filesystem, you don't likely want to prevent VOP_READ
> during 2 and 3.
You are probably right. I'm not sure if there ever were circumstances
where you'd want to wait. There may be, but I bet they'd be the rare case. =
Note also that you'd probably also be permitting writes while you're=20
In terms of getting to this, I think I'd much prefer moving to internal=20
locking. One of the bigest problems I encountered when getting layered=20
file systems working was ambiguity in what was was happeneing with=20
locking. So I pushed everything to use exclusive real locks; to be=20
consistent (and a bit facist). If we go to making locks advisory, I'm=20
concerned that things would get ambiguous again, and we're back in a mess.=
I'd actually much rather massive rototillage, in the expectation that we'd=
be changing so much that we'd have to pay attention to what we're doing,=20
and get it right.
Ironically, the next few months are the best time to do it. Something like=
this would be a major change, and could postpone the release after 2.0. So=
if it's going to happen, we're approaching one of the best windows to do=20
it in. ;-)
Anyone know how SystemV kernels handle this?
As a transition step, file systems could be changed to just add lock calls=
at the start of routines that now take unlocked vnodes, and unlocks at the=
bottom. So we change the interface, the callers, layered file systems, but=
not the leaf file systems. i.e. we're more likely to get things right. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----