具体而言，如果我只关心目录结构而不关心时间戳或其他目录元数据，那么是否可以使用fdatasync代替fsync？如果可以，它是否具有任何性能优势？
POSIX 是否定义了这一点？常见操作系统（例如 Linux 和 FreeBSD）如何处理？
当在目录描述符上使用fdatasync()时，其语义是什么？
3
- yuri kilochek
1个回答
1
从VFS API的角度来看，它通常实现为：同步内容+可选元数据。在目录中，这意味着：同步一些子元数据+可选的自身元数据。
但是，最终如何处理取决于文件系统。
如果属性元数据像Unix文件系统上那样部分解耦，则可能不会刷新，但在其他文件系统上，它可以存储在一起，例如存储以下内容的FAT16：文件名、属性、时间戳、簇号。
从磁盘数据结构的角度来看，在类UNIX文件系统（例如ext4）中，条目包含：inode号、条目长度、类型和文件名。然后inode实际上存储权限、时间戳等属性。
BTRFS虽然更加复杂，但仍属于Unix文件系统的传统范畴，并存储有inode关键字、名称和类型，而inode项则存储了权限、时间戳等信息。
还有一些遵循此传统的文件系统：
- HPFS - NTFS - XFS - UFS/UFS2/FFS - MINIX - F2FS - JFS - BFS - VxFS - ODS-2 (VMS) - UDF
另外还有一些替代实现：
- ReiserFS 和Reiser4（时间戳与inode分别存储）
但即使对于Unix文件系统，哪些元数据被刷新也高度依赖于实现，只有在基础的磁盘格式考虑较少的情况下才会被考虑。
但是，最终如何处理取决于文件系统。
如果属性元数据像Unix文件系统上那样部分解耦，则可能不会刷新，但在其他文件系统上，它可以存储在一起，例如存储以下内容的FAT16：文件名、属性、时间戳、簇号。
从磁盘数据结构的角度来看，在类UNIX文件系统（例如ext4）中，条目包含：inode号、条目长度、类型和文件名。然后inode实际上存储权限、时间戳等属性。
BTRFS虽然更加复杂，但仍属于Unix文件系统的传统范畴，并存储有inode关键字、名称和类型，而inode项则存储了权限、时间戳等信息。
还有一些遵循此传统的文件系统：
- HPFS - NTFS - XFS - UFS/UFS2/FFS - MINIX - F2FS - JFS - BFS - VxFS - ODS-2 (VMS) - UDF
另外还有一些替代实现：
- ReiserFS 和Reiser4（时间戳与inode分别存储）
但即使对于Unix文件系统，哪些元数据被刷新也高度依赖于实现，只有在基础的磁盘格式考虑较少的情况下才会被考虑。
- Ismael Luceno
4
我认为一个目录的“数据”仅指目录项，而目录本身的访问时间/修改时间是“完整元数据”。目录项所引用的文件的元数据也不是。 - yuri kilochek
属性、时间戳和名称是从VFS的角度来看目录条目的一部分。然而，文件系统可以自由地以任何它们认为合适的方式处理这些内容。底层数据结构并没有受到任何限制，元数据可以分成独立的部分。 - Ismael Luceno
不应该将例如最后修改时间戳作为目录项的一部分，因为它所指向的文件可以通过另一个目录中的另一个条目打开并修改。文件系统必须查找所有引用该文件的目录项并更新它们。 - yuri kilochek
从概念上讲，这是可行的方式，并且将其单独存储仅对支持硬链接的文件系统构成问题... - Ismael Luceno
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接