WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2025 Poal.co

871

Archive: https://archive.today/u0X7I

From the post:

>Sent out and already merged today for the Linux 7.0 kernel are the EXT4 file-system updates. One of the changes for EXT4 in this next kernel version that stands out for me is improving write performance when dealing with concurrent direct I/O writes to multiple files. This performance improvement comes by deferring the splitting of unwritten extents to I/O completion. EXT4 in Linux 7.0 also now avoids unnecessary cache invalidation in the extent status cache, avoids unnecessary forced ordered writes when appending to a file with delayed allocation, and a variety of bug fixes.

Archive: https://archive.today/u0X7I From the post: >>Sent out and already merged today for the Linux 7.0 kernel are the EXT4 file-system updates. One of the changes for EXT4 in this next kernel version that stands out for me is improving write performance when dealing with concurrent direct I/O writes to multiple files. This performance improvement comes by deferring the splitting of unwritten extents to I/O completion. EXT4 in Linux 7.0 also now avoids unnecessary cache invalidation in the extent status cache, avoids unnecessary forced ordered writes when appending to a file with delayed allocation, and a variety of bug fixes.
[–] 0 pt

Huh...I might need to look more into BTRFS then. Doesn't it add more wear to SSDs?

[–] 1 pt (edited )

Btrfs generally causes more wear on SSDs than ext4 due to its Copy-on-Write (CoW) nature and metadata overhead, which can result in higher write amplification. However, Btrfs supports compression (e.g., zstd) which can significantly reduce total writes, potentially offsetting this wear. Ext4 is generally more efficient and reliable for basic, heavy-write desktop use.

I haven't used SSD based NAS, so I can't tell if the corruptions were caused by failing HDD (though SMART reports never showed any issue)