On 8/29/14, 8:29 AM, Samuel Granjeaud wrote:
> Taking into account the two answers, here is some more information.
> The system is a openfiler installation, v2.3, up-to-date.
> The problematic system is a backup but the production system uses the same
> openfiler NAS system. The difference is that there are currently more files
> on the backup system than the production system; so I guess the problem will
> appear sooner on the prod sys.
> # xfs_info /dev/vg1_backup/backup
> meta-data=/mnt/vg1_backup/backup isize=256 agcount=80, agsize=58981376 blks
> = sectsz=512
> data = bsize=4096 blocks=4718510080, imaxpct=25
> = sunit=0 swidth=0 blks, unwritten=1
> naming =version 2 bsize=4096
> log =internal bsize=4096 blocks=32768, version=1
> = sectsz=512 sunit=0 blks
> realtime =none extsz=65536 blocks=0, rtextents=0
> # uname -a
> Linux 22.214.171.124-1.0.11.smp.gcc3.4.x86_64 #1 SMP Sun Jan 11 02:42:55 GMT 2009
> x86_64 x86_64 x86_64 GNU/Linux
> # xfs_info -V /dev/vg1_backup/backup
> xfs_info version 2.6.25
> # cat /etc/fstab
> /dev/vg1/pcurrent /mnt/vg1/pcurrent xfs defaults,usrquota,grpquota 0 0
> # cat /etc/mtab
> /dev/mapper/vg1-pcurrent /mnt/vg1/pcurrent xfs rw,usrquota,grpquota 0 0
<thanks for all the extra info>
> I have no idea concerning the inode64 option. Just tell me how to find it
> out. I don't think this option was changed: as previously told, removing a
> few files allows files to be created without error.
You'll want to be using the inode64 mount option for this filesystem; I'm
surprised the openfiler folks didn't do this by default.
add it to fstab for this filesystem, reboot the box (or unmount/mount the
filesystem) and all should be well.