XFS / EXT4 / Btrfs / F2FS / NILFS2 Performance On Linux 5.8

[adriansev]

I would be really curious on the numbers on hdds ...

[S.Pam]

Great article

What IO-Scheduler was used? It is likely it would affect the Application Start-up times a lot. Michael could you re-run the test with different IO schedulers like mq-eadline, bfq and none?

[adriansev]

What IO-Scheduler was used?

I think this is shown in the first box, the one with system details, and i take it from there that "None" was de default IO scheduler for all (AFAIK ubuntu defaults to None for all nvme drives)

[S.Pam]

I can't find any info in the specs. Can you show me?

[adriansev]

I can't find any info in the specs. Can you show me?

see https://openbenchmarking.org/embed.p...ha=a11596e&p=2
for each file system there are show the default options, and i take that NONE as the IO scheduler

[S.Pam]

see https://openbenchmarking.org/embed.p...ha=a11596e&p=2
for each file system there are show the default options, and i take that NONE as the IO scheduler

Thanks. Yes, that probably makes sense.

[rudiservo]

can you make a benchmark with BTRFS space_cache=v2 with clear_cache and discard=async?

[guglovich]

phoronix We need a new NILFS2 benchmark

[Chaython]

BTRFS performs great for me, I use it because there’s an open source driver for windows and I transparently zstd compress the whole drive.

do any of these other formats have a windows driver? Do they support transparently compressing with zstd?

[Old Grouch]

phoronix We need a new NILFS2 benchmark

Well, yes, and no. Yes, because refreshing the data would be nice; no because NILFS2 will perform badly compared to more recently developed/update filesystems (I have carefully not said 'more modern'. There are known performance bottlenecks in NILFS2 which the small development/maintenance community do not have the resources to address, not least because it would likely require a change in the on-disk format. Which is a shame.

I do not use NILFS2 for performance. I am happy so long as the performance is adequate for my needs/use case, which is it is, especially on SSD. I use it for the effectively continuous checkpointing capability, any checkpoint of which can be turned into a snapshot and mounted read-only for data recovery if you do something silly like overwrite some key data in a file or delete an important file.

NILFS2 is not perfect, or fast. I would like it if both metadata and data were checksummed, but that is unlikely to happen, so I can only hope that btrfs or bcachefs can provide a similar continuous/continual checkpointing/snapshotting capability. In the meantime, I have used NILFS2 as my daily-driver filesystem on all filesystems except /boot for the last 8 years, with no NILFS2-caused problems so far. It suits my use case, but I would not recommend it unreservedly for all use-cases.