关于XFS文件系统的一个问题

[hank.peng]

机器上跑的内核是2.6.20, 32位。
现在创建了一个2.5T大小的XFS文件系统，用于ftp共享，里面存的文件数量非常多，今天发现一个问题：
在用df -h命令查看剩余空间还有70多G，但是却不能往里面写任何东西了，报错：no space left on this device.
我现在怀疑是由于XFS的inode引起的，不知道大家有没有遇到过类似的情况。

--
The simplest is not all best but the best is surely the simplest!
_______________________________________________
Linux 内核开发中文邮件列表
Linux-...@zh-kernel.org
http://zh-kernel.org/mailman/listinfo/linux-kernel
Linux 内核开发中文社区： http://zh-kernel.org

[heyman.yyl]

hank.peng<peng...@gmail.com> 写到：

>机器上跑的内核是2.6.20, 32位。
>现在创建了一个2.5T大小的XFS文件系统，用于ftp共享，里面存的文件数量非常多，今天发现一个问题：
>在用df -h命令查看剩余空间还有70多G，但是却不能往里面写任何东西了，报错：no space left on this device.
>我现在怀疑是由于XFS的inode引起的，不知道大家有没有遇到过类似的情况。

在JFFS2文件系统上遇到过这个问题，貌似是JFSS2 的GC回收算法有BUG,找了很久都没解决办法，后来只能换新的文件系统~

[hank.peng]

今天在网上查了一下这个问题，的确是由于XFS的inode引起的，因为如果当data部分将前面1T的空间占满了的话，在分配inode的时候就需要到1T范围以外的地方去分配，这样32bit就表示不下了。
SGI的开发人员给出的solution有两个：
1.删去前面的部分文件，好在前1T空间腾出部分空间用于分配inode。
2.用64bit的内核。

第一种方法就等于没有，至于第二种，我试图在我的32位机器上编译64bit内核，但是一开始就报错，这里想问一下大家：如果我真的想编一个64位的内核，是不是需要在64位机器上或者是运行64位内核和软件的机器上编译呢？

2008/7/8 heyman.yyl <heyma...@gmail.com>:

>
> hank.peng<peng...@gmail.com> 写到：
>>机器上跑的内核是2.6.20, 32位。
>>现在创建了一个2.5T大小的XFS文件系统，用于ftp共享，里面存的文件数量非常多，今天发现一个问题：
>>在用df -h命令查看剩余空间还有70多G，但是却不能往里面写任何东西了，报错：no space left on this device.
>>我现在怀疑是由于XFS的inode引起的，不知道大家有没有遇到过类似的情况。
>
> 在JFFS2文件系统上遇到过这个问题，貌似是JFSS2 的GC回收算法有BUG,找了很久都没解决办法，后来只能换新的文件系统~
>
>

--

The simplest is not all best but the best is surely the simplest!

[hank.peng]

2008/7/9 Danny Lau <liud...@gmail.com>:
> 数据结构用64位表示就可以了（两个u64）。不一定要用64位内核和机器，就如同128位的zfs一样可以用在x86 freebsd中一样。
> 2.6.20中xfs_inode.h里面的i_ino是u64的，在gnu C里面定义为unsigned long long。
> 所以，你的说法我表示一些怀疑。
>
昨天在xfs的邮件列表里也有人提出你这样的疑问，但是SGI的开发人员没有对此进行解释。
如果简单的用unsigned long long结构，那我想SGI的家伙们也不会想不到。
你可以看一下内核中XFS_BIGINUM这个宏定义为1的前提条件是BITS_PER_LONG == 64，也就是必须在64位机器上。

这个问题让我对XFS感到巨失望，难道逼得人家去搞64位机器？
>
> 2008/7/8 hank. peng <peng...@gmail.com>:

> --
> -dan

[Chen Gong]

你这个是很常见的。一个分区满了本来就是有两种情况。磁盘空间不够和inode节点
不够。所以你要做的就是增大inode的设置，应该在/proc下有对应的设置吧，具体我
不记得了。你可以g一下看看

[Li Zefan]

Chen Gong 写道:

> 你这个是很常见的。一个分区满了本来就是有两种情况。磁盘空间不够和inode节点
> 不够。所以你要做的就是增大inode的设置，应该在/proc下有对应的设置吧，具体我
> 不记得了。你可以g一下看看
>

inode的数目，在创建文件系统的时候就固定了，没法改的。至少ext3和ext4是这样的。

[hank.peng]

2008/7/9 Li Zefan <li...@cn.fujitsu.com>:

> Chen Gong 写道:
>> 你这个是很常见的。一个分区满了本来就是有两种情况。磁盘空间不够和inode节点
>> 不够。所以你要做的就是增大inode的设置，应该在/proc下有对应的设置吧，具体我
>> 不记得了。你可以g一下看看
>>
>
> inode的数目，在创建文件系统的时候就固定了，没法改的。至少ext3和ext4是这样的。
>

通过df -i可以看到inode数目的使用情况，在出问题的那个文件系统下查看了一下，inode才使用1%，主要问题是inode分配到1TB以外空间的时候，32bit就不能表示这个inode号了，所以就报错no
space left on device，其实是个假象。

XFS有个allocation
group的概念，它把整个分区划分成很多个同样大小的AG，每个AG里面包含数据和inode，当创建文件，要去分配inode，它会依次查找每个AG，找出一定大小（具体值忘记了）的连续空间以分配给inode，当data占满最前面的1TB或者由于文件碎片的存在，当它在前面1TB找不到时，就会到接下来的空间也就是1TB以外来找，这时候在32bit机器上就出现问题了。

[霍澄平]

>> 这个问题让我对XFS感到巨失望，难道逼得人家去搞64位机器？

如果一个系统面面俱到，结果很可能是性能很差，缺乏实用性。技术进步是同步的，不能小马拉大车。

2008/7/9 hank. peng <peng...@gmail.com>:

[Danny Lau]

我没有在kernel里面grep到XFS_BIGINUM这个东西（2.6.25和2.6.20都无）

无论如何，sizeof u64，在32位的x86上都是8，XFS在32bit的linux上，文件和文件系统的限制是16T。
另外，xfs的inode分配是动态分配的，不会出现类似ufs/ext3那样的no inode的情况。

可能还有其他情况我没有想到，从我现在想到的两个情况：1是inode的表示范围（u64），2是inode本身的分配（动态），我都比较怀疑把问题定位到32位系统的inode上-----超过1T导致问题出现。

2008/7/9 hank. peng <peng...@gmail.com>:

--
-dan

[hank.peng]

2008/7/10 Danny Lau <liud...@gmail.com>:
> 我没有在kernel里面grep到XFS_BIGINUM这个东西（2.6.25和2.6.20都无）
>
sorry,是XFS_BIG_INUMS在fs/xfs/linux-2.6/xfs_linux.h这个文件中。

> 无论如何，sizeof u64，在32位的x86上都是8，XFS在32bit的linux上，文件和文件系统的限制是16T。
> 另外，xfs的inode分配是动态分配的，不会出现类似ufs/ext3那样的no inode的情况。
>
> 可能还有其他情况我没有想到，从我现在想到的两个情况：1是inode的表示范围（u64），2是inode本身的分配（动态），我都比较怀疑把问题定位到32位系统的inode上-----超过1T导致问题出现。
>

有兴趣看一下这个thread，应该就是这个问题了，但是没有好的解决办法。

http://oss.sgi.com/archives/xfs/2007-02/msg00016.html

[Danny Lau]

谢谢你的link，大概看了下代码，xfs出现这种情况，应该和它的动态inode分配策略有关系。mount 里面有一个-o
inode64，它的意义是"inodes can be allocated
anywhere"，换句话说，inode32就是cannot，呵呵。

至于为什么inode32 cannot，就没有继续追究啦。

2008/7/10 hank. peng <peng...@gmail.com>:

--
-dan