On 10/03/2012 09:54 AM, Oliver Welter wrote: > Hi Herbert > > On 01.10.2012 17:39, Herbert Poetzl wrote: >> On Mon, Oct 01, 2012 at 01:43:19PM +0200, Oliver Welter wrote: >>> Hi, >>> I am experimenting with vserver and glusterfs - I guess that this is a >>> glusterfs issue but perhaps somebody here has an idea. >>> I am creating my root filesystem from a read-only root and an overlay >>> filesystem using aufs. This is working fine with normal blockdevices. I >>> now tried to replace the writeable partition using a glusterfs mount >>> point, which results in >>> fakerunlevel: open("/var/run/utmp"): File too large >> sounds like the file is too large :) >> >> check the file sizes on all involved filesystems and >> compare them to the maximum allowed file size > Well - the utmp file remaining on the disk after abort is 384 bytes and > I have no problems to create some larger files so I guess there is some > issue with locking or the like. As said, I assume thats not really > related to vserver itself... It sounds like you have bumped into one of the many issues with GlusterFS that arise when you try to use it as a rootfs. You may want to have a read through the glusterfs-devel mailing list archives for issues like this that I came across when I was using it for similar things (e.g. Open Shared Root). The particularly common claim among the developers at the time was that "they couldn't reproduce it" - in reality they just couldn't be bothered to put together a few VMs to test the kind of a setup required to run GLFS as rootfs. From what I've seen about GLFS, not much has changed since a few years back other than version number inflation and a RH badge. Do bear in mind that GLFS is extremely susceptible to split-braining if you are hoping to do anything interesting like sharing rootfs-es. This is borne out of it's lack of having any notion of quorum and node fencing. Gordan