Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Recently we ran into a problem with an xfs file system reporting that it had run out of space, even though there was lots of free space left. Because it is a backup volume, we ran into the 5% of space for inodes limit that seems to be the default for CentOS.

# cat /etc/redhat-release
CentOS release 6.3 (Final)

Consequently we increased the imax_pct to 25. After that, we could touch files again on that file system.

This is what xfs_info has to say now:

root@node01:/var/backup# xfs_info /dev/mapper/vg_data-lv_backup
meta-data=/dev/mapper/vg_data-lv_backup isize=256    agcount=33, agsize=33554480 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=1073743872, imaxpct=25
         =                       sunit=16     swidth=96 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=16 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Reading more about possible space issues with xfs I came across the inode64 mount option that is recommended for large xfs file systems. At 4TB the file system in question is not gigantically huge, but still from what I understand it could become crowded in the lower 1TB with large amounts of inodes, provoking more out-of-space problems. Moreover I understand that apart from making sure inodes can be created anywhere on the disk, it will also make sure that inodes and data are located closer together, (at least potentially) improving performance.

I followed the advice and mounted the volume again with inode64 enabled.

root@node01:/var/backup# mount | grep backup
/dev/mapper/vg_data-lv_backup on /var/backup type xfs (rw,noexec,inode64,noquota)

While the system seems to work ok, allowing us to create new files and hard links, I am curious about the output of xfs_db:

root@node01:/var/backup# xfs_db -r -c sb -c p /dev/mapper/vg_data-lv_backup | egrep icount\|ifree\|max_pct
imax_pct = 25
icount = 858994880
ifree = 0

In contrast to that, df -i shows this:

root@node01:/var/backup# df -i /var/backup
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_data-lv_backup
                     4294975488 858994880 3435980608   20% /var/backup

The used count is identical, but the free count is obviously very much different.

When I touch a new file, I expect the icount value to go up, removing it again should make the icount go down:

root@node01:/var/backup# touch X
root@node01:/var/backup# df -i /var/backup
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_data-lv_backup
                     4294975488 858994881 3435980607   20% /var/backup

root@node01:/var/backup# rm -f X
root@node01:/var/backup# df -i /var/backup
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_data-lv_backup
                     4294975488 858994880 3435980608   20% /var/backup

So far, so good. However, looking at xfs_db does not reflect that:

root@node01:/var/backup# xfs_db -r -c sb -c p /dev/mapper/vg_data-lv_backup | egrep icount\|ifree\|max_pct
imax_pct = 25
icount = 858994880
ifree = 0

root@node01:/var/backup# touch X
root@node01:/var/backup# xfs_db -r -c sb -c p /dev/mapper/vg_data-lv_backup | egrep icount\|ifree\|max_pct
imax_pct = 25
icount = 858994880
ifree = 0

root@node01:/var/backup# rm -f X
root@node01:/var/backup# xfs_db -r -c sb -c p /dev/mapper/vg_data-lv_backup | egrep icount\|ifree\|max_pct
imax_pct = 25
icount = 858994880
ifree = 0

Also, why is ifree showing a value of 0?

I might be missing something obvious here, but so far I don't see the forest for the trees.

share|improve this question
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.