Spreading volumes across multiple disks?

[commodorejohn]

I've just gotten NetBSD 6.1.5 set up on a MicroVAX 3100/90 I recently acquired. It came with four 406MB SCSI hard drives, and since I'm on a tight budget, it's going to be keeping those four 406MB drives for the foreseeable future. Currently it's just got / mapped to a full-drive partition on sd0/dka0 (on account of the installer not being able to set up partitions on multiple disks.) What I'd like to do with it is get it set up so that it makes good use of the available disk space.

Mostly that's just a matter of copying out different parts of the filesystem to new partitions on the other disks and then changing fstab, but one thing I'd specifically like to do is have a /usr partition larger than 406MB, since it seems like the majority of pretty much any non-core stuff gets installed in /usr. I'm curious - I know there's relatively simple ways to mirror a partition across multiple disks, but is there an easy way to actually spread a larger virtual partition across a couple different physical partitions?

I suppose if nothing else I could map some of the /usr subdirectories to different partitions, but a true virtual partition seems like it would be a more flexible, simpler solution.

(And as an aside, is there any viable way to get a working compiler toolchain running natively on NetBSD/vax?)

[jggimi]

I'm not a NetBSD user .... but with that disclaimer, perhaps CCD is what you're looking for to manage your 1.6GB worth of disk space?

https://www.netbsd.org/docs/guide/en/chap-ccd.html

[commodorejohn]

Hm, that does look like about what I'm looking for...I'll give it a try when I get a chance.

[Oko]

Originally Posted by commodorejohn

(And as an aside, is there any viable way to get a working compiler toolchain running natively on NetBSD/vax?)

IIRC NetBSD uses most of the time cross compiling for non Tier I architectures (read not amd64, i386). That means that their VAX port is probably compiled on fast amd64 machine. However OpenBSD uses always native builts and toolchain. The good news is that VAX is one of 22 supported architectures by OpenBSD


P.S. I would really like to get my hands on one 3100/90. That was my first UNIX computer after I switched from Atari 1990.

[commodorejohn]

Yeah...I actually went to OpenBSD first, but unfortunately it's very noticeably slower and heavier on disk space than NetBSD, at least on something with MicroVAX levels of horsepower.

[jggimi]

Should you return to it, note that ccd was long deprecated. Concatenation is performed as a softraid(4) discipline.

[abs]

Originally Posted by commodorejohn

I've just gotten NetBSD 6.1.5 set up on a MicroVAX 3100/90 I recently acquired. It came with four 406MB SCSI hard drives, and since I'm on a tight budget, it's going to be keeping those four 406MB drives for the foreseeable future. Currently it's just got / mapped to a full-drive partition on sd0/dka0 (on account of the installer not being able to set up partitions on multiple disks.) What I'd like to do with it is get it set up so that it makes good use of the available disk space.

Mostly that's just a matter of copying out different parts of the filesystem to new partitions on the other disks and then changing fstab, but one thing I'd specifically like to do is have a /usr partition larger than 406MB, since it seems like the majority of pretty much any non-core stuff gets installed in /usr. I'm curious - I know there's relatively simple ways to mirror a partition across multiple disks, but is there an easy way to actually spread a larger virtual partition across a couple different physical partitions?

I suppose if nothing else I could map some of the /usr subdirectories to different partitions, but a true virtual partition seems like it would be a more flexible, simpler solution.

The two obvious options are ccd or raidframe. While ccd is 'less sophisticated' it might actually be better for your usage as you can concatenate different sized partitions, while raidframe only works with striping (which is better performance wise, but only if you have a power of two data disks)

Raidframe can also autoconfigure so any raids will assemble correctly when the kernel boots before mounting any filesystems (even if you shuffle all the disks around).

Some options might be

a) boot partition on one disk (maybe 64M), then concatenate the rest of that disk, and the other 3 into one big ccd and mount on /usr. Gives the largest possible /usr (at the expense of no space anywhere else

b) boot partition on one disk (maybe 64M), remainder of disk as say /var, and three disks together as a ccd for /usr. Can be striped or concatenated, but non power of 2 stripe may mean striping gives poor performance

c) boot partition on one disk (maybe 64M), remainder of disk as say /var, one disk as /home and two disks together as a ccd for /usr. Can be striped or concatenated, power of 2 stripe may give a speed increase

d) tiny boot partition on one disk then a striped ccd partition for /usr across the remainder of that disk and the same sized chunk of the other three. Gain the speed of striping with power of 2 stripes, but you are left with three other tiny partitions to fiddle with

e) Any of b), c) or d) but with raidframe. Only real benefit is the autoconfiguration

f) boot disk with / and maybe /var, then a raid5 partition for /usr of the other 3, which would give 406M+406M+parity. You lose 406M for the parity, but gain data security if one of the three fails, probably have reasonable performance due to stripe size, but may lose out due to compute overhead

I'd probably pick c) as a nice mix, plus NFS mount something from another box when needed

Originally Posted by commodorejohn

(And as an aside, is there any viable way to get a working compiler toolchain running natively on NetBSD/vax?)

I think gcc-4.8 (which should be in netbsd-7) is looking much better for reliable native code generation (assuming you have a boat load of memory and more patience than God).

Otherwise someone time and the right itch could look at a VAX frontend for clang, or spend some time on pcc/VAX. The latter certainly should be performant enough on VAX.

Anyway, congrats on the 3100/90. Its a nice box. Do you have a framebuffer & cables for X on it?

[commodorejohn]

Originally Posted by abs

The two obvious options are ccd or raidframe. While ccd is 'less sophisticated' it might actually be better for your usage as you can concatenate different sized partitions, while raidframe only works with striping (which is better performance wise, but only if you have a power of two data disks)

Good to know, although I suppose with raidframe there's the option to use two physical disks and then partition the virtual disk how you like. (That actually might not be a bad approach here...)

Raidframe can also autoconfigure so any raids will assemble correctly when the kernel boots before mounting any filesystems (even if you shuffle all the disks around).

Does ccd not? Will that affect the boot process?

I think gcc-4.8 (which should be in netbsd-7) is looking much better for reliable native code generation (assuming you have a boat load of memory and more patience than God).

Otherwise someone time and the right itch could look at a VAX frontend for clang, or spend some time on pcc/VAX. The latter certainly should be performant enough on VAX.

Yeah, modern gcc is incredibly huge and slow for this level of machine (and it's only got 80MB RAM anyway.) I'd be open to pcc if I had an environment set up for doing cross-compiles so I could get it. Currently about the only option for native programming with an actual build in the packages collection is pforth. (Oh, and Bywater BASIC.)

Anyway, congrats on the 3100/90. Its a nice box. Do you have a framebuffer & cables for X on it?

Nope, it's serial-only. I suppose theoretically one could set up X and then use a suitable client over Ethernet, but I shudder to think how most modern X software would run on this thing...

[abs]

Originally Posted by commodorejohn

Good to know, although I suppose with raidframe there's the option to use two physical disks and then partition the virtual disk how you like. (That actually might not be a bad approach here...)

That should be possible with both ccd and raidframe - just write a disklabel to ccd0c or raid0d and away...

> Raidframe can also autoconfigure so any raids will assemble correctly when
> the kernel boots before mounting any filesystems (even if you shuffle all
> the disks around).

Does ccd not? Will that affect the boot process?

Configuration for ccd can be written to /etc/ccd.conf, which is processed by /etc/rc.d/ccd as part of the boot process. Raidframe config can be stored in /etc/raid[0-9]{0,1}.conf. Both work the same way and should configure the relevant devices early enough in boot to enable /usr to be placed on a ccd or raid.

Raidframe also has an autoconfigure option, which writes all the metadata to the header of the relevant partitions, so the kernel will autoconfigure the raid as soon as it sees the disk. It also has an option to mark a raid as he root device, so you could even setup all of your disks as a raid5 set, apart from a single tiny partition big enough to store /boot and a kernel. After the kernel loads, it will autoconfigure the raid5 set, which can then contain / and all other file systems. The other nice aspect (particularly if you have many disks), is raid autoconfiguration is robust in the case of disks being shuffled around or even moved to different controllers.

Yeah, modern gcc is incredibly huge and slow for this level of machine (and it's only got 80MB RAM anyway.) I'd be open to pcc if I had an environment set up for doing cross-compiles so I could get it. Currently about the only option for native programming with an actual build in the packages collection is pforth. (Oh, and Bywater BASIC.)

I was quite partial to brandybasic (as an old BBC basic user

I suspect you might be able to build pcc using gcc if you set -O0, or possibly ask on port-vax@netbsd.org to see if anyone has a pcc binary spare...

Nope, it's serial-only. I suppose theoretically one could set up X and then use a suitable client over Ethernet, but I shudder to think how most modern X software would run on this thing...

I ran X on a 4000/90 for a little bit to play with. It wasn't *too* bad for xkobo level apps, and (with patience) I ran Firefox from an amd64 box onto it as an Xterminal

[commodorejohn]

I've run X on my 4000/60 under OpenVMS, and it works pretty well, but all the X software I've used on it was last built sometime in the early 2000s, so that's not terribly indicative.

[abs]

Originally Posted by commodorejohn

I've run X on my 4000/60 under OpenVMS, and it works pretty well, but all the X software I've used on it was last built sometime in the early 2000s, so that's not terribly indicative.

The average X app has put on... considerable weight since then. I remember using X on an 8MB sparc1+ and being quite happy with the result

As an aside on the crossbuilding. If you have a more modern box then one option is to install simh and build apps under a simulated VAX with many 100s of MB of RAM...

[commodorejohn]

I suppose that's true. I may just wind up running OpenVMS on it instead (with two VAXen, all I need is another AUI and a router to have my own little cluster,) but we'll see how it goes.

[abs]

Originally Posted by commodorejohn

I suppose that's true. I may just wind up running OpenVMS on it instead (with two VAXen, all I need is another AUI and a router to have my own little cluster,) but we'll see how it goes.

If you're going to play with VMS it really does make sense to cluster the machines - I believe you can even cluster a real VAX and a simh virtual VAX on another machine...

The VAXen you have should be *just* about powerful enough to run a LAMP (NAMP? VAMP?) stack, with NetBSD/Apache/MySQL/PHP, though my personal preference would probably be NetBSD/nginx/PostgreSQL/Perl, but thats just me

Anyway - have fun whichever way you choose to keep the ol' iron running.