mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#ext4

2 Beiträge2 Beteiligte0 Beiträge heute

Ich wollte heute eine alte 500GB Festplatte als Musikspeicher für möglichst alle #Betriebssysteme formatieren. Stellt sich mal wieder raus: #FAT32 und #NTFS sind immer noch ungeeignet.
Jede Menge "Sonderzeichen", wie z.B. "?" im Dateinamen werfen Fehler und die Dateien werden nicht gespeichert.
Tjo nun, dann nehm ich eben wieder #Ext4. #Linux kommt damit klar, #MacOS glaube ich auch. Wenn ich die Platte mal an einem #Windows anschließe und sie nicht gelesen werden kann - Pech gehabt.

📊 New #Haiku development report - May 2025!

A month focused on targeted improvements and stability:
- HaikuDepot now more user-friendly for newcomers
- Important Tracker and Terminal fixes
- Major BUrl class rework with cleaner API
- More stable #NFSv4 and #EXT4 drivers
- #Wacom #Intuos4 support added

Interesting milestone: 258 HaikuPorts commits vs 52 core system - shows growing maturity! 🚀

Full report: desktoponfire.com/haikuos/soft

#OpenSource#BeOS#HaikuOS

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

#Journal#filesystem#EXT4

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#Filesystem#Linux

I've managed to get #OpenMediaVault working on my #RaspberryPi (running #Raspbian Lite) and the performance seems pretty impressive! Despite relying on USB storage for the SSDs.

This is my first time running a
#NAS on the Pi, on #OMV, not using #ZFS or #RAID but rather an #Unraid like solution, 'cept, #FOSS called #SnapRAID in combination with #mergerfs (the drives themselves are simply #EXT4).

So far, honestly, so good. I got 2x 1TB SSDs for data, and another 1TB SSD for parity. Don't have a backup for the data themselves atm, but I do have a scheduled backup solution (
#RaspiBackup) setup for the OS itself (SD card). It's also got #Timeshift for creating daily snapshots.

I'm not
out of the woods yet though, cos after this comes the (somewhat) scary part, deploying #Immich on the Pi lol. I really could just deploy it in my #Proxmox #homelab, and I wouldn't have to worry about system resources or hardware transcoding, etc. but I really wanna experiment this 'everything hosted/contained in 1 Pi' concept.

Antwortete im Thread
Here still using #ext4 on my laptop but for sensitive info I use password-store I try to keep simple as possible but luks is ok, very mature and widely use.

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.

Fortgeführter Thread

Anyway, I was having big issues with trying to create an #EXT4 file system and the same problem was occurring on multiple devices, indicating that it wasn’t the device that was at fault and I concluded that it must be something to do with #mkfs.ext4.

Antwortete im Thread

Thanks @vkc

<Start/tip nobody asked for>
For those who want something close to Debian testing, #siduction (by default #KDE #Plasma6) might be worth a try. It is unstable (Codename: Sid), thus before testing. This means it is tested but, it is certainly not as stable as testing.
But here is the twist. Use it with #btrfs or #timeshift and #ext4 to have efficient tools for a rollback once it breaks (and it will break sporadically) and you should be good.
<End/tip nobody asked for>