Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: System V file systems
Message-ID: <367@auspex.UUCP>
Date: 31 Oct 88 20:36:20 GMT
Article-I.D.: auspex.367
References: <6413@daver.UUCP> <8332@alice.UUCP> <1988Oct27.173247.2789@utzoo.uucp> <8338@rpp386.Dallas.TX.US> <917@vsi.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27

>How hard is it for an instantiation of UNIX to support multiple
>kinds of blocksizes?

If you have the right buffer cache mechanism (or moral equivalent; cf.
SunOS 4.0, which uses the buffer cache only for control information,
using the pagins sytem for data caching), it's not that hard.

>I would think that keeping the blocksize in the superblock would make
>it pretty easy, so I could use 1k blocks for root, and (say) 8k for
>the /database partition with a dozen files all > 1MB.

That's basically what the BSD file system does.

>Currently it seems like a big deal for them to come out with a new
>supported blocksize.

That's because they *don't* have the right buffer cache mechanism, and
have to hack in a new buffer cache for 2KB file systems (although at
least both buffer caches are sort of subclasses of a more general
"buffer cache" class, so they do get to share some code).

With any luck, S5R4 will have the right buffer cache mechanism, namely
the BSD one (i.e., with any luck, they'll put the V7/S5 file system on
top of it, rather than having *both* the BSD *and* the V7/S5 buffer
cache to support the two different file systems), or moral equivalent
(cf. SunOS 4.0, whose VM subsystem will be in S5R4 - which will, like
SunOS 4.0, use it for data caching).