小编sta*_*ona的帖子

我注意到当我做一个：

ls -ls file

它提供块数，比如 8 个块。

当我做：

stat file

我注意到块数是 16，是 ls 给出的数字的两倍。

我的文件系统上的块大小是 4096。我了解到 ls 使用的块的任意单位是 1024。说 stat 在报告块时使用 512 字节的任意单位是否正确？

如果是这样，是否有不一致的原因？

我在 ext4 文件系统上运行 Ubuntu 11.10。

我运行了程序 pstree -p 31872 ，它打印了以下输出：

 ruby(31872)???{ruby}(31906)         
             ??{ruby}(32372)

pstree 的手册页说：

进程的子线程位于父进程下，并用花括号中的进程名称显示，例如

       icecast2---13*[{icecast2}]

Run Code Online (Sandbox Code Playgroud)

（以上显示不同，因为缺少 -p 选项，禁用压缩。）

在没有 -p 的情况下运行 pstree 31872 给出：

ruby???2*[{ruby}] 

当我尝试使用ps观察那些 PIDS 时，没有找到任何结果。但是，pid 存在于 /proc 中。

我的问题是，为什么线程会有不同的 pid？我希望它们与过程相同（31872）。运行 htop 时观察到相同的行为。

为了我自己的学习，我一直在尝试创建带有文件漏洞的文件。我创建了一个 util，它只是从 stdin 读取并写入文件，但在写入文件之前，它使用 lseek 将文件末尾移出多个字节。

fh -b 20000 testfile
hello
there

启动此过程后，可以输入输入（“hello”），并将其写入 testfile，但在此之前，它会查找文件末尾的 20000 字节。然后在写入之前，它会在写入“那里”之前再次寻找超过文件末尾的另外 20000 个字节。

我不清楚的是分配给新创建的文件的块数。如果我做

ls -ls testfile

它显示分配了 8 个块，文件大小为 40013（这是预期的）。

一个有 13 个字节（但没有文件空洞）的新文件根据ls -ls. 我发现这实际上意味着 1 个块（一个块为 2048 个字节），但报告的块可被 512 个字节整除。所以假设这是真的，数学不会计算带有文件漏洞的文件。为什么分配了 8 个块，因为物理文件大小只有 13 个字节（与 40013 的逻辑大小相反），所以它不应该仍然只有 4 个吗？

我不确定我是否正确读取了块大小，其次，考虑到没有文件孔的类似大小的文件只有 4，我不明白为什么块大小是 8。

我在 ext4 文件系统上运行 Ubuntu 11.10。