From mboxrd@z Thu Jan  1 00:00:00 1970
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <20120103214219.GA17347@polynum.com>
From: Vivien MOREAU <vpm@serengetty.fr>
Date: Wed,  4 Jan 2012 09:58:36 +0100
In-Reply-To: <20120103214219.GA17347@polynum.com> (tlaronde@polynum.com's
	message of "Tue\, 3 Jan 2012 22\:42\:19 +0100")
Message-ID: <87sjjvu9mr.fsf@pitchu.serengetty.fr>
User-Agent: Gnus/5.1100000000000003 (Gnus v5.11) Emacs/22.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [9fans] ramfs, fossil, venti etc.
Topicbox-Message-UUID: 53c573fc-ead7-11e9-9d60-3106f5b1d025

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