标签: ext4

我正在编写一个需要存储大约1000万个文件的应用程序.

它们目前以UUID命名,每个大约4MB,但总是相同.从/向这些文件读取和写入将始终是顺序的.

我正在寻找2个主要问题的答案:

1)哪种文件系统最适合这种情况.XFS还是ext4？2)是否有必要将文件存储在子目录下以减少单个目录中的文件数量？

对于问题2,我注意到人们已经尝试发现可以存储在单个目录中的文件数量的XFS限制,并且没有找到超过数百万的限制.他们注意到没有性能问题.在ext4下怎么样？

在人们做类似事情时,有些人建议将inode编号存储为文件的链接而不是文件的性能(这是在数据库索引中.我也在使用).但是,我没有看到用于按inode编号打开文件的可用API.这似乎更像是在ext3下提高性能的建议,我不打算顺便使用它.

ext4和XFS限制是什么？从一个到另一个有什么性能优势,你能看到在我的情况下使用ext4而不是XFS的理由吗？

rename(tmppath, path)没有先拨打电话是否安全fsync(tmppath_fd)？

我希望路径始终指向一个完整的文件.我主要关心的是Ext4.在所有未来的Linux内核版本中,rename()承诺是否安全？

Python中的一个用法示例:

def store_atomically(path, data):
    tmppath = path + ".tmp"
    output = open(tmppath, "wb")
    output.write(data)

    output.flush()
    os.fsync(output.fileno())  # The needed fsync().
    output.close()
    os.rename(tmppath, path)

我只创建了大约800万个文件,然后在/ dev/sdb1中没有自由的inode.

[spider@localhost images]$ df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1            8483456 8483456       0  100% /home

有人说可以在格式化分区时指定inode计数.

例如mkfs.ext4 -N 1000000000.

我试过但得到了一个错误:

"inode_size(256)*inodes_count(1000000000)太大了......指定更高inode_ratio(-i)或更低的inode数(N)."

什么是合适的inode_ratio值？

我听说ext4的min inode_ratio值是1024.

是否可以在一个分区上存储十亿个文件？如何？有人说它会很慢.

我需要创建非常多的文件,这些文件不是很大(如4kb,8kb).这在我的计算机上是不可能的,因为它使所有inode达到100%并且我无法创建更多文件:

$ df -i /dev/sda5
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda5            54362112 36381206 17980906   67% /scratch

(我开始删除文件,这就是为什么它现在是67%)

我的文件系统上每个节点的字节数为256(ext4)

$ sudo tune2fs -l /dev/sda5 | grep Inode
Inode count:              54362112
Inodes per group:         8192
Inode blocks per group:   512
Inode size:               256

我想知道是否可以将此值设置得非常低,甚至低于128(在重新格式化期间).如果是,我应该使用什么价值？谢谢

在POSIX文件系统中持久重命名文件的正确方法是什么？特别想知道目录上的fsyncs .(如果这取决于OS/FS,我问的是Linux和ext3/ext4).

注意:在StackOverflow上还有关于持久重命名的其他问题,但是AFAICT它们没有解决fsync-ing目录(这对我来说很重要 - 我甚至不修改文件数据).

我目前有(在Python中):

dstdirfd = open(dstdirpath, O_DIRECTORY|O_RDONLY)
rename(srcdirpath + '/' + filename, dstdirpath + '/' + filename)
fsync(dstdirfd)

具体问题:

• 这是否也暗含fsync源目录？或者我可能会在电源循环后最终显示两个目录中的文件(意味着我必须检查硬链接计数并手动执行恢复),即不可能保证持久的原子移动操作？
• 如果我fsync源目录而不是目标目录,那还会隐式fsync目标目录吗？
• 是否有任何有用的相关测试/调试/学习工具(故障喷射器,内省工具,模拟文件系统等)？

提前致谢.

我有一个程序,可以生成大量的小文件(比方说,10,000个文件).创建它们之后,另一个脚本会逐个访问它们并进行处理.

问题:

• 在性能方面,文件的组织方式(所有在一个目录或多个目录中)是否重要
• 如果是这样,那么每个目录的最佳目录和文件数是多少？

我使用ext4文件系统运行Debian

有关

• Linux上的最大文件/文件夹数量？
• https://serverfault.com/questions/104986/what-is-the-maximum-number-of-files-a-file-system-can-contain

Android使用哪个文件系统？我读过ext4和YAFFS2.

Tim Bray的文章"安全地保存数据"给我留下了悬而未决的问题.今天,已经有一个多月了,我还没有看到任何跟进,所以我决定在这里讨论这个话题.

本文的一点是,在使用FileOutputStream时,应该调用FileDescriptor.sync()以保证安全.起初,我非常恼火,因为在我做Java的12年中,我从未见过任何Java代码进行同步.特别是因为处理文件是一件非常基本的事情.此外,FileOutputStream的标准JavaDoc从未暗示过同步(Java 1.0 - 6).经过一番研究,我认为ext4实际上可能是第一个需要同步的主流文件系统.(是否有建议使用显式同步的其他文件系统？)

我很欣赏这方面的一些一般性想法,但我也有一些具体的问题:

1. Android什么时候会同步到文件系统？这可以是周期性的,另外还可以基于生命周期事件(例如,应用程序的过程进入后台).
2. FileDescriptor.sync()是否负责同步元数据？这是同步已更改文件的目录.与FileChannel.force()比较.
3. 通常,一个不直接写入FileOutputStream.这是我的解决方案(你同意吗？):

   FileOutputStream fileOut = ctx.openFileOutput(file, Context.MODE_PRIVATE);
   BufferedOutputStream out = new BufferedOutputStream(fileOut);
   try {
       out.write(something);
       out.flush();
       fileOut.getFD().sync();
   } finally {
       out.close();
   }
   

我正在编写一个使用Linux异步I/O系统调用的库,并且想知道为什么该io_submit函数在ext4文件系统上表现出较差的扩展.如果可能,我该怎么做io_submit才能阻止大IO请求大小？我已经做了以下(如描述这里):

• 使用O_DIRECT.
• 将IO缓冲区与512字节边界对齐.
• 将缓冲区大小设置为页面大小的倍数.

为了观察内核花了多长时间io_submit,我运行了一个测试,在其中我用dd和创建了1 Gb测试文件/dev/urandom,并重复删除系统缓存(sync; echo 1 > /proc/sys/vm/drop_caches)并读取文件越来越大的部分.在每次迭代中,我打印io_submit了等待读取请求完成所花费的时间和所花费的时间.我在运行Arch Linux的x86-64系统上运行了以下实验,内核版本为3.11.该机器有一个SSD和一个Core i7 CPU.第一个图表绘制了读取的页数与等待io_submit完成所花费的时间.第二个图显示等待读取请求完成所花费的时间.时间以秒为单位.

为了比较,我创建了一个类似的测试,通过使用同步IO pread.结果如下:

似乎异步IO按预期工作,最大请求大小为20,000页.之后,io_submit阻止.这些观察结果导致以下问题:

• 为什么执行时间io_submit不变？
• 是什么导致这种不良的缩放行为？
• 我是否需要将ext4文件系统上的所有读取请求拆分为多个请求,每个请求的大小小于20,000页？
• 20,000的"神奇"价值来自哪里？如果我在另一个Linux系统上运行我的程序,如何确定要使用的最大IO请求大小而不会遇到不良的扩展行为？

用于测试异步IO的代码如下所示.如果您认为它们是相关的,我可以添加其他源列表,但我尝试仅发布我认为可能相关的详细信息.

#include <cstddef>
#include <cstdint>
#include <cstring>
#include <chrono>
#include <iostream>
#include <memory>
#include <fcntl.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
// For `__NR_*` system call definitions.
#include <sys/syscall.h>
#include <linux/aio_abi.h>

static int
io_setup(unsigned n, …

ext4文件系统能否检测到文件内容的数据损坏？如果是,默认情况下是否启用,如何检查损坏的数据？

我已经读过ext4维护文件元数据及其日志的校验和,但我无法找到有关实际文件内容的校验和的任何信息.

为清楚起见:我想知道自上次写操作以来文件是否已更改.