[gentoo-amd64] New install, /var on tmpfs

[gentoo-amd64] New install, /var on tmpfs

[Tonko Mulder]

Hello,

I'm doing a new install and since I put /tmp on tmpfs I was wondering
if I could put /var on tmpfs as well.

Regards,
Tonko Mulder
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] New install, /var on tmpfs

[Volker Armin Hemmann]

On Mittwoch, 6. Februar 2008, Tonko Mulder wrote:
> Hello,
>
> I'm doing a new install and since I put /tmp on tmpfs I was wondering
> if I could put /var on tmpfs as well.

no.

/var/lib
and
/var/db 

contains essential data.

/var/log

also contains data that should survive a reboot.

You can put 
/var/tmp
on tmpfs, but 'the spec' says, that stuff in /var/tmp should survive a reboot.

So 
/var/tmp/portage

that is save.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] New install, /var on tmpfs

[Tonko Mulder]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Op Wednesday 06 February 2008 08:39:46 schreef Volker Armin Hemmann:
> On Mittwoch, 6. Februar 2008, Tonko Mulder wrote:
> > Hello,
> >
> > I'm doing a new install and since I put /tmp on tmpfs I was wondering
> > if I could put /var on tmpfs as well.
>
> no.
>
> /var/lib
> and
> /var/db
>
> contains essential data.
>
> /var/log
>
> also contains data that should survive a reboot.
>
> You can put
> /var/tmp
> on tmpfs, but 'the spec' says, that stuff in /var/tmp should survive a
> reboot.
>
> So
> /var/tmp/portage
>
> that is save.

Oke, thanks. All needed to know :)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: New install, /var on tmpfs

[Duncan]

Tonko Mulder <tonko.mulder@gmail.com> posted
200802060847.50748.tonko.mulder@gmail.com, excerpted below, on  Wed, 06
Feb 2008 08:47:42 +0100:

> Op Wednesday 06 February 2008 08:39:46 schreef Volker Armin Hemmann:
>> On Mittwoch, 6. Februar 2008, Tonko Mulder wrote:
>> >
>> > I'm doing a new install and since I put /tmp on tmpfs I was wondering
>> > if I could put /var on tmpfs as well.
>>
>> no.

>> You can put
>> /var/tmp
>> on tmpfs, but 'the spec' says, that stuff in /var/tmp should survive a
>> reboot.
>>
>> So
>> /var/tmp/portage
>>
>> that is save.
> 
> Oke, thanks. All needed to know :)

FWIW, I have /tmp on tmpfs, and /var/tmp as a symlink pointing at it.  
There's some stuff in /var/tmp by default that really should go in /var/
cache instead (as above, it's cache, not tmp, and works best if kept over 
a reboot), but at least here, I was able to point it all elsewhere, thus 
leaving tmp (including /var/tmp) as really tmp.

Specifically, I have a script that I run from the local service at boot 
that creates individual user tempdirs for a couple users in /tmp (with a 
~/tmp symlink pointed at the appropriate /tmp/<user> subdir) and 
additionally, creates with the appropriate permissions the various X 
tempdirs (.X11-unix, .ICE-unix, .font-unix, the latter for xfs font 
server I believe).

Additionally, as a KDE user, I had to set and export three KDE* vars in 
my environment, KDEVARTMP and KDESYCOCA to point to a non-tmpfs cache dir 
location (I decided to place them in the user's homedir, not in a system 
dir like /var/tmp, the sycoca var of course points to a filename in the 
dir), and KDETMP to point to the appropriate user tmpdir under /tmp.  
GNOME probably has similar settings, but I'd have no idea what or where 
as I don't run it.

Before setting the KDEVARTMP var I'd lose konqueror and general KDE 
favicon cache, etc.  However, it wasn't anything serious, nor should it 
be, as the spec says /var/tmp is for cached stuff, which is nice to save 
over a reboot, but not critical.  Again, why they don't just use /var/
cache for that, and save tmp for really tmp stuff, I don't know, but 
that's the way it is.

After making those adjustments, I've had no further issues.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: New install, /var on tmpfs

[Tonko Mulder]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

Op Wednesday 06 February 2008 11:19:46 schreef Duncan:

> FWIW, I have /tmp on tmpfs, and /var/tmp as a symlink pointing at it.
> There's some stuff in /var/tmp by default that really should go in /var/
> cache instead (as above, it's cache, not tmp, and works best if kept over
> a reboot), but at least here, I was able to point it all elsewhere, thus
> leaving tmp (including /var/tmp) as really tmp.
Don't know what 'FWIW' is, but anyway :)

> Specifically, I have a script that I run from the local service at boot
> that creates individual user tempdirs for a couple users in /tmp (with a
> ~/tmp symlink pointed at the appropriate /tmp/<user> subdir) and
> additionally, creates with the appropriate permissions the various X
> tempdirs (.X11-unix, .ICE-unix, .font-unix, the latter for xfs font
> server I believe).
>
> Additionally, as a KDE user, I had to set and export three KDE* vars in
> my environment, KDEVARTMP and KDESYCOCA to point to a non-tmpfs cache dir
> location (I decided to place them in the user's homedir, not in a system
> dir like /var/tmp, the sycoca var of course points to a filename in the
> dir), and KDETMP to point to the appropriate user tmpdir under /tmp.
> GNOME probably has similar settings, but I'd have no idea what or where
> as I don't run it.
>
> Before setting the KDEVARTMP var I'd lose konqueror and general KDE
> favicon cache, etc.  However, it wasn't anything serious, nor should it
> be, as the spec says /var/tmp is for cached stuff, which is nice to save
> over a reboot, but not critical.  Again, why they don't just use /var/
> cache for that, and save tmp for really tmp stuff, I don't know, but
> that's the way it is.
>
> After making those adjustments, I've had no further issues.

Thanks for the info and I'll try that when I'm ready to boot..
( I wasn't thinking and I created a lvm root partition :P )

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: New install, /var on tmpfs

[Duncan]

Tonko Mulder <tonko.mulder@gmail.com> posted
200802061253.45910.tonko.mulder@gmail.com, excerpted below, on  Wed, 06
Feb 2008 12:53:37 +0100:

> Op Wednesday 06 February 2008 11:19:46 schreef Duncan:
> 
>> FWIW, I have /tmp on tmpfs, and /var/tmp as a symlink pointing at it.

> Don't know what 'FWIW' is, but anyway :)

http://www.onelook.com/?w=fwiw&ls=a

For What It's Worth.  (FWIW... I don't use too many IM/list-speak 
acronyms and tend to dislike reading posts from those that do, but I use 
a few common ones, FWIW, BTW=By The Way, smilies, etc.) 

> Thanks for the info and I'll try that when I'm ready to boot.. ( I
> wasn't thinking and I created a lvm root partition :P )

=8^\ 

I've never done that, tho I understand it's workable if you have 
/boot separate and an initramfs/initrd with lvm2 therein, but I spent 
QUITE some time planning my system so it wasn't necessary, putting 
root and rootbak (if one fails I can boot the other, I update the backup 
only periodically, when I know the main one is working well) on 
partitioned RAID-6, specifically to AVOID root on lvm.  Unlike lvm, the 
kernel can pickup md/RAID parameters from its command line and can boot 
into it directly, so that's how I have it arranged, /boot on RAID-1 as 
that's all the RAID grub can handle, root and rootbak, along with the 
physical volume for my LVM for everything else redundancy critical on 
partitioned RAID-6, and 4-way striped swap and RAID-0 for caches (ccache, 
the Gentoo tree, /usr/src/linux/) that are speed but not redundancy 
critical.

The root and rootbak partitions contain most of /usr and /var as well, 
basically everything that gets touched by ebuilds and the package manager 
including its data, so it all stays in sync.  If I were doing it over, 
the only two things I'd do differently would be to have two rootbaks, so 
if the system crashed while I was writing the one backup and neither it 
nor the primary working root were functional, I could still boot the 
other backup, and I'd create my RAID using at least 5 spindles/drives 
(but go lower end on capacity per spindle), as writing to a 4-way RAID-6 
is slowwwww.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: New install, /var on tmpfs

[Volker Armin Hemmann]

On Mittwoch, 6. Februar 2008, Duncan wrote:

>
> The root and rootbak partitions contain most of /usr and /var as well,
> basically everything that gets touched by ebuilds and the package manager
> including its data, so it all stays in sync.  If I were doing it over,
> the only two things I'd do differently would be to have two rootbaks, so
> if the system crashed while I was writing the one backup and neither it
> nor the primary working root were functional, I could still boot the
> other backup, and I'd create my RAID using at least 5 spindles/drives
> (but go lower end on capacity per spindle), as writing to a 4-way RAID-6
> is slowwwww.

and the more spindles, the higher the chance for a fatal disk crash.
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: New install, /var on tmpfs

[Duncan]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
200802061341.37169.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Wed, 06 Feb 2008 13:41:37 +0100:

> and the more spindles, the higher the chance for a fatal disk crash.

Well yes, but that's sort of the point of using RAID-6 instead of RAID-5, 
and once one gets over 8-10 disks, RAID-10 or RAID-61 (? or would it be 
called 16, duplicating each disk, not the entire RAID-6 ?) becomes 
practical.

Actually, today I'd probably implement it using a couple of those 
external 5-way port-multipliered SATA boxes, connecting each to the 
system via single SATA-300 cable, which should handle 5 disk's disk-rate 
I/O reasonably well without bottlenecking.  Connect each cable to a 
separate SATA-300 card on separate PCI-E or PCI-X channels, avoiding 
bottlenecking there, and the bandwidth should be reasonable.  Because the 
external disk arrays have their own power supplies, the one in the 
computer itself wouldn't have to be such a honker, I could run low noise 
supplies in all of them, and the computer case could be smaller too, as 
the only drive in it would be a DVD burner.  It'd be three smaller, 
quieter, more portable and easier to work with boxes, in place of the 
single full tower case, quad internal hard drives plus DVD burner, I'm 
using today.  The dual 5-way drive cases would give me space for ten 
drives, of which I'd probably make two hot-spares, leaving an 8-way 
RAID-6, two parity, six data stripes.  Large write performance, the real 
killer now, would be much better, and because I'd have two hot-spares 
ready for the system to bring online if necessary, total reliability 
should remain comparable to now, 4-way RAID-6 but without the hot-spares.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list