Re: [9fans] Streaming on venti

["Wilhelm B. Kloke" <wb@arb-phys.uni-dortmund.de>]

Francisco J Ballesteros <nemo@lsub.org> schrieb:
> a gpt partitioned disk should have its mbr declaring mostly the disk
> in use, IIRC, plan 9 fdisk does not screw it up unless you decide
> to change the partitions in the mbr.

On a GPT partitioned disk the mbr has to be ignored, as there is no way
to make it look the same in every respect.

Plan9 (and other OSs, such as FreeBSD, NetBSD, OS/2, too) has
idiosyncratic ideas conflicting with my own idiosyncratic ideas how
to layout the MBR.  Every time I tried to add a new OS to some
working partition table I got some sort of bad experience, which
ranged from reordering the partion table to confusing sector
addressing styles.

Just not screwing up the partition table is not enough. I want to
access the data partitions outside the plan9 partition either
to store venti arenas on them, so that these are accessible
from other OSs (Plan9 from User Space, e.g.) or to store other
OS-independent file formats like multimedia, or a database.
IIRC this was not there in Plan9 at the time when I tried it.

But let me return to my main point: If you want to store and access
files bigger than the size of a normal venti arena or even a large
part of one, it looks like a bad use of venti to me.
In his paper about Foundation Russ Cox explains some circumstances
where you probably don't want venti to archive these files forever.
For these sort of files the services of other file systems are
overkill, too. You don't want write more than one at the same time mostly.
You don't need the ability to append to the file, once it is closed.
If you have files of several Gigabyte size you
probably want to have them contiguous. You cannot use BSD slices or
BSD partitions or plan9 partitions to store these, because there are too few
of them. The 128 partitions on a GPT are sufficient, because a 500GB
disk can be laid out to use one big chunk to host file systems and
several smaller chunks from 1GB to, say 20GB for multimedia files.
Of course, you need utilities to manage these.

A file system very suitable for this situation was that of DEC's
RT11 (if it were not limited to 16bit block adresses).  On this
system, every file was contiguous, there was a directory, which
looked mostly like a big partition table, because the directory had
only one level. A new file could be allocated either with a fixed
size in the 1st gap to fit, or to fill the biggest gap. The default
was to fill the maximum of the 2nd largest gap and half the largest
gap size.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373
PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key