Date: Wed, 18 Aug 1999 11:59:01 -0700 (PDT) From: Bill Studenmund <wrstuden@nas.nasa.gov> To: Terry Lambert <tlambert@primenet.com> Cc: Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: BSD XFS Port & BSD VFS Rewrite Message-ID: <Pine.SOL.3.96.990818112953.14430G-100000@marcy.nas.nasa.gov> In-Reply-To: <199908181819.LAA14096@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Aug 1999, Terry Lambert wrote: > > Right. That exported struct lock * makes locking down to the lowest-level > > file easy - you just feed it to the lock manager, and you're locking the > > same lock the lowest level fs uses. You then lock all vnodes stacked over > > this one at the same time. Otherwise, you just call VOP_LOCK below and > > then lock yourself. > > I think this defeats the purpose of the stacking architecture; I > think that if you look at an unadulterated NULLFS, you'll see what I > mean. Please be more precise. I have looked at an unadulterated NULLFS, and found it lacking. I don't see how this change breaks stacking. > Intermediate FS's should not trap VOP's that are not applicable > to them. True. But VOP_LOCK is applicable to layered fs's. :-) > One of the purposes of doing a VOP_LOCK on intermediate vnodes > that aren't backing objects is to deal with the global vnode > pool management. I'd really like FS's to own their vnode pools, > but even without that, you don't need the locking, since you > only need to flush data on vnodes that are backing objects. > > If we look at a stack of FS's with intermediate exposure into the > namespace, then it's clear that the issue is really only applicable > to objects that act as a backing store: > > > ---------------------- ---------------------- -------------------- > FS Exposed in hierarchy Backing object > ---------------------- ---------------------- -------------------- > top yes no > intermediate_1 no no > intermediate_2 no yes > intermediate_3 yes no > bottom no yes > ---------------------- ---------------------- -------------------- > > So when we lock "top", we only lock in intermediate_2 and in bottom. No. One of the things Heidemann notes in his dissertation is that to prevent deadlock, you have to lock the whole stack of vnodes at once, not bit by bit. i.e. there is one lock for the whole thing. > > Actually isn't the only problem when you have vnode fan-in (union FS)? > > i.e. a plain compressing layer should not introduce vnode locking > > problems. > > If it's a block compression layer, it will. Also a translation layer; > consider a pure Unicode system that wants to remotely mount an FS > from a legacy system. To do this, it needs to expand the pages from > the legacy system [only it can, since the legacy system doesn't know > about Unicode] in a 2:1 ratio. Now consider doing a byte-range lock > on a file on such a system. To propogate the lock, you have to do > an arithmetic conversion at the translation layer. This gets worse > if the lower end FS is exposed in the namespace as well. Wait. byte-range locking is different from vnode locking. I've been talking about vnode locking, which is different from the byte-range locking you're discussing above. > > Nope. The problem is that while stacking (null, umap, and overlay fs's) > > work, we don't have the coherency issues worked out so that upper layers > > can cache data. i.e. so that the lower fs knows it has to ask the uper > > layers to give pages back. :-) But multiple ls -lR's work fine. :-) > > With UVM in NetBSD, this is (supposedly) not an issue. UBC. UVM is a new memory manager. UBC unifies the buffer cache with the VM system. > You could actually think of it this way, as well: only FS's that > contain vnodes that provide backing should implement VOP_GETPAGES > and VOP_PUTPAGES, and all I/O should be done through paging. Right. That's part of UBC. :-) Take care, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.96.990818112953.14430G-100000>