[9fans] ramfs, fossil, venti etc.

[9fans] ramfs, fossil, venti etc.

[tlaronde]

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?
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ramfs, fossil, venti etc.

[Vivien MOREAU]

Hello Thierry,

tlaronde@polynum.com writes:

> 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?

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.

--
Vivien

Re: [9fans] ramfs, fossil, venti etc.

[tlaronde]

Hello Vivien,

On Wed, Jan 04, 2012 at 09:58:36AM +0100, Vivien MOREAU wrote:
> Hello Thierry,
>
> tlaronde@polynum.com writes:
> > [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,
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ramfs, fossil, venti etc.

[Jack Norton]

On 1/4/2012 2:58 AM, Vivien MOREAU wrote:
> Hello Thierry,
>
> tlaronde@polynum.com writes:
>
>> 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.
>
> 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

Re: [9fans] ramfs, fossil, venti etc.

[tlaronde]

On Wed, Jan 04, 2012 at 08:45:41AM -0600, Jack Norton wrote:
>
> 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.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ramfs, fossil, venti etc.

[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

Re: [9fans] ramfs, fossil, venti etc.

[tlaronde]

On Wed, Jan 04, 2012 at 01:33:46PM +0000, Steve Simon wrote:
>[...]
> 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 ;)

>
> 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!
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ramfs, fossil, venti etc.

[smiley]

"Steve Simon" <steve@quintile.net> writes:

> 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?

--
+---------------------------------------------------------------+
|Smiley       <smiley@icebubble.org>    PGP key ID:    BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+