Hello Oliver,
Oliver Welter:
> I want to replace drbd with glusterfs, but get a very strange error
> "File too large" when the server is booting on some files which seem to
> be "special":
>
> vserver testing start
> chroot-sh: open("/etc/mtab"): File too large
> secure-mount: chdir("/proc"): File too large
> /etc/vservers/testing/fstab:1:1: failed to mount fstab-entry
> secure-mount: chdir("/tmp"): File too large
> /etc/vservers/testing/fstab:2:1: failed to mount fstab-entry
> secure-mount: chdir("/dev/pts"): File too large
> /etc/vservers/testing/fstab:3:1: failed to mount fstab-entry
> fakerunlevel: open("/var/run/utmp"): File too large
>
> Using gluster without the aufs layer on top works, so I guess that there
> is some kind of conflict when aufs is calling the lower fs.
>
> Any help is appreciated - I can provide a detailed setup instruction if
> necessary.
First, more info is necessary.
(from the aufs README file)
----------------------------------------------------------------------
When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (instead of the output of mount(8))
- /sys/module/aufs/*
- /sys/fs/aufs/* (if you have them)
- /debug/aufs/* (if you have them)
- linux kernel version
if your kernel is not plain, for example modified by distributor,
the url where i can download its source is necessary too.
- aufs version which was printed at loading the module or booting the
system, instead of the date you downloaded.
- configuration (define/undefine CONFIG_AUFS_xxx)
- kernel configuration or /proc/config.gz (if you have it)
- behaviour which you think to be incorrect
- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net
----------------------------------------------------------------------
Probably the version of your glusterfs will be necessary too.
Next, stat info is necessary too.
For example, just before the command which retuned the error,
$ stat /etc /etc/mtab /proc /etc/vservers/testing/fstab /tmp /dev/pts \
/var/run/utmp
Although I don't think your files are so large, we should confirm it.
The manual page of open(2) says,
ERRORS
:::
EFBIG See EOVERFLOW.
:::
EOVERFLOW
pathname refers to a regular file that is too large to be
opened. The usual sce-
nario here is that an application compiled on a 32-bit
platform without
-D_FILE_OFFSET_BITS=64 tried to open a file whose size exceeds
(2<<31)-1 bits; see
also O_LARGEFILE above. This is the error specified by
POSIX.1-2001; in kernels
before 2.6.24, Linux gave the error EFBIG for this case.
It means that if someone (including aufs) returns the incorrect value in
stat.st_size, then open(2) may return EFBIG. And this is your case. Just
my current guess.
J. R. Okajima
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
