Hello Willi,
Willi Fehler:
> error messages:
> root@server:~# ll /mnt/gluster/static/
> ls: reading directory /mnt/gluster/static/: File too large
> total 0
> aufs au_xino_read:650: I/O Error, too large hi9978470377534379593
In short, aufs detects the inode number is too large and stops handling
it.
As you might know, aufs has an external inode-number translation table
which is call XINO. The XINO file contains the inode number on the
branch fs where aufs accessed. So the maximum file size will be
sizeof(inum) * inum_aufs_found
In your case, aufs finds the inode number 9978470377534379593 on your
branch fs. I don't know it came from static-live or static-testing1. It
doesn't matter. Additionally I don't know the value of
sizeof(inum). Assuming your sizeof(inum) is 4 bytes, the size of XINO
will be
4 * 9978470377534379593 = 39913881510137518372
which exceeds LLONG_MAX (if your sizeof(inum) is 8 bytes, the result
will be two times larger).
And aufs stops handling it and returns 27:EFBIG:File too large.
Theoritically, the inode number can take ULLONG_MAX value (if it is
allowed). But aufs cannot handle such large value.
If your GlusterFS has a option to limit the inode-number, I'd suggest
you to try it.
Also I'd suggest you to refer to aufs manual, especially the section
" External Inode Number Bitmap, Translation Table and Generation Table (xino)"
J. R. Okajima
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
