In fact, you are both right and wrong at the same time. NWFS is not
dependent on a mirroed cache and hotfix/mirroring are architecturally
separate (Hotfix and mirrroing ARE independent of NWFS even in Netware),
however, there are fault tolerant dependencies that allow NWFS to handle
some very complex data failure and recovery conditions not available
with most other FS's. It is possible to implement without it, but then
NWFS is not complete. Netware allows mirrored objects at a cache
level. There is also a very clean layer between disks and cache, unlike
Linux, which is quite frankly a big, nasty ***MESS*** between the disk
drivers and the buffer cache. There's no obvious method of supporting
async callbacks (which will increase file system performance by several
hundred percent).
All I am suggesting is that we adopt a semantic similiar to what's in NT
and Netware today rather than stay stuck with a non-extensible
architecture.
Jeff
.
Alan Cox wrote:
>
> > On Mon, 1 Nov 1999, Jeff V. Merkey wrote:
> > > We basically need a smarter cache than what's there. Eventually, Linux
> > > will evolve there (Since the page cache already resembles what's in NT).
> >
> > Jeff, I know that it sounds extremely snub, but get a different
> > background, please. Make yourself aware of the existence of other Unices.
> > Page cache similar to the new Linux one was there in *BSD for years. You
>
> There are actually fundamentally good reasons for not smartening the cache
> in this case too.
>
> Take the NWFS mirroring and hot fixing. Now there are two cases
>
> 1. It is so tied to NWFS that it depends on NWFS. In which case it is
> inappropriate to burden the buffer cache with it. In fact it might be
> appropriate instead to ask "what is in the buffer cache that is for
> ext2 only and should be in ext2"
>
> 2. The NWFS mirroring and hot fixing can work with other file systems with
> some simple hooks. In which case it belongs in the driver layer like
> the raid code so that you can drop any file system over it and get the
> benefits it apparently has.
>
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/