> I'm running a p9p venti server under Linux using several
> (small by current standards) physical drives as my arena
> pool. I got a 500GB external USB drive to use as a backup
> of the arenas. But here's the gotcha. The number of blocks
> per cylinder on the 500GB drive isn't the same as the other
> smaller drives. So, I can't create a partition that's exactly
> the same size as one of the smaller drives, which means that
> the last arena is a different size when I format it. mirrorarenas
> complains about that and considers it fatal. I modified
> it so that if the destination arena is bigger than the source,
> it's just a warning and not fatal and it's happily mirroring
> as we speak. But I've got a couple of questions:
> - Is this going to cause any problems?
> - Is there a better way to handle this?

It would be best to set up an arena set that
matches the one you are mirroring exactly.

To cope with the lack of real partitioning
support in operating systems that are not
Plan 9, the p9p venti lets you specify disk
subpieces in the partition names. So you
can say /dev/hda:0-10G to get the first ten
gigabytes of /dev/hda. Or /dev/hda:0-12345M
or /dev/hda:1G-123123123123M etc.

Also, if you do create a Plan 9 partition and
then prep it to make subpartitions (you'd have
to use 9vx, copying the binaries from sources),
then p9p venti can handle those partition names
too: /dev/sda1:arenas assuming /dev/sda1 is a
Plan 9 fdisk partition containing a subpartition
named arenas.

Yes, it's terrible. You use Unix long enough,
you get used to that.

Russ

> Also, if you do create a Plan 9 partition and
> then prep it to make subpartitions (you'd have
> to use 9vx, copying the binaries from sources),
> then p9p venti can handle those partition names
> too: /dev/sda1:arenas assuming /dev/sda1 is a
> Plan 9 fdisk partition containing a subpartition
> named arenas.

So here's what I ended up with. I installed 9vx on
the machine and used that to partition the big
drive: one fairly big partition with 4 subpartitions
for the 4 arena disks already on the machine. The
p9p mirrorarenas didn't like the partition name
notation. It calls initpart which calls parsepart
which seems to only like the numeric range notation.
But running the Plan 9 mirrorarenas in 9vx works
just fine. So I'm pretty much where I want to be
for now.

Thanks,
BLS

>> Also, if you do create a Plan 9 partition and
>> then prep it to make subpartitions (you'd have
>> to use 9vx, copying the binaries from sources),
>> then p9p venti can handle those partition names
>> too: /dev/sda1:arenas assuming /dev/sda1 is a
>> Plan 9 fdisk partition containing a subpartition
>> named arenas.
>
> So here's what I ended up with. I installed 9vx on
> the machine and used that to partition the big
> drive: one fairly big partition with 4 subpartitions
> for the 4 arena disks already on the machine. The
> p9p mirrorarenas didn't like the partition name
> notation. It calls initpart which calls parsepart
> which seems to only like the numeric range notation.
> But running the Plan 9 mirrorarenas in 9vx works
> just fine. So I'm pretty much where I want to be
> for now.

It should be there as of HG revision 2825 (July 3).
The particular file contents that I expect are at
http://swtch.com/go/venti-plan9-partitions
It's at the bottom of the file.

In addition to /dev/sda1:arenas you can say
/dev/sda:arenas -- the code parses the fdisk table
to find the Plan 9 partition too (but it's also happy
if you give it the Plan 9 partition directly).

Using 9vx is fine, of course, but this is one less
moving piece in your mirroring scripts.

Russ