toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

206
active users

#ext4

1 post1 participant0 posts today
Replied in thread

@Klimakipppunkt@troet.cafe @CrazyIT@freiburg.social @alexantemachina@mastodon.social

Um Backups auf ein
#Samba oder #NFS #Share auszulagern, braucht es gar kein Addon. Das geht otb mit Bordmitteln.

Ich würde gern, nach der Erfahrung, dass die komplette Konfiguration sowie
#Datenbank weg waren (komplett leerer Ordner /homeassistant) gerne diese auf ein vernünftiges #Dateisystem wie #ext4 oder #ZFS auslagern.

#exFat ist, basierend auf #Fat32 einfach #FailByDesign und nicht zeitgemäß.

Ich wiederhole mich hier:
Wie man auf die Schnapsidee kommen kann, ein
#Linux basiertes System mit einem exFat Dateisystem auszuliefern, ist einfach komplett unverständlich und 🤡🤡🤡

#Homeassistant #HA

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

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!

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.

so been using arch for the past few days...
couple things I like and don't like...

  1. boot times are nuts, like way faster than any other os I've run on this particular laptop (t480s)
  2. latest gnome, latest kernel and maybe updates are too often? I know there is a testing phase but I've heard horror stories of arch breaking.....might just be a user thing
  3. I already run majority of my apps as flatpaks, so system is light and quick
  4. battery life seems slightly improved, likely due to less resources and background processes

I don't do much gaming, theming, tweaks, no custom kernels, no extra fonts, none of that for me, so I am interested on the longevity and stability going forward. So far I am impressed. Using ext4 so backups should be pretty basic.

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

So, I'm currently installing WSL in an attempt to get Windows 11 to view various ext4 filesystems, as I do a lot of stuff with Rasperry Pi machines. This feels...kinda wrong. I hope it works though. I know just enough to be dangerous, but not enough to be a true expert.

#WSL#Linux#Windows

I wonder if anyone can help me with a #Linux #USB issue. I’ve got a new flash drive on which I want to put a Linux directory structure on {with #EXT4, encrypted if possible). However, using the #GNOME #disks utility to #Format it apparently works but when I go into the disk’s root directory, I can’t create any files – I get an input/output error. If I reformat the disk as a #FAT (windows(disk then it works again and so I’m thinking there must be some problem with the utility I’m using.

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?

#AskFedi#ext4#btrfs
Continued thread

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?

#mdadm#raid#ext4