Talk:Comparison of file systems

NTFS 6.0

There does not exist any NTFS 6.0 ! There are only system extentions of Windows NT 6.0 (Vista/2008) but inside the specifications of the current NTFS 3.1

Modification Time

In the Metadata table, we need a Modification Timestamp, and the "Last metadata change timestamps" column might need to be clearer as to what it means.. — Preceding unsigned comment added by 174.116.11.227 (talk) 14:00, 21 September 2023 (UTC)

Agreed. It would be prudent to include this with a more precise title, such as "Last content change timestamps".

(a list of common terms, such as "Modification date" or "Modification timestamp", can be placed in an {{EFN}} if necessary for clarity)

-- Jim Grisham (talk) 17:43, 5 June 2024 (UTC)

Somewhat related: the "Last metadata change timestamp" behaves differently between many file systems for directories. (Some only update the date when the directory metadata, excluding the list of contained files, changes, some update the date when the directory is moved or copied even if no metadata or contained files change ... although that is likely to be more of an OS/driver issue, some update the date when the list of contained files changes but not of an individual file is changed, etc.)

These distinctions should be noted by editors in the table whenever possible. Jim Grisham (talk) 17:52, 5 June 2024 (UTC)

Concurrency safety?

Information about how filesystems deal with being simultaneously mounted on multiple server I.E. accessed concurrently by multiple systems would be important. Especially nowerdays as everything is moving to more and more "cloud-philosophy". Only a few filesystems support RW access from multiple independent servers to the same shared backing block device. Many/Most however support single RW and multiple RO access just fine. And only a few don't support any concurrency at all. And in cases of where single RW and multiple RO access works, it should be noted if that is enforced by the filesystem (e.g. by checking timestamps) or not.

This kind of safety is often also referred to as shared-disk file system. As formerly stated, such setups are very commonly used for: backup purposes (backup server has a RO mount of the production filesystem), server rooms and centers that have a dedicated storage network (SAN), virtual machines, ... Agowa (talk) 10:15, 23 October 2023 (UTC)

ReFS limits

The limits in this article are not the same as in the ReFS article. The limit is 35PB. Can someone verify it and fix? ויקיטכני (talk) 19:11, 26 March 2024 (UTC)

Support for multiple virtual file systems

I'm not sure what the actual term for these are, APFS calls them 'containers', btrfs 'subvolumes', zfs 'datasets', but it's the support for multiple virtual file systems, backed by the same partition on the same block device.

Would it be worth it to add another column on the support tables for these? Foxtdev (talk) 16:52, 3 July 2024 (UTC)

APFS calls them 'containers' APFS calls a disk or partition (or a RAID group) a "container", with "volumes" containing file systems inside it (and there can also a be "volume group" within a container, with multiple volumes in the volume group), at least according to Disk Utility on macOS Ventura. So the name for a file system in APFS appears to be "volume", not "container".

it's the support for multiple virtual file systems Unfortunately, virtual file system already has a different meaning, so it's not really the right choice of name.

backed by the same partition on the same block device With ZFS, a zpool can have more than one vdev, and a vdev can have multiple physical devices. As noted, macOS supports RAID, so a container can also consist of multiple physical devices, and, given Linux's LVM, the same is presumably true of whatever btrfs subvolumes are contained in.

I think of it as multiple file systems within a shared storage pool (whatever form the storage pool may take), but that may be an invented terminology. Guy Harris (talk) 19:38, 3 July 2024 (UTC)