... #BetrFS https://www.betrfs.org/ ...
『… in-kernel file system that uses Bε trees to organize on-disk storage. Bε trees are a write-optimized dictionary, and offer the same asymptotic behavior for sequential I/O and point queries as a B-tree. The advantage of a B ε tree is that it can also ingest small, random writes 1-2 orders of magnitude faster than B-trees and other standard on-disk data structures.』
btrfs mention
#ZFS Right Now! c 2007,
by Jeff B,
(only slides) https://www.usenix.org/legacy/event/lisa07/htgr_files/bonwick_htgr.pdf
https://www.usenix.org/conference/lisa-07/zfs
-- introduction to ZFS of Sun Microsystems vintage
Black-Box Problem Diagnosis in Parallel File Systems, c 2010,
by Michael P K, Jiaqi T, Rajeev G, Priya N,
https://www.usenix.org/conference/fast-10/black-box-problem-diagnosis-parallel-file-systems
-- compares the metric histograms of the nodes
VS Code extension to edit the filesystem like a text buffer
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!
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.
"[…] 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. […]"
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.
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
Understanding the Linux /usr Merge #filesystem #linux #unix #opensource
https://ostechnix.com/understanding-linux-usr-merge/
Highlights from the main #erofs merge for #Linux 6.16 (https://git.kernel.org/torvalds/c/79b98edf918e8146047e08817e2a42937428be02):
* a `fsoffset` mount option is introduced for file-backed mounts to specify the filesystem offset in order to adapt customized container formats.
* Intel QAT hardware accelerators are supported to improve DEFLATE decompression performance.
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
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
"some performance improvements and one minor mount option update" are among the main #Btrfs changes merged for #Linux 6.16:
https://git.kernel.org/torvalds/c/5e82ed5ca4b510e0ff53af1e12e94e6aa1fe5a93
A few highlights:
Performance:
- extent buffer conversion to xarray gains throughput and runtime improvements on metadata heavy operations doing writeback (sample test shows +50% throughput, -33% runtime)
- extent io tree cleanups lead to performance improvements by avoiding unnecessary searches or repeated searches
- more efficient extent unpinning when committing transaction (estimated run time improvement 3-5%)
User visible changes:
- remove standalone mount option 'nologreplay', deprecated in 5.9, replacement is 'rescue=nologreplay'
- in scrub, update reporting, add back device stats message after detected errors (accidentally removed during recent refactoring)
Core:
- convert extent buffer radix tree to xarray
- continued preparations for large folios
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:
Learn more Could this perhaps be fixed with a new API?
Like, a new system call that checks if string A contains substring B, with whatever case-folding algorithm is in effect for folder C.
GitHub: 
