[9fans] ramfs, fossil, venti etc.

[t***@polynum.com]

Hello,

Since I will have to fix and redo my Plan9 installation, I'd like to
have some tips about disks layout, in order to prevent another "disk
full" inconvenience.

My date is organized, at least, in three distinct chunks:

1) The data that I use read-only (written by someone else and that can
be retrieved at will). So are the sources for the OSes etc., that I may
backup (on optical disks) from time to time, but for what I don't need
an archival filesystem (no snapshots; no backup)
=> For this, if I understand: fossil alone, no venti, and setting
snaptime so that the low epoch is very need to the higher one.

2) Really transient data: /tmp, typically. For that ramfs(4) seems the
right candidate, and fossil will be a waste of space.

3) Data that I do care about, because I'm the writer and I do need the
ability to go back in the archives. So, in this case: fossil+venti.

Do I get the things approximately correct above?

Second question: I know the amount of my data; I guess the amount of
tmp data; what is the amount of space needed for a whole install and the
sources (leaving aside contrib/ packages)?

Thanks for any tip!

PS: not really related. Has someone tried GRUB+etherboot to
install/reinstall Plan9 by network without a PXE able network card?

[Vivien MOREAU]

Hello Thierry,

Post by t***@polynum.com
1) The data that I use read-only (written by someone else and that can
be retrieved at will). So are the sources for the OSes etc., that I may
backup (on optical disks) from time to time, but for what I don't need
an archival filesystem (no snapshots; no backup)
=> For this, if I understand: fossil alone, no venti, and setting
snaptime so that the low epoch is very need to the higher one.
2) Really transient data: /tmp, typically. For that ramfs(4) seems the
right candidate, and fossil will be a waste of space.
3) Data that I do care about, because I'm the writer and I do need the
ability to go back in the archives. So, in this case: fossil+venti.
Do I get the things approximately correct above?

You don't need to have several fossil on the disk. Just use chmod +t
/usr/tlaronde/rodata in order to avoid archiving your read-only data on
venti.

The same is true about /tmp. Actually ls -l /usr/tlaronde/tmp will show
you that /tmp has already the +t bit. However, yes you can also use
ramfs if you have enough RAM. :-)

IMHO, the default layout is good enough for your needs.

[t***@polynum.com]

Hello Vivien,

Post by Vivien MOREAU
Hello Thierry,

[snipped]
Do I get the things approximately correct above?

You don't need to have several fossil on the disk. Just use chmod +t
/usr/tlaronde/rodata in order to avoid archiving your read-only data on
venti.
The same is true about /tmp. Actually ls -l /usr/tlaronde/tmp will show
you that /tmp has already the +t bit. However, yes you can also use
ramfs if you have enough RAM. :-)
IMHO, the default layout is good enough for your needs.

Thanks! I will take the opportunity of the reinstall to increase (not
very difficult...) my understanding of fossil, venti, kfs etc.

Cu,

[Jack Norton]

Post by Vivien MOREAU
Hello Thierry,

Post by t***@polynum.com
1) The data that I use read-only (written by someone else and that can
be retrieved at will). So are the sources for the OSes etc., that I may
backup (on optical disks) from time to time, but for what I don't need
an archival filesystem (no snapshots; no backup)
=> For this, if I understand: fossil alone, no venti, and setting
snaptime so that the low epoch is very need to the higher one.

You don't need to have several fossil on the disk. Just use chmod +t
/usr/tlaronde/rodata in order to avoid archiving your read-only data on
venti.

I don't follow. Wouldn't read only data be perfect for venti? If I had
a bunch of files that I would never need changed, I would just throw
them directly into venti and be done with it. Couldn't you just push
those files onto your venti srv, and access them through other methods
besides fossil, bypassing this whole snapshot thing all together?

I'm curious also how much ram this beast will have. Are you building a
new machine?

-Jack

[t***@polynum.com]

Post by Jack Norton
I don't follow. Wouldn't read only data be perfect for venti? If I had
a bunch of files that I would never need changed, I would just throw
them directly into venti and be done with it. Couldn't you just push
those files onto your venti srv, and access them through other methods
besides fossil, bypassing this whole snapshot thing all together?
I'm curious also how much ram this beast will have. Are you building a
new machine?

The data that I don't need to archive with version is typically
externally provided data that is backed somewhere else (I do burn CD
from time to time even for these sources; but it's not critical).

That's not because _I_ treat them read-only that they don't change. So
fossil without venti is perfect for the job: perha snapshots for some
days (to be able to keep working in case of problem), but not a whole
archival.

And no: I don't install a new machine now. And the "beast" is an old
one (but is the best of the 3 I have now). Not due to lack of means, but
to lack of need: my programs are always written to need the minimal of
resources; they run without ado on this.

[Steve Simon]

I split my disk up into fossil, venti, and other
(as well as a few other small partitions like nvram and fs).

My 'other' filesystem is a fossil partition but it is never
dumped to venti as it only holds files which are temporary or
which are already backed up elsewhere - e.g. CDROM ISO images.

Don't forget you can always grow your venti by adding more arenas
partitions. More indexes can be added also - rebuilt from your
existing arena partitions).

Even fossil can be grown though you will need a new bigger
partition or grow the existing one using fs(3), this can then
be refreshed from a venti snapshot.

Having had some disk failures in the past I built my server with
two mirrored disks and fs(3) config in seperate partitions for
Mirrored, A-only and B-only. Thus when one disk fails I can quickly
reboot onto the working disk.

-Steve

[t***@polynum.com]

Post by Steve Simon
[...]
Don't forget you can always grow your venti by adding more arenas
partitions. More indexes can be added also - rebuilt from your
existing arena partitions).

I finally read the paper about fossil/venti so it's a little mor clear
now ;)

Post by Steve Simon
Having had some disk failures in the past I built my server with
two mirrored disks and fs(3) config in seperate partitions for
Mirrored, A-only and B-only. Thus when one disk fails I can quickly
reboot onto the working disk.

That's the next step: to build a Plan9 fs with RAID.

Thanks for the advices!

[s***@icebubble.org]

Post by Steve Simon
Even fossil can be grown though you will need a new bigger
partition or grow the existing one using fs(3), this can then
be refreshed from a venti snapshot.

Quid pro quo: IIRC, if you do this (using flfmt), you will retain venti
archives of the fossil filesystem, but loose the ephemeral snapshots, as
well as any data marked +t. There's currently no way to resize a fossil
file system in-place, is there?