如何使用执行增量 read() 的 C 程序来确定文件系统使用的块大小?
How to determine the block size used by the file system by using a C program that performs incremental read()'s?
我正在通过做一些教科书练习题来准备我的考试。我被困在其中一个问题上,该问题要求我们通过使用执行大小递增的 read() 的 C 程序来查找计算机文件系统使用的块大小。
教科书给了我们这样的提示:
使用不同大小的读取(确保大小足够大)分析执行此类读取所需的时间。顺序读取可能会受到预取的影响,因此请考虑到这一点。
我对以下内容感到困惑:
1) 我不明白执行递增大小的读取有何帮助
确定块大小?
2) Sequential reads may affected by prefetching so take this into account.
是什么意思?
3) 每轮递增大小的时候,每次都要从头读吗?还是从我开始的地方继续阅读?
非常感谢任何帮助。
算法思路
尝试不同的大小,并通过一次 "block" 的试验来记录读取 X
字节所花费的时间。
我不会 "read from the start every time" 也不会 "keep reading from the point I started",在子测试之间,但会提前避免使用预取数据。
写一个大文件作为设置填充随机数据。
假设块大小为 S1smallest, S2, S3, S4, ... or SnLargest
字节。 (例如 100、256、1000、1024、4096、65536 等
让n = 100
.
1) 从 addr=0
开始
2) 总共读取n*S5Largest
字节数据,一次读取S1smallest
字节。报告经过的时间。
3) fseek()
n*S5Largest
字节超出您所在的位置。 (这是为了顺利通过任何预取数据。)
4) 重复步骤 2),大小为 S2
而不是 S1smallest
。和步骤 3)
5) 对剩余尺寸 S3 .... SnLargest
.
执行步骤 4)
最好的时机是一个好的候选人获胜者。以块大小的相反顺序尝试相同的测试,以确保您获得一致的结果。
预先计算执行此测试所需的大小以确保原始文件足够大。
伙计,多么愚蠢的教科书。
1) I dont get how performing reads of incrementing sizes would help determine the block size?
块大小将是 2 的幂。理论上,如果您读取
2^0, 2^1, 2^2, . . . . 2^N
从文件开头(或从块边界偏移)开始的字节,这些操作将花费相同的时间,直到 N 超过块大小(即需要 2 次读取才能服务)。
2) What does it mean by Sequential reads may affected by prefetching so take this into account.?
如果您读取文件中的第一个块,OS 可能会获取第二个块并将其缓存起来,以期需要下一个块。那会打乱时间。所以你需要从随机位置读取。
3) When incrementing the size each round, do I have to read from the start every time? Or keep reading from the point I started?
您想从一个随机位置读取,但该位置应该是大于块大小(例如 2^20)的 2 的幂的倍数。如果您使用任何旧的随机值,您可能会进行 2 次块读取,即使只有 2 个字节。
由于以下原因,我不确定建议的提示(书中)是否是获取块大小的正确方法
(1) 文件系统内部可以有可变块。
(2) 预取是更内部的实现,通常它的目标是确保从内存中读取(即没有磁盘 I/O 成本),特别是对于顺序读取。
我认为一种块大小的方法(至少对于磁盘文件系统和固定块大小):
一般而言,文件系统块大小为4K、8K、16K、32K、64K等(4K的倍数)。在 UNIX 中会有 "du(1) " 给出文件在磁盘上的实际消耗量。
可以创建具有不同字节的不同文件大小的文件,并且可以了解文件正在增长的多个块大小。
我正在通过做一些教科书练习题来准备我的考试。我被困在其中一个问题上,该问题要求我们通过使用执行大小递增的 read() 的 C 程序来查找计算机文件系统使用的块大小。
教科书给了我们这样的提示:
使用不同大小的读取(确保大小足够大)分析执行此类读取所需的时间。顺序读取可能会受到预取的影响,因此请考虑到这一点。
我对以下内容感到困惑:
1) 我不明白执行递增大小的读取有何帮助 确定块大小?
2) Sequential reads may affected by prefetching so take this into account.
是什么意思?
3) 每轮递增大小的时候,每次都要从头读吗?还是从我开始的地方继续阅读?
非常感谢任何帮助。
算法思路
尝试不同的大小,并通过一次 "block" 的试验来记录读取 X
字节所花费的时间。
我不会 "read from the start every time" 也不会 "keep reading from the point I started",在子测试之间,但会提前避免使用预取数据。
写一个大文件作为设置填充随机数据。
假设块大小为 S1smallest, S2, S3, S4, ... or SnLargest
字节。 (例如 100、256、1000、1024、4096、65536 等
让n = 100
.
1) 从 addr=0
2) 总共读取n*S5Largest
字节数据,一次读取S1smallest
字节。报告经过的时间。
3) fseek()
n*S5Largest
字节超出您所在的位置。 (这是为了顺利通过任何预取数据。)
4) 重复步骤 2),大小为 S2
而不是 S1smallest
。和步骤 3)
5) 对剩余尺寸 S3 .... SnLargest
.
最好的时机是一个好的候选人获胜者。以块大小的相反顺序尝试相同的测试,以确保您获得一致的结果。
预先计算执行此测试所需的大小以确保原始文件足够大。
伙计,多么愚蠢的教科书。
1) I dont get how performing reads of incrementing sizes would help determine the block size?
块大小将是 2 的幂。理论上,如果您读取
2^0, 2^1, 2^2, . . . . 2^N
从文件开头(或从块边界偏移)开始的字节,这些操作将花费相同的时间,直到 N 超过块大小(即需要 2 次读取才能服务)。
2) What does it mean by Sequential reads may affected by prefetching so take this into account.?
如果您读取文件中的第一个块,OS 可能会获取第二个块并将其缓存起来,以期需要下一个块。那会打乱时间。所以你需要从随机位置读取。
3) When incrementing the size each round, do I have to read from the start every time? Or keep reading from the point I started?
您想从一个随机位置读取,但该位置应该是大于块大小(例如 2^20)的 2 的幂的倍数。如果您使用任何旧的随机值,您可能会进行 2 次块读取,即使只有 2 个字节。
由于以下原因,我不确定建议的提示(书中)是否是获取块大小的正确方法
(1) 文件系统内部可以有可变块。
(2) 预取是更内部的实现,通常它的目标是确保从内存中读取(即没有磁盘 I/O 成本),特别是对于顺序读取。
我认为一种块大小的方法(至少对于磁盘文件系统和固定块大小):
一般而言,文件系统块大小为4K、8K、16K、32K、64K等(4K的倍数)。在 UNIX 中会有 "du(1) " 给出文件在磁盘上的实际消耗量。
可以创建具有不同字节的不同文件大小的文件,并且可以了解文件正在增长的多个块大小。