"[…] we observed that the df command shows higher space utilization compared to du when many small files are copied. Over time, the outputs of both df and du converge. This happens because #XFS initially reserves additional space for these files.

The feature that causes this behavior is Dynamic Speculative End of File (EOF) Preallocation. This feature allows files to dynamically reserve more space to prevent fragmentation in case the file is grown later on. This blog post explores what this feature is, how it works, and how it can be beneficial for certain use cases. […]"

https://blogs.oracle.com/linux/post/du-vs-df-in-xfs

Highlights from the main #XFS merge for #Linux 6.16 (https://git.kernel.org/torvalds/c/f83fcb87f824b0bfbf1200590cc80f05e66488a7):

- Atomic writes for XFS

- Remove experimental warnings for pNFS, scrub and parent pointers

I need a Zen5 laptop, apparently. Also, #XFS maxing out the benchmarks was not in my 2025 bingo card and it's nice to hear that Kent of #Bcachefs fame has become more balanced and optimistic. Go, man, go!

https://youtu.be/s6nR75HM7Y0

A bunch more manual xfs repairs over the past week. In contrast, there's been exactly zero ext4 or btrfs manual fsck's needed for the same environments. All with some flavor of EL8 or EL9 on two different storage platforms (Ceph, Longhorn). Still no idea what's causing it, but xfs continues to be the outlier.

#XFS remains the fastest filesystem in #Linux 6.15, at least on NVMe drives:
https://www.phoronix.com/review/linux-615-filesystems

I've been using XFS on all my laptops for over 15 years with no data loss. Meanwhile, while #Btrfs has matured to the point I would entrust it with my /home, it still has terrible performance in most benchmarks.

And note that slower I/O usually means higher CPU usage and thus shorter battery life for your laptop.

TIL that xfs has supported copy-on-write reflink copies for years, where as zfs only got it last year (and it is not considered stable!)

https://blogs.oracle.com/linux/post/xfs-data-block-sharing-reflink

Tipos de Sistemas de Archivos en Linux #hardware #btrfs #comparación_sistemas_de_archivos. #ext4 #particionamiento_linux #sistemas_de_archivos_linux #tipos_de_particiones_linux #xfs
https://soploslinux.com/tipos-de-sistemas-de-archivos-en-linux/

Here’s a thought I’ve just had on file systems for #Linux: if I have no need for advanced features like subvolumes or snapshots or built-in support for multiple devices, is there really a point to thinking about which file systems is good for an Average Jane such as myself? I don’t exactly consider myself lacking in bandwidth, so surely the difference only starts to matter at scale? #btrfs #ext4 #xfs

hey hey #Linux #FileSystem #ZFS #RAID #XFS entities! I'm looking for extremely opinionated discourses on alternatives to ZFS on Linux for slapping together a #JBOD ("Just a Bunch Of Disks", "Just a Buncha Old Disks", "Jesus! Buncha Old Disks!", etc) array.

I like ZFS but the fact that it's not in tree in-kernel is an issue for me. What I need most is reliability and stability (specifically regarding parity) here; integrity is the need. Read/write don't have to be blazingly fast (not that I'm mad about it).

I also have one #proxmox ZFS array where a raw disk image is stored for a #Qemu #VirtualMachine; in the VM, it's formatted to XFS. That "seems" fine in limited testing thus far (and quite fast, so it does seem like the defaults got the striping correct) but I kind of hate how I have multiple levels of abstraction here.

I don't think there's been any change on the #BTRFS front re: raid-like array stability (I like and use BTRFS for single disk filesystems but) although I would love for that to be different.

I'm open to #LVM, etc, or whatever might help me stay in tree and up to date. Thank you! Boosts appreciated and welcome.

#techPosting

And here we go now: #XSF #Summit27 remote participation, Day 2!

Day 1 was a super edifying experience and I couldn't be more grateful for the effort the #XFS does to open the doors for everyone to join and take part of the event!

Transparent, open, considerate, integrative ...

This is the #community I choose to be a part of, beyond all technical merits and achievements.

Highlights from the main #XFS merge for #Linux 6.14:

https://git.kernel.org/torvalds/c/b477ff98d903618a1ab8247861f2ea6e70c0f0f8

reflink (https://git.kernel.org/torvalds/c/156d1c389c543c4620dd86ad8636ecb224be0376) and reverse-mapping (https://git.kernel.org/torvalds/c/a938bbe4739f8ffb0797f963324d207f789329c8) support for XFS's real-time devices

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?

#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...

hch is working on support for zoned devices in #xfs:

https://lore.kernel.org/all/20241211085420.1380396-1-hch@lst.de/
https://lore.kernel.org/all/20241211085636.1380516-1-hch@lst.de/