[9fans] adding storage to ken's fs

[9fans] adding storage to ken's fs

[Sam]

I've a cache/fake worm fileserver that's almost full.
I want to add some more space to it.  The current
configuration, with one adapter is:

config w0
service ramac
filsys main cw0fw1
filsys dump o
...

I'm looking at adding another adapter with two
more disks.  Provided the new adapter is seen
as the second, can I get what I want
by changing filsys main to be:

filsys main cw0f(w1.1w1.0.0w1.1.1)

and keeping all else the same?

Any other tips for doing this without shooting
myself in the foot?

Sam

Re: [9fans] adding storage to ken's fs

[Geoff Collyer]

> filsys main cw0f(w1.1w1.0.0w1.1.1)

I think you want

	filsys main cw0f(w1w1.<0-1>.0)

That is, wT is scsi adaptor 0, target (a.k.a.  unit) T, lun 0; wA.T.L
is adaptor A, target T, lun L. lun is almost always 0 (some jukeboxes
use, or can be configured to use, non-zero luns).  wT.L is adaptor 0,
target T, lun L, which turns out to be rarely useful.  fsconfig(8) has
the whole story.

(You may also have to issue

	filsys dump o

again afterward; I'm not sure.  I always do this after redefining a cw
main since the dump is derived from the worm part of the cw
declaration.)

I believe that this should grow your fake worm, but Charles or Nigel
probably have more experience with this.  I've changed cache disks and
added and removed (as-yet-unwritten) optical disks, and the fs kernel
always seems to automatically and correctly resize the cache or the
worm as appropriate.  On the other hand, I'm not sure how the
fake-worm's bitmap would interact with adding more space.

> Any other tips for doing this without shooting myself in the foot?

or shooting yourself in the root. ☺  Obviously a dump to CD of your
own files first wouldn't be a bad idea.  Type carefully on the fs
console and double-check commands before pressing `return'.

Re: [9fans] adding storage to ken's fs

[Charles Forsyth]

>>worm as appropriate.  On the other hand, I'm not sure how the
>>fake-worm's bitmap would interact with adding more space.

that's the thing you need to watch: the bitmap is at the end
of each f device, so you need to define your extended configuration
to preserve it (or you'll have a big disaster)

here's the (possibly) relevant part of my home configuration
	filsys main cp(w1.2.0)0.20(fp(w1.2.0)20.80fw1.3.0fw1.4.0)
	filsys dump o

note that it concatenates several f devices to form the worm device.
that way each existing bitmap was preserved.  alternatively you could add
some code to the fs kernel to copy it, or copy it by booting a terminal/cpu
on the machine temporarily and fiddling with dd and the /dev/sd*/data
to shuffle the blocks with the bits, but the latter two options are harder.

aha! but there's still a catch: you need to initialise the bitmap to zero first.
ream is NOT what you want.  i think i ended up doing a special fs kernel
to devream just the new device, not the file system (which would empty the super block),
but it was a long time ago.  it should be enough to clear a large chunk
of the new device to zero using a terminal/cpu kernel.

with a real worm (eg, jukebox) all that's required when adding platters is to
extend the configuration to refer to them, and it uses them.