Francisco J Ballesteros <[EMAIL PROTECTED]> 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
