日前，同事反饋一個(gè)問題：在一個(gè)大分區(qū)(24T)中使用xfs文件系統(tǒng)，用來做歷史文件備份，突然提示沒有磁盤空間錯(cuò)誤，先檢查下：
[root@imysql ~]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb1 xfs 19T 16T 2.4T 88% /backup/p>
p>[root@imysql ~]# df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb1 9.3G 3.4M 9.3G 1% /backup
可以看到，不管是物理空間，還是inode，都還有很多余量，那為何還會(huì)報(bào)告磁盤空間不夠呢？
查詢了下XFS FAQ，發(fā)現(xiàn)有一段：
Q: What is the inode64 mount option for?/p>
p>By default, with 32bit inodes, XFS places inodes only in the first 1TB of a disk. If you have a disk with 100TB, all inodes will be stuck in the first TB. This can lead to strange things like "disk full" when you still have plenty space free, but there's no more place in the first TB to create a new inode. Also, performance sucks.
To come around this, use the inode64 mount options for filesystems >1TB. Inodes will then be placed in the location where their data is, minimizing disk seeks.
Beware that some old programs might have problems reading 64bit inodes, especially over NFS. Your editor used inode64 for over a year with recent (openSUSE 11.1 and higher) distributions using NFS and Samba without any corruptions, so that might be a recent enough distro.
大意就是xfs文件系統(tǒng)會(huì)把inode存儲(chǔ)在磁盤最開始的這1T空間里，如果這部分空間被完全填滿了，那么就會(huì)出現(xiàn)磁盤空間不足的錯(cuò)誤提示了。解決辦法就是在掛載時(shí)，指定 inode64 選項(xiàng)：
mount -o remount -o noatime,nodiratime,inode64,nobarrier /dev/sdb1 /backup
P.S，磁盤空間小于1T的不用擔(dān)心這個(gè)問題 :)
