I'd like to set up my spiffy new cpu server to boot from a venti using at least mirrored arenas via fs(3). A few questions on this: • I'm mirroring the arenas to insure against drive failure. Does it make sense to also interleave the indexes? Both of them? • I've got three disks. The venti arenas will be on two. Will the indexes benefit significantly from either being interleaved across three, or only on the third (with the fossil)? I understand that this is somewhat usage-dependent; I guess the real question is how sensitive are the indexes to write times? • The venti would be used for the fossil boot partition, so needs to be there at startup. fs(3) suggests sticking the config on a floppy (!). This seems like not the most reliable option. Where are others sticking their fs(3) configs for boot? • Once there's an fsconfig var, how does the rest of the startup go? I don't see it pulling that in anywhere. This needs to be well before cpurc, right? Will this require a custom boot? Anthony
> • The venti would be used for the fossil boot partition, so needs to > be there at startup. fs(3) suggests sticking the config on a floppy > (!). This seems like not the most reliable option. Where are others > sticking their fs(3) configs for boot? The wiki page for mirroring under venti and fossil: http://plan9.bell-labs.com/wiki/plan9/ Mirroring_with_Fossil_and_Venti/index.html Suggests storing the fs config in an 'fscfg' parition on the local (hard) disk, similar to the conf headers for venti or fossil themselves. > • Once there's an fsconfig var, how does the rest of the > startup go? > I don't see it pulling that in anywhere. This needs to be well before > cpurc, right? Will this require a custom boot? And then one can set 'fsonfig=' in plan9.ini to the partition created above to start devfs with it at boot. The rest of your questions I'm experimenting with myself & am very interested in the experience of others and yours; I do know Russ Cox has some informative comments about venti and fossil caching (in memory) at the end of the venti-rescue paper. The big hint for a single-machine fossil+venti, I thought, is that fossil caches venti blocks, too. -- Josh
since modern disks can read a whole track at once, there's no "reload" time. it would only make sense to interleave you have more than 1 i/o process (venti seems to have a few) and you're either running faster than the disk bandwidth. the disk bandwidth could be as high as 60MB/s for sequential reads and as low as 1MB/s for small reads with many seeks. if most of venti's io is via the read ahead process, i think there would be very limited benefit by interleaving i/o. and you would need four disks. if you use two disks partitioned in ½, you will insure that every write will generate a huge seek. - erik