是否将短期文件刷新到磁盘?


9

我的程序创建了许多小的短期文件。它们通常在创建后一秒钟内删除。这些文件位于由真实硬盘支持的ext4文件系统中。我知道Linux会定期将(pdflush)脏页刷新到磁盘。由于我的文件寿命很短,因此很可能不会被缓存pdflush。我的问题是,我的程序会导致大量磁盘写入吗?我关心的是硬盘的寿命。

由于文件很小,因此我们假设它们的大小之和小于dirty_bytesdirty_background_bytes

Ext4已启用默认日志,即元数据日志。我还想知道元数据或数据是否已写入磁盘。


>我的程序创建了许多小的短期文件,“很多”是多少?您要删除这些文件还是重写文件?>我也想知道元数据或数据是否已写入磁盘。我相信默认的元数据模式是有序的,这意味着在将数据写入磁盘之前已提交了元数据。当然,您可以添加一些安装选项来更改此设置。>我的问题是,我的程序会导致大量磁盘写入吗?考虑到您提供的信息,这很难回答。您是否考虑过使用iotopsysstat之类的工具来监视磁盘IO?
AngryWombat

如果您实际上希望微型文件打入磁盘,那么ReiserFS对于微型文件会更好,如果您不在乎,则tmpfs会很好
xenoterracide 2013年

一些澄清:(1)。ext4文件系统未安装sync选件。您可以考虑默认安装的fedora,debian或ubuntu。你选一个。(2)。每个文件约为60KB。(3)。每秒大约创建和删除1000个文件,但是任何时候都不会超过10个文件。换句话说,I / O吞吐量很大,但占用的空间却很小。
Wu Yongzheng

Answers:


5

一个使用ext4的简单实验:

创建一个100MB的图像...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

使其成为循环设备...

# losetup -f --show image
/dev/loop0

创建文件系统并挂载...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

使用短期文件进行某种运行。(将此更改为您喜欢的任何方法。)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Umount,同步,开环。

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

检查图像内容。

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

就我而言,它列出了所有文件名,但没有列出文件内容。因此,只写了内容。


不错的尝试。现在,我确信了。我还尝试了ext2,并得到了与您相同的结果。我将并行I / O工作负载更改为顺序的I / O工作负载,并得到了一个短期文件999和8个短期内容*。有人有解释吗?
Wu Yongzheng

@msw:如果不清楚,请进行编辑。否则请详细说明。
弗罗斯特斯

那真是愚蠢。文件同时存在,没有要覆盖的内容,文件系统也不会覆盖已删除的文件内容,因为这样做会损害性能。但是,请务必使用nbd并记录流量(或跟踪所有写入的类似方法)。
弗罗斯特斯

7

除非您谈论的是固态驱动器,否则磁盘的大量写入不会成为驱动器寿命的主要因素。

如果您真的想完全避免磁盘写入操作,请查看tmpfs


2
在这种情况下,tmpfs确实很合适,但是作为一般的操作系统问题,我仍然想知道是否将数据写入磁盘(不必要)?
Wu Yongzheng

您的问题将需要比可能明确表达的问题要明确得多。缓冲区高速缓存在性能和持久性之间进行了复杂的折衷,而这种折衷不能抽象地解决。使用列出的@AngryWombat工具,您可以测量特定应用程序下的实际写入量,但是有太多因素可能使它因运行而异。
msw

好吧,如果pdflush 删除文件出现。编写它是不必要的。
Wu Yongzheng

1

通常,不,它们不会被编写。这是因为满足以下两个条件之一时,缓存会刷新脏页:

  1. 数据在后老化/proc/sys/vm/dirty_writeback_centisecs,默认为5秒。

  2. 缓存无法容纳数据的内存太少,超过dirty_ratio了缓存中的脏页(默认为20%)。

因此,在一个具有大量可用内存且几乎没有写入流量的系统上,除了在不到5秒的时间内删除的小文件之外,该数据将不会被刷新。


0

短命文件是否写入磁盘不仅取决于内核文件高速缓存的默认行为,还取决于文件系统驱动程序实现的详细信息以及所述文件系统的安装选项。可以通过以下方式配置系统,使所有内容始终立即写入磁盘(本质上是类似DOS的行为)。

XFS是一种文件系统,它具有您感兴趣的行为(即所谓的“延迟分配”)的显着特征。有了它,您可以或多或少地确定(在别处没有有趣的配置选项)在不进行中间磁盘访问的情况下,属于已删除文件的块将在内存中重用。XFS可能仍想更新其元数据日志(会相当频繁地写入磁盘;但是,由于XFS的日志仅是元数据,因此它足够小,可以在其他快速设备上进行设置,例如找到电池供电的RAM在许多RAID控制器上)。

由于这种行为,在突然断电后,发现XFS文件系统上的文件(大小和其他元数据完好无损)会被完全清零,这并不罕见。这是支持快速的“半临时”文件操作的成本。

一些理论

通常,以文件系统驱动程序定义的方法(在注册VFS驱动程序时附加到“ struct inode_operations”和“ struct file_operations”),访问文件系统的系统调用会很快结束。之后发生的情况完全由文件系统实现自行决定。通常,使用类似于以下方法的东西(此简单示例来自linux FAT驱动程序):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

如果文件系统以“同步”模式安装,则所有更改都会立即进入磁盘(在这种情况下,通过fat_sync_inode())。否则,该块将标记为“脏”,并保留在内存高速缓存中,直到有合理机会刷新为止。

因此,在不考虑文件系统挂载选项和检查其实现源代码的情况下,就无法预测有关临时文件的系统行为(当然,这通常适用于大多数在嵌入式空间中发现的各种奇特文件系统) 。


感谢您的回答。似乎ext4也有延迟的分配。这是否意味着我的回答是“否”?(在其他地方都没有有趣的配置选项)。如果使用ext2,这是否还表示我的回答是“是”?
Wu Yongzheng

我认为即使在现代内核上使用ext2,答案也不会。对该问题进行了很多讨论,对内核源代码的简要了解表明ext2驱动程序主要依靠“默认”内核操作来完成其工作(因此,所有操作都会因块缓存而延迟)。我想,我应该更新我的答案,以包括一些额外的信息。
奥卡德

我的ext4显然未安装sync选项。我永远不会那样做。
Wu Yongzheng

将inode标记为脏时,我假设文件系统负责将相应的页面标记为脏。稍后删除inode时,文件系统是否清除脏页面?否则,数据将不必要地刷新到磁盘。
Wu Yongzheng

2
未使用的数据块被“释放”,因此它们不再变脏。如果您将一些东西写到文件中,然后在刷新之前将其截断,则经过EOF的垃圾就会消失(有点)。对于元数据,它可能不是那么简单,因为在文件系统数据结构的完整性方面可能存在各种折衷。顺便说一句,从您的问题中并不总是可以完全控制您的平台-大多数应用程序通常最终运行在配置未知的计算机上,而不是开发人员。
奥卡德
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.