Today I learned the following. Journaling and journaling are two separate distinctly separate manners of keeping file systems in Sync.

When microsoft talks about journaling in NTFS you should never, ever think about the robust journaling system that Ext4 has

In comparison EXT4 journaling is a god while en NTFS journaling is not even an ant

I have EXT4 file systems connected to an extremely unstable machine. This thing crashes to green screens more than 64 times a day.

{It's a Gigabyte Mini PC in case you're interested never buy those. The machine came with overheating errors from the beginning. The factory installed a fan for the APU which is not even suitable for a GPU that was made a decade ago}

I've not even lost one bit of data on those EXT4 file systems.

Those NTFS file systems with journaling? I lost all of them. All NTFS file systems were lost

I didn't lose data because I have backups the file systems just keeled over simply because the machine kept rebooting

Thank you for being so robust EXT4

Your EXT4 filesystem will be speedier on Linux 6.16!

#EXT4 #Linux #Kernel #LinuxKernel #Computers #Laptops #TechNews #TechUpdates

https://officialaptivi.wordpress.com/2025/05/28/linux-6-16-yields-improved-ext4-performance/

Linux 6.16 yields improved EXT4 performance!

As part of the changes that are done in Linux 6.16, there are some of the very interesting changes that are done to the EXT4 filesystem. Those changes yield improved performance, causing you to have a faster EXT4 filesystem compared to the recently released Linux 6.15.

Those changes have been made to improve the filesystem performance, which will be pushed to the v6.16 development branch from this PR, including:

• Fast commit performance improvements
• Multi-fsblock atomic write support for bigalloc file systems
• Large folio support for regular files

The large folio support for regular files was, in itself, a factor of the improvements, along with all other changes, which yielded over 37% performance increase according to the kernel test robot that made this report you can see here. According to the test robot, it has reported that it had noticed a 37.7% improvement on fsmark.files_per_sec.

The large folio support for regular files has been added with this patch, which checks for the following conditions in the ext4_should_enable_large_folio() function before enabling such support:

• If i_mode on an inode is a regular file using the S_ISREG() macro
• If either the data flags on the superblock or the inode flags has the journal data flags
• If the superblock has no verity and has no encryption support

Also, Linux 6.16 fixes some corruption bugs on an EXT4 file system caused by race conditions in the extent status tree. Those race conditions were potentially manifested from the heavy simultaneous allocation and deallocation to a single file.

Expect the first release candidate of Linux 6.16 in the next two weeks!

#EXT4 For #Linux 6.16 Brings A Change Yielding "Really Stupendous Performance"

https://www.phoronix.com/news/Linux-6.16-EXT4-Performance

BtrFS completely sucks & i shall never again make the error of using it instead of ext4.

Hoy descubrí algo que me dejo muy perplejo... en #windows 11 conseguí sin mayores problemas formatear un #pendrive #USB de 16Tb con formato #NTFS, mientras que después de muchos intentos no logré hacer lo mismo ni en #linux #ubuntu, ni en #arch, ni en #macOSX

En todos me aparecían errores e interrumpían a menos de medio minuto el proceso de formateo y creación de particiones #ext4

¿Alguien sabe algo al respecto?

Edit: I'm going with LUKS + BTRFS. Thanks for the responses!

Which file system should I use for an encrypted root partition on Linux for a single disk (no RAID)?

I typically use LUKS + ext4.

I've also used encrypted BTRFS and ZFS but never worked with them to any extent beyond getting them setup. I see distros such as Fedora are now defaulting to using BTRFS.

I'm seeking some advice: Should I stick with ext4? Or use BTRFS? Or ZFS?

What is the best file system to use today for an additional data disk* on a #Linux desktop?
#ext4? #btrfs?

* will mostly be a data dump - synched Nextcloud storage, photography temp-files, documenta, music etc., maybe some games

Is there any know-how about creating filesystems on top of RAID1? Both XFS and ext4 top out at 35 MB/s for me even though the block device below it is capable of 135 MB/s (yes, 4x difference!) This even with an absurdly large I/O request sizes like 512KB.

The disks are old-ish SATA drives with 512-byte sectors. XFS seem to use 512b sectors while ext4 picked 4k. They're connected via USB DAS, with dm-integrity on top of each disk, which are then combined into mdadm raid1, and encrypted with LUKS.

I confirmed with fio that the slowdown happens on the filesystem level, not LUKS or anywhere below it.

The only advice I found online is about alignment, but with 512KB requests it shouldn't be an issue because that's way larger than any of the block/sector sizes involved. I must be missing something, but what is it?

Sag mal, FEDI, was ist denn der beste Weg, um eine #Ext4 Festplatte unter #Windows zu nutzen? Möglichst, ohne für Drittanbieter-Software zu bezahlen. #FollowerPower #FragFedi

As someone who lost data before (multiple times) I went for a overkill solution.

Currently in the works:
- #ZFS Mirror 2 x 4TB SSD
- Directly attached 2TB SSD via a USB adapter (Running backup leveraging #rsync every day)
- Offsite 4TB spinning disk that get's plugged in every week (Also using #rsync here)

#FreeBSD and #ZFS keeps my data safe and a disaster strategy is also in place.

Btw, three different filesystems used (#ZFS, #EXT4, #UFS)

Better safe than sorry I'd say!

#Debian question: my systems are all using the... not-non-user-hostile... defaults of encrypted LVM partitions, so I have ~250MB of /boot with #ext4. My / is #XFS so I can't move /boot. I have closed #nvidia drivers via #dkms, maybe that matters.

I used to be able to juggle two kernels, one installed, one to be installed. That fails now, I am stuck.

Are there any good and modern docs on reducing #linux #kernel footprint in /boot?

I can find old stuff, empty stuff, and whataboutism, no docs...

@neil @ai6yr @restic I'd say an external #SATA-SSD in an enclosure with #brtfs or "journalless #ext4" works fine.

• Maybe consider a cheap multi-port case with #HDDs and using #dmraid for #RAID-based failsafe?

I'm considering to switch my #Gluon / #OpenWrt / #Linux development stuff onto a deduplicating filesystem. As I think that would fit nicely with my #Git worktree setup. So far I used just #ext4. I benchmarked #XFS, #btrfs and #OpenZFS. For all of them an OpenWrt target build (excluding the toolchain) seems to take about 23min. on my laptop - even when using #ZFS with both dedup. + compression.
So the filesystem seemingly is not a bottleneck. Anyone having similar experiences?

Been reading up a bit trying to decide which file system I want to use when I redo my home server soon. Think I'm leaning towards giving btrfs a go. Curious what the splits are on fedi. I've only ever used ext4 on Linux. I'm guessing for desktop/home server use, xfs isn't very popular. Just including it here since it's in this article.

#Linux #FileSystems #EXT4 #BTRFS #ZFS #XFS

https://blog.usro.net/2024/10/linux-file-systems-comparison/

Ich hab ne zweite #SSD in meinem PC, die ich gerne nutzen würde, um meine Daten (Dokumente etc.) zu speichern. Welches Dateiformat eignet sich dafür auf #Linux am besten? #Btrfs? #Ext4? Oder ganz was anderes?

Ich lege übrigens keinen Wert auf Kompatibilität mit Windows, weil ich die Daten im Falle einer Rückkehr zu Windows auch von meinem NAS-Backup holen könnte.