Subject: Re: Redoing file system suspension API (update)
To: None <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/26/2006 14:31:44
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 26, 2006 at 08:30:20PM +0200, Juergen Hannken-Illjes wrote:
> On Mon, Jun 26, 2006 at 09:43:59AM -0700, Bill Studenmund wrote:
> > On Sat, Jun 24, 2006 at 11:05:04AM +0200, Juergen Hannken-Illjes wrote:
> > > On Fri, Jun 23, 2006 at 05:14:00PM -0700, Bill Studenmund wrote:
> > > >=20
> > > > Especially if we go with the idea of having the file system grab an=
> > > > release the mountpoint-transaction-lock (the current incarnation of=
> > > > "gate" you spoke of originally, the thing that makes us atomic w.r.=
> > > > snapshot), then it's not a problem. We just have the read and write=
> > > > in fifofs not take the transaction lock, and we're fine.
> > I'm sorry, but this is an important point. I have the feeling it was=20
> > missed.
> Not sure I get it right: you mean taking the transaction lock for
> read/write/ioctl in every file system while taking it for other operations
> Looks difficult to maintain.
How is it difficult to maintain?
The idea is that we only use transaction locks above the file system if we
have a real transaction.
> > > > Such a change would limit our exposure to cases where someone is tr=
> > > > make a transaction that involves writing to or reading from a fifo.=
> > > > try to do that, you get what you get.
> > >=20
> > > Both specfs and fifofs need special care because they are no real fil=
> > > Their vnodes live in real file systems that may update meta data befo=
> > > after they call operations on specfs/fifofs. These updates need the =
> > > lock. The real operations (as long as they dont go to disk devices) =
> > > keep this lock because they may sleep forever waiting for data.
> > How many transactions, other than an actual write or read, will write o=
> > read a fifo?
> Its not only fifo, it is also non-disk VCHR and VBLK devices. This infor=
> is currently hidden outside VFS.
> Unlocking/relocking in specfs/fifofs would be the same it is now. Curren=
> there is already a VOP_UNLOCK/VOP_LOCK in specfs/fifofs.
vn_lock() isn't a transaction lock, we use it as an atomicity lock. So as=
long as you don't unlock/relock in the middle of your atomic operation.=20
i.e. you unlock/lock either before or (if you're weird) after the "read"=20
or the "write", you're fine. I'm assuming POSIX atomicity here.
> > Thus if we move the transaction/snapshot logging into the read or write
> > call, we have fifofs and specfs skip that step, and we're fine.
> See above. I think it is easier to maintain if we try to keep the transa=
> lock completely outside of file systems.
Then we need buckets of them. If I understood your earlier discussions, we=
then need transaction locking around every caller into the VFS/VOP layer.=
That seems messier to maintain.
> > What do other OSs do?
> No OS I know of has something like this. Do you have a special OS in min=
Yes, they don't have this. But other OSs handle snapshotting. How do they=
handle the suspension? Do they bother? If so, how do they do it? If they=20
don't, why do we have a problem and they don't?
We're adding a new locking hierarcy. I think we should look at prior art=20
before we go too far. If we need the new hierarcy, we will do it. But=20
let's make sure we didn't overlook a cool idea somewhere else first.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----