I wanted to store some #BorgBackup archives on an #exFAT disk so that any operating system (not just #Linux) could easily read it, but Borg needs a journaling #filesystem.

In theory, there isn't any reason why journaling can't be implemented on FAT but everybody probably doesn't consider it worth the effort.

#NTFS would work too, except some of the #Linux machines I run Borg on are running Debian Stable, whose old kernel lacks the ntfs3 driver.

Things I like about FreeBSD:

"You can tune a file system, but you cannot tune a fish."

is still listed as a bug in the tunefs man page on FreeBSD 14.3
I first saw it more that 30 years ago on SunOS that was BSD based at the time.

Found a handy CLI tool for Git >_

**git-statuses** — Display the status of multiple Git repositories in a clear, tabular format.

Scans directories recursively for Git repositories

Written in Rust!

GitHub: https://github.com/bircni/git-statuses

My daughter has a friend whose sibling is no longer alive, as of recently. The family wants to access their MacBook Pro which is password protected. It's a fairly recent model, apparently, and it's unclear whether the disk is encrypted -- prob safe to assume it is (?).

Is there something Apple can/will do to help the family gain access, given proof of the situation?

Don't forget that your filesystem is a database you can use as such. I've been writing a diary of sorts, where each entry is just a text file, with the current date as its filename.

File encryption with a browser.

I've been exploring the #WebCryptoAPI and I'm impressed!

When combined with the #FileSystemAPI, it offers a seemingly secure way to #encrypt and #store files directly on your device. Think #localstorage, but with #encryption!

I know #webapps can have #security vulnerabilities since the code is served over the web, so I've #OpenSourced my demo! You can check it out, and it should even work if #selfhosted on #GitHubPages.

Live Demo: https://dim.positive-intentions.com/?path=/story/usefs--encrypted-demo

Demo Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js

Hook Code: https://github.com/positive-intentions/dim/blob/staging/src/hooks/useFS.js

IMPORTANT NOTES (PLEASE READ!):
* This is NOT a product. It's for #testing and #demonstration purposes only.
* It has NOT been reviewed or audited. Do NOT use for sensitive data.
* The "password encryption" currently uses a hardcoded password. This is for demonstration, not security.
* This is NOT meant to replace robust solutions like #VeraCrypt. It's just a #proofofconcept to show what's possible with #browser #APIs.

Next at #bsdcan, in the plenary room - "A distributed filesystem for OpenBSD" by Rob Keizer https://indico.bsdcan.org/event/5/contributions/115/ #conference #bsd #filesystem #openbsd #freesoftware #libresoftware

Folks who know "rsync -F" because they already use it -- am I right in thinking that it adds these behaviours to a sync:

- recursively look for .rsync-filter files in every directory in the copy source, including the top-level

- apply the filters they each contain to the directory and subdirectories rooted at the same level that each file was found

- exclude those .rsync-filter files from being copied to the destination

Is that right? #rsync #sync #data #sysadmin #filesystem #filesystems

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!

#Linux Might Drop The #Apple #HFS / HFS+ #FileSystem Kernel Driver Support
#Apple no longer supports the Hierarchical File System on the latest versions of #macOS itself and in prior releases was read-only support since macOS 10.6 for HFS itself. The newer HFS+ file-system does continue to be supported by Apple. Linux support for HFS has been poor and ill-maintained and it looks like the kernel drivers could be on their way out.
https://www.phoronix.com/news/Linux-2025-Sad-State-HFS

Highlights from the main #bcachefs merge for #Linux 6.16: https://git.kernel.org/torvalds/c/522544fc71c27b4b432386c7919f71ecc79a3bfb

- Incompatible features may now be enabled at runtime, via "opts/version_upgrade" in sysfs.

- Various changes to support deployable disk images

- Major error message improvements for btree node reads, data reads, and elsewhere.

- New option, 'rebalance_on_ac_only'.

- Repair/self healing:

- We can now kick off recovery passes and run them in the background if we detect errors.

- Performance:

- Faster snapshot deletion

- Faster device removal

- We're now coalescing redundant accounting updates prior to transaction commit, taking some pressure off the journal.

- Stack usage improvements: All allocator state has been moved off the stack

Kernel Linux 6.15: driver Rust, exFAT veloce e supporto ampliato

https://gomoot.com/kernel-linux-6-15-driver-rust-exfat-veloce-e-supporto-ampliato/

#arm #blog #driver #filesystem #kernel #linux6.15 #news #nova #opensource #picks #rust #tech #tecnologia

Linux 6.16 will see more btrfs improvements

The btrfs filesystem in Linux 6.16 has undergone many improvements that make its performance faster than before. It has already been improved across Linux releases, but the upcoming version of Linux sees even more improvements to this filesystem. Any system that uses this filesystem can now benefit from those improvements.

The buffer conversion work underwent some throughput and runtime improvements for metadata heavy operations, backed by several commits in a pull request made to the 6.16 branch, such as “extent buffer conversion to xarray gains throughput and runtime improvements on metadata heavy operations doing writeback (sample test shows +50% throughput, -33% runtime).”

The tree cleanups have been improved to avoid repeated or unnecessary searches. This improves the I/O performance, should any operation rely on tree cleanups. As for committing transactions, the extent unpinning action has become more efficient than before, yielding a 3-5% performance improvement in runtime.

You can find more about this pull request by clicking on the below button:

Cover image credit.

With keen interest I studied the following blogpost by @stefano

You have to read the blog post carefully, if necessary, read it twice, because there are things said between the words and the lines that should resonate with you

One major lesson is extremely important know when to cut and leave; never ever deviate from your course afterwards

When politics, corruption and deviousness are involved, you have to make absolutely certain that both your integrity and your health remain at your primary interest

A lot has been learned by me from this article

Thank you for sharing it with us Stefano

https://it-notes.dragas.net/2025/05/21/the_day_glusterfs_tried_to_kill_my_career/