Subject: Re: removing VOPs
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Jonathan Stone <jonathan@Pescadero.dsg.stanford.edu>
List: tech-kern
Date: 09/27/2005 17:30:13
In message <1127860302.790673.1659.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:


>> (If I ever find time, I intend to write a wrapfs for NetBSD-3 or
>> -current, assuming the FreeBSD-4 wrapfs is a useful starting point).
>
>i don't know much about FiST.
>in the vfs pov, it isn't different from arbitrary filesystems, is it?

With regret, circumstances force me to disagree with you.

Suppose we agree that supporting stackable filesystems is a desirable
goal. Consider stacking one filesystem -- a "wrapper" VFS, with
as-yet-undetermined extra semantics -- over an underlying VFS which
supports semantics like UFS holes, *and* associated growth
(allocation) of holes, *and* correctly implementing consistency
between, on the one hand, mmap()ed access and read()/write() access.

Once you start trying to make that work, I find that you very, *very*
quickly break what should be clean abstraction boundaries between
filesystem layers.  

I'm not sure my email skills are up to illustrating with a specific
case, right now; can I reply in more detail around noon tomorrow,
US/Pacific time?


>if they need redundant VOPs like VOP_TRUNCATE,
>i'd say their design is broken.



I'm not sure about that, either.  Before I tried to wrap my head
around FiST, and UFS, and holes, and mmap() consistency, I'd have
agreed with you. After my attempt, I'd prefer that we do our
due-diligence and check whether serious attempt to build stackable
filesystems really *do* end up needing to expose these nominally
filesystem-internal APIs between stacked-filesystem layers.

Is anyone who knows our vnode API really well (bill? chuck?) willing
to volunteer?