问题标签 [disk-io]

我正在阅读硬盘的 FAT32 条目，到目前为止，我已经通过使用 、 和 API 成功地读取了CreateFile这些ReadFile条目SetFilePointer。到目前为止，这是我的代码（用 C# 编写）。

---DLL 导入-----

------CODE----将在任何.NET应用程序中工作------

上面的代码读取F:\驱动器，出于试用目的，我已将其读取第一个文件目录集群并查询每个文件条目，如果文件已被删除，则显示文件名。

但是，我想将它变成一个成熟的应用程序，为此我将不得不经常使用字节数组并将其映射到根据 FAT32 规范指定的数据结构。

如何有效地使用读取数据的字节数组？我已经使用 filestream 和 binaryreader 尝试了相同的代码并且它可以工作，但是现在假设我有一个类似的 C 结构

我想在 C# 中有一个类似的数据结构，当我将数据读取到字节数组时，我想将它映射到结构中。我尝试了很多选择，但没有得到完整的解决方案。我也尝试过开设课程并进行序列化，但这也没有用。当我从 FAT 条目中读取数据时，我将使用大约 3 个类似 theese 的结构。我怎样才能最好地达到预期的结果？

当有大量文件（超过 100,000 个）时，我试图找出在特定目录中查找文件数量的最佳方法。

当有那么多文件时，执行ls | wc -l需要很长时间才能执行。我相信这是因为它返回了所有文件的名称。我试图尽可能少地占用磁盘 I/O。

我尝试了一些 shell 和 Perl 脚本，但无济于事。我该怎么做？

我在处理一个大型项目时遇到了一个非常奇怪的问题。我在一个分区上写了一堆相同大小的文件（尝试了通过创建的 RAM 磁盘和虚拟磁盘diskmgmt.msc）。当没有足够的可用空间来容纳另一个文件时（如 报告GetDiskFreeSpaceExW），我删除了一个（仅一个）先前创建的文件并写入新文件。然后，我删除另一个旧文件并写入一个新文件，无限期地写（因此，您可能会将分区视为大小相同的文件的环形缓冲区）。在一系列写入删除（从几百到几千）之后，我no free space在编写新文件时遇到了错误（在此之前，GetDiskFreeSpaceExW报告了足够的空间）。我请我的几个同事尝试在他们的硬件上重现该问题，但问题没有重新浮出水面。

为了澄清一点，这里是确切的算法：

1. 选择文件大小（比如 S 字节）
2. 使用 GetDiskFreeSpaceExW 检查可用空间
3. 如果 free_space > S：写入大小为 S 的新文件并转到 2
4. 否则：删除一个文件并转到 2

需要注意的是，我以 4096 字节大小的块将数据写入文件（问题可能会或可能不会重新出现，具体取决于块大小）。文件大小为 5MB。NTFS 分区大小为 21 MiB。集群大小为 512 B（同样，更改这些参数会影响结果）。使用这些参数，在创建第 684 个文件期间会发生故障。它不取决于我是使用 RAM 磁盘还是虚拟磁盘（因此，这不是特定实现的问题）。

我分析了故障后生成的磁盘映像转储，发现文件碎片严重。Chkdsk 在实验前后都没有报告任何问题。在系统日志中没有发现错误。

我的上网本（Dell Inspiron 1110）的可能相关参数：

• Pentium SU4100，相对较慢的双核 x64 CULV CPU (1.3 GHz)
• Windows 7 Ultimate x64 版
• 2 GB 内存

有谁知道发生了什么以及如何调试它？我在哪里可以找到更多信息？我已经没有想法了，我需要尽快解决这个问题......

UPD：问题发生在我写入文件数据（即write()失败）时，而不是在我创建文件时。所以，看起来我并不缺少 MFT 条目。

UPD2：回答一些被问到的问题

• 该分区是一个新格式化的分区，因此没有文件的特定属性，没有目录结构，什么都没有
• 权限是默认的
• 没有 .lnk，没有硬链接 - _only_ 我写的文件
• 所有文件都写入根目录，不再创建目录
• 文件名只是文件的序号（即 1、2、3、...）
• 没有备用数据流，文件使用 `fopen()` 创建，使用 `fwrite()` 写入并使用 `fclose()` 关闭
• $Txf 确实被创建了
• 没有坏集群，这是一个虚拟（或 RAM）磁盘

我想测试文件系统在不同条件下的性能。

具体来说，我想在“普通硬盘”和 USB 磁盘上测试没有压缩和压缩的 Windows 虚拟机的性能，因为看看到底有什么区别会很有趣。

我需要的是一个程序，它可以测试文件系统的不同方面（随机访问、顺序读/写等）并制作与我的博客相得益彰的漂亮图表。最好应用程序应该是自动化的，这样我就可以将它添加到启动中，这样每次运行的时间都是相同的，我可以重复运行以进行验证。

当我开始测试它时，我可以在此处发布结果链接。现在它只是在计划阶段。

我正在寻找一个在 OS X Lion 上运行的好实用程序，它可以为我提供每个进程的 CPU 使用率和磁盘 I/O 的摘要。我不想监视即时使用情况，而是要找出每个进程在一段时间内（如一天的工作）内的平均 CPU 和磁盘使用情况。

我的 Mac 上还有一个在 VMWare Fusion 上运行 WinXP 的 VM，所以如果您知道类似的 PC 实用程序，它会很有用。

每次从项目目录构建项目时，我都会运行此命令：

而且我不明白为什么连续运行比第一次快 10 倍。实际上，我在其他涉及大目录（计算目录大小、代码提交等）的磁盘 IO 操作中看到了这种行为。我认为这与操作系统的磁盘 IO 内部有关。可能它在某种程度上正在缓存。有人能把我的鼻子指向正确的方向吗？

我正在尝试在使用 MySQL 开发的 webapp 上模拟行级安全性。

使用此方法：使用所需的表创建一个数据库，其中将存储与所有用户有关的数据，并对表的列进行适当的索引。

根据用户 ID 为特定用户创建 mysql“视图”。

为了实现行级安全性，我还必须为每个用户创建 mysql 帐户并设置视图的“授予”权限。

对于 Web 界面，将使用基于 PHP 的 MVC 框架。

但是，根据我的研究：

1] Having separate mysql account per user "make the webapp less secure".
2]Having separate mysql account per user "increases the disk I/O".

问题：
1] How does creating mysql user per webapp user make the webapp less secure?
2] Does the disk I/O increase considerably?
3] Is there a better way to implement row-level-security in MySQL?
4]What are the pros/cons of implementing row-level-security by the above method?

为什么我要查看行级安全性？
I need row level security because there are rows which will be shared between multiple users & have 1 or 2 owners to it. Only these owners can delete/modify them.

我已经在 Python 中实现了一个后缀树来进行全文搜索，它运行得非常好。但是有一个问题：索引文本可能非常大，所以我们无法在 RAM 中拥有整个结构。

图片：单词的后缀树BANANAS（在我的场景中，想象一棵树大 100000 倍）。

所以，稍微研究了一下，我发现了这个pickle模块，一个很棒的 Python 模块，用于从/到文件中“加载”和“转储”对象，你猜怎么着？它与我的数据结构完美配合。

所以，长话短说：在磁盘上/从磁盘上存储和检索这种结构的最佳策略是什么？我的意思是，一种解决方案可能是将每个节点存储在一个文件中，并在需要时从磁盘加载它，但这不是最好的想法（磁盘访问次数过多）。

脚注：虽然我已将此问题标记为python，但编程语言并不是问题的重要部分，磁盘存储/检索策略确实是重点。

好的，到目前为止，我一直在主内存中开发一个系统，该系统具有许多不同的对象，每个对象都存储系统中其他对象的列表。现在我想将其移至持久存储。我不是在寻找使用 DBMS 的明显答案，因为重点是我正在为我的系统编写自定义数据库。

现在为每个对象分配一个 ID。可以在表中查找 id，以找到该对象的数据位置的块和偏移量。现在每个对象都有指向系统中其他对象的列表/集合。所以很明显，在存储中，它们将是 8 字节的列表（使用 long 作为 id）id，可用于查找其他对象。现在我的问题是，我知道这些列表会随着时间的推移而增长，因此它们需要增长空间。到目前为止，我存储列表以便在对象增长时不需要在对象周围移动的最佳想法是为每个列表分配一个 id，就像对象一样，以便它们可以像要查找的对象一样在表中查找它们在磁盘上。

现在每个列表部分将有一组分配的空间来存储 10 个对象，然后如果它包含更多对象，最后将是下一个列表部分的 id。这似乎是一种不错的方法来处理不断增长的对象，但我想知道是否有更好的方法。我会将索引存储在内存中（空间允许），因此给定一个对象 id，查找在内存中，然后需要 1 个 I/O 才能找到从磁盘获取它的数据和列表 id。然后对于您要遍历的每个列表，如果块被缓存，则列表中的每 10 个对象或更少的对象将进行另一次查找和 I/O。

I/O 的数量并不可怕，我会尝试保持列表部分的局部性以消除不必要的 I/O，但是有更好的方法吗？我是否应该尝试将列表与对象分开存储，或者我应该考虑将它们与对象数据一起存储的方法。我对此的担心是，随着一个列表的增长，它会进入另一个列表，然后需要被分割，这可能会变得更加复杂。任何建议表示赞赏并提前感谢。

我想解析 MySQL 常规日志并将该信息存储在另一台服务器上。

我想知道让 MySQL 将其日志写入 Linux 命名管道 FIFO 而不是仅移动日志文件然后解析它是否会提高性能。

我的目标是删除硬盘访问并提高 MySQL 服务器的性能。

这一切都是在 Linux centos 上完成的。

那么 FIFO 是使用磁盘访问还是一切都在内存中完成？

如果我让 MySQL 写入 FIFO，并且有一个在内存中运行的进程解析该信息，然后将其发送到不同的服务器，这会节省磁盘写入吗？

这也比将 MySQL 通用日志存储到 MySQL 数据库中更好。我注意到插入语句可以为脚本添加 0.2 秒。所以我想知道我是否打开 MySQL 的日志记录，它会为每个运行的查询添加 .2。