On 2013-04-23 1:59 PM, Neil Bothwick <n...@digimed.co.uk> wrote:
On Tue, 23 Apr 2013 18:34:38 +0200, Florian Philipp wrote:

So - first, is 5G way too big for the two /tmp dirs? I have lots of
space, but hate waste

If you worry about waste consider bind-mounting both from the same
partition and install quotas to avoid one filling up the other.

Or set PORTAGE_TMPDIR to use /tmp. Then /var/tmp will be so small you
can leave it as a sub-directory of /var.

If this is a server, 5G is fine for this, but for a desktop it may need
to be bigger, to accommodate LibreOffice builds.

One thing I'm trying to do is make the system as secure as possible at the filesystem level, and I've read that making /tmp and /var/tmp separate partitions so you can mount them /nodev/noexec/nosuid is one way to make things a bit more secure...

On that note, I realized I can't make two /tmp's in lvm, so, I guess I can make a vtmp, and just bind that to /var/tmp in fstab like:

/dev/vg/vtmp    /var/tmp     ext4     nodev,noexec,nosuid     0 0

Will that work?

Last issue -

I was planning on using XFS for my /var so I've been researching filesystems on VMs, and ran into this FAQ on the XFS site:

http://xfs.org/index.php/XFS_FAQ#Q:_Which_settings_are_best_with_virtualization_like_VMware.2C_XEN.2C_qemu.3F

"Q: Which settings are best with virtualization like VMware, XEN, qemu?

The biggest problem is that those products seem to also virtualize disk writes in a way that even barriers don't work any more, which means even a fsync is not reliable. Tests confirm that unplugging the power from such a system even with RAID controller with battery backed cache and hard disk cache turned off (which is safe on a normal host) you can destroy a database within the virtual machine (client, domU whatever you call it).

In qemu you can specify cache=off on the line specifying the virtual disk. For others information is missing."

Which says there IS NO BEST SETTING, and that XFS (and by implication, ANY FS) will always be very vulnerable to sudden power loss by the Host...

Comments welcome...

Reply via email to