文件系统大小限制

大猫

原帖由 "哇哈哈" 发表：
有一种情况就是inode节点已经用完，但空间没有用完，这是为什么？
通常这种问题的原因就是nbpi设定太大造成的，这样的话也就是说文件系统建立后，其inode数也就限制了，但这个数远不是16M，为什么？

16m是最大值! nbpi不能改了, 但fs可以扩, inode数=fs size/nbpi

哇哈哈

不对吧，如果是这样，那怎么会出现文件系统中inode不够用的情况，比如8M文件系统，4K nbps，那么应该能放2048个inode（或文件及目录），只要文件大小不为0，那么永远也占用不完inode，那怎么还会出现inode已经用100%而文件系统空间没有用完的情况？

是不是inode空间如果占用不足4k，则其余下的空间可以存储真正的文件内容？如果是这样的话，也就是：比如一个100 byte的文件，因其内容太少，所以加上inode也没有用完4k，这样就省下一部分空间给其它的文件或inode使用，是不是这样？

感谢ing

老农

哇哈哈，你的概念错误都让我不知道该怎么说了：（
INODE不占用数据块！你可以把它理解为图书的索引表。

大猫

[quote]原帖由 "哇哈哈"]不对吧，如果是这样，那怎么会出现文件系统中inode不够用的情况，比如8M文件系统，4K nbps，那么应该能放2048个inode（或文件及目录），只要文件大小不为0，那么永远也占用不完inode，那怎么还会出现inode已经用100%..........[/quote 发表：

头一个问题,你的分析方法是对的, 如果fragment size用default的4k, nbpi也为default 4k, 确实不会出现inode已经用100%的情况.
另外, 纠正你一个概念错误, inode的大小不可能是4k, 一般是单字节, 有时是多字节(我前面已提到), 也许几k个inode会占4k

哇哈哈

JFS supports nbpi values of 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, and 131072. The values 32768, 65536, and 131072 only apply to AIX Version 4.2 or later.

这不是说inode大小可以是这些值吗？nbip不是number byte per inode？

大猫

原帖由 "哇哈哈" 发表：
JFS supports nbpi values of 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, and 131072. The values 32768, 65536, and 131072 only apply to AIX Version 4.2 or later.

这不是说inode大小可以是这些值?.........

Number of bytes per inode意思是：平均每节点管理多大空间
看看redbook吧

老农

并不是说INODE的大小，而是每个INODE平均对应的数据块的大小。
我白给你解释那么形象了，你还真够倔的：（

哇哈哈

谢谢大猫及老农，原来我一直理解错了。真不好意思，如果有机会见面，我请你们吃饭好了。

老农啊，你没有见过我就知道我的性格，这就是经验。不说我说理，只要道理讲通了，我服了You。

多谢！多谢！

ydar

我觉得首先弄明白：为什么要引入”inode“，它的作用是什么？
引用下面一片短文《索引节点inode》

　　　Linux为每个文件分配一个称为索引节点的号码inode，可以将inode简单理解成一个指针，它永远指向本文件的具体存储位置。系统是通过索引节点(而不是文件名)来定位每一个文件。例如：假设我们在硬盘当前目录下建立了一个名为mytext文本文件，其内容只有一行：This　is　my　file.当然这行文字一定是存储在磁盘数据区某个具体位置里(物理上要通过磁头号、柱面号和扇区号来描述，在本例中假设分别是1、20、30)。假设其inode是262457，那么系统通过一段标准程序，就能将这个inode转换成存放此文件的具体物理地址(1磁头、20柱面、30扇区)，最终读出文件的内容：“This　is　my　file.”
所以inode是指向一个文件数据区的指针号码，一个inode对应着系统中唯一的一片物理数据区，而位于两个不同物理数据区的文件必定分别对应着两个不同的inode号码。
　　　文件拷贝命令： #　cp　/home/zyd/mytext　newfile　在当前工作目录建立了一个新文件newfile，其实际操作主要包括如下三步：
　　　1、在当前目录中增加一个目录项，其文件名域填入newfile，并分配了一个新的inode，假设是262456。
　　　2、将原文件(在1磁头、20柱面、30扇区)的内容复制了一份到新的空闲物理块(假设是1磁头、20柱面、31扇区)。
　　　3、填写一些其他关键信息，使系统通过这些信息及inode号码可以完成物理地址的转换。
　　　所以文件复制要分配新的inode和新的数据区，虽然两个文件的内容是一样的。

    一个文件系统允许的inode节点数是有限的，如果文件数量太多，即使每个文件都是0字节的空文件，系统最终也会因为节点空间耗尽而不能再创建文件。所以当发现不能建立文件时首先要考虑硬盘数据区是否还有空间(可通过du命令)，其次还得检查节点空间。
    Linux之所以能支持多种文件系统，其实是由于Linux提供了一个虚拟文件系统VFS，VFS作为实际文件系统的上层软件，掩盖了实际文件系统底层的具体结构差异，为系统访问位于不同文件系统的文件提供了一个统一的接口。实际上许多文件系统并不具备inode结构，其目录结构也和以上的讨论不同，但通过VFS，系统均为其提供了虚拟一致的inode和目录项结构。所以，'ls　-il'命令实际显示的inode应该是VFS　inode，也就是说，inode是存在于内存中的数据结构，而不一定是实际的硬盘结构。但为Linux量身定做的ext2文件系统具备实际的inode和连接型目录项结构

但也由几个问题拿捏不准，希望得到确切答复：
1、jfs逻辑上是不是也可以理解为这种结构？
   引导块+超级块+索引节点表+数据块
2、nbpi是不是文件分配中最小的逻辑单元？
3、假设某个文件对应的节点号为n，大小为2.5个nbpi，那么下个可供顺序分配的节点号是不是n+3，是不是第n+2个节点对应的nbpi中约有一半的空间闲置？

augusta

我讨厌理解这些东西