* RE: [9fans] Venti config for booting from fs(3)
@ 2007-11-16 1:10 Joshua Wood
0 siblings, 0 replies; 3+ messages in thread
From: Joshua Wood @ 2007-11-16 1:10 UTC (permalink / raw)
To: 9fans
> • 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] Venti config for booting from fs(3)
2007-11-16 0:38 Anthony Sorace
@ 2007-11-16 1:11 ` erik quanstrom
0 siblings, 0 replies; 3+ messages in thread
From: erik quanstrom @ 2007-11-16 1:11 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [9fans] Venti config for booting from fs(3)
@ 2007-11-16 0:38 Anthony Sorace
2007-11-16 1:11 ` erik quanstrom
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Sorace @ 2007-11-16 0:38 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-11-16 1:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-16 1:10 [9fans] Venti config for booting from fs(3) Joshua Wood
-- strict thread matches above, loose matches on Subject: below --
2007-11-16 0:38 Anthony Sorace
2007-11-16 1:11 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).