【问题标题】:Simulating file system access模拟文件系统访问
【发布时间】:2011-09-01 17:24:09
【问题描述】:

我正在用户空间设计一个文件系统,需要对其进行测试。我不想使用可用的基准测试工具,因为我的要求不同。所以为了测试文件系统,我希望模拟文件访问操作。为此,我首先使用 ftw() 函数遍历我现有的文件系统(实验)并列出文件中的所有文件和目录。

然后我调用一个模拟器来模拟多个进程的文件访问。因此,模拟器随机启动一个进程,即它分叉一个线程,该线程执行真实进程会执行的操作。线程随机选择一个文件操作(读取、写入、重命名等)从列表中选择该操作的参数(由 ftw() 生成)。线程执行许多此类文件操作,然后退出标记进程结束。模拟器继续产生线程;线程执行可以像真实进程一样重叠。现在,由于操作由线程执行,文件被插入、删除、重命名,并在文件列表中更新。

我还没有开始编码。这个计划看起来合理吗?我也不确定如何编写模拟器......它会如何在一段时间内产生线程。我是否应该使用一些随机延迟来执行此操作。

谢谢

【问题讨论】:

  • 你想达到什么目的?我会坚持飞钓——帽子更好看。

标签: c linux file-io filesystems


【解决方案1】:

是的,这对我来说似乎很合理。我会考虑尝试对您的文件操作(以及对特定文件的访问)进行统计分布,以某种方式与您的预期工作负载相匹配。您也许可以找到一些关于典型文件系统工作负载的统计数据作为起点。

【讨论】:

  • @Gian..谢谢。我在想类似的路线,但不确定我知道该怎么做..有一些我会阅读的参考资料
  • debian-administration.org/articles/388 似乎在谈论他们用来比较文件系统的工作负载。正如他们所建议的那样,复制然后重新复制文件树之类的事情似乎是一个不错的测试。
【解决方案2】:

对于一个体面的测试用例来说,这听起来很合适,只是为了确保它正常工作。您可以使用 sleep() 在生成线程之间等待,或者一次全部生成它们并让它们执行一个操作,然后稍等,然后执行另一个操作,等等... IMO 如果您遇到很多请求和它可以工作,那么您的文件系统很可能会做得很好。以 PostMark 为例,它所做的只是疯狂地附加到不同的文件和其他基准测试中,这些基准测试在不同的位置进行随机访问读/写,以确保必须从磁盘读取页面。

【讨论】:

  • 谢谢..我的要求是诱导进程间文件共享
  • 实际上带有文件的IPC应该由操作系统和共享内存页面来完成。如果您的意思是让多个进程同时打开和编辑文件,那么您可能无法获得正确性,因为操作系统(除非您重写了一些东西)可以并且将重新排列块 I/O 向量并将它们合并,这将产生不正确的输出。
  • 我已经编写了代码来处理共享...这就是我想要检查的内容
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-11-08
  • 1970-01-01
  • 1970-01-01
  • 2011-12-11
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多