Symbolic links vs Hard links in Linux. What's the difference? Why would you use one over the other? What limitations do each have? If you'd like to know these answers, check out this episode of Red Hat's Into the Terminal.
https://www.youtube.com/live/qzMxDLT4cIU?si=teSlMjdRfg8bUJ0s
Symlinks and Hardlinks. If you're like me you know they both exist, but maybe aren't all that clear on when to use which? On today's Into the Terminal, we're exploring both, and talking through why you might use one vs. the other. Come join us! Noon eastern!
One Open-source Project Daily
Manage filesystem snapshots and allow undo of system modifications
https://github.com/openSUSE/snapper
#1ospd #opensource #fs #filesystem #snapshots #linux #suse #opensuse
... #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.』
#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
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!
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
"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
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
Just added some new diagrams to describe the internals of the https://thi.ng/block-fs block storage & filesystem (incl. some examples) and also added/updated CLI tooling docs...
I have found that all of the "solutions" I've looked at are just locking you into some more specific ecosystem, so went back to the revolutionary idea of using the #filesystem I have my photos and videos in a folder structure on my laptop by year, trip.
I don't auto backup from my #iPhone or #Sonya6700 anymore, that really just synced a load of cruft I had to delete, or pay to store. I move photos I want to my laptop, where I adjust and edit them in #darktable / #rawtherapee / #digikam
2/4
#ReleaseWednesday Just pushed a new version of https://thi.ng/block-fs, now with additional multi-command CLI tooling to convert & bundle a local file system tree into a single block-based binary blob (e.g. for bundling assets, or distributing a virtual filesystem as part of a web app, or for snapshot testing, or as bridge for WASM interop etc.)
Also new, the main API now includes a `.readAsObjectURL()` method to wrap files as URLs to binary blobs with associated MIME types, thereby making it trivial to use the virtual filesystem for sourcing stored images and other assets for direct use in the browser...
(Ps. For more context see other recent announcement: https://mastodon.thi.ng/@toxi/114264980961483146)
The #GPartedLive USB just saved my a** ! 
GitHub: 
G◍M◍◍T 
