dch :flantifa: :flan_hacker:
and 2 others
boosted
2 media
Stefano Marinelli
boosted
New blog post: Dark Blue Weekly published
https://darkblueraven.com/sites/blog/dark-blue-weekly-published.php
By the way, 2 episodes are already published.
#darkblueweekly #darkblueraven #opensource #freesoftware #linux #bsd
Stefano Marinelli
boosted
Happy Friday/Friyay to all the #BSD folks out there! 😎 
Happy Friday/Friyay to all the #BSD folks out there! 😎
New blog post: Dark Blue Weekly published
https://darkblueraven.com/sites/blog/dark-blue-weekly-published.php
By the way, 2 episodes are already published.
#darkblueweekly #darkblueraven #opensource #freesoftware #linux #bsd
Stefano Marinelli
boosted
Quote from Hammer2 page
Because HAMMER2 is a block copy-on-write filesystem, the "atime" field is not supported and will typically just reflect local system in-memory caches or mtime.
The radix tree is dynamic in that each entry can dynamically control how many bits it chops off. This allows small files to be contained in just one or two levels regardless of the block seek positions. The depth of the radix tree is increased as needed via a splitting mechanism, and will also be recombined if it grows smaller. All block references are 64-bit aligned-byte-indexed references and thus portable regardless of physical sector size changes between underlying block devices.
Inodes are 1KB of which 512 bytes are used for the top-level radix tree OR 512 bytes of data. Any file less than or equal to 512 bytes stores its data directly in the inode. Files up to 256KB can be accommodated with direct inode block references.
Directory entries are hashed (semi-sorted hash algorithm), and directly embedded in the radix table's blockref structure for maximum performance. Files with very long filenames will contain a dataref, otherwise filenames are embedded in the directory entry itself. Because directory entries are hashed, seeking and lookups are able to use a radix search and no linear scan of the directory is needed.
The inode and directory entry structure is extremely well suited for any file size or directory size, from tiny to huge.
Because of the block-copy-on-write nature of the filesystem, the filesystem is able to create a snapshot trivially simply by copying the volume header's root block table (4 blockref entries). The directory topology actually starts with a SUPERROOT, and volume ROOTs are directory entries under the SUPERROOT. Though the entries are actually special-cased a bit and actually part of the root inode for each filesystem root. And since physical freeing of space is handled via a bulk meta-data scan, destroying a snapshot or volume can be done simply by wiping the inode and ignoring everything under it... the next bulkfree scan will reclaim any reclaimable space. Similarly with file deletions... the top-level data blockrefs can simply be removed. The inode can simply be removed from the radix tree.
Performance is very good. HAMMER2 uses a variable-sized block in powers of two, starting at 1KB, up to 64KB, for the last block of the file (straddling EOF). All earlier blocks in the file, if any, use 64KB blocks. The freemap is organized by domain to cluster various meta-data types together. Indirect blocks can be one of two sizes: 16KB or 64KB, allowing medium-sized files and directories to be optimally allocated. In addition, file data compression of a logical block can result in a smaller physical block. The physical layer always does 64KB I/O and can cluster the I/O on top of that.
https://www.dragonflybsd.org/hammer/
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
Stefano Marinelli
boosted
The amazing DragonFlyBSD has the fantastic
Hammer2 filesystem:
* Block copy-on-write filesystem
* Instant recovery on mount
* Instant snapshots
* Mounted snapshots are writable
* Automatic snapshotting can be enabled at the system level via periodic scripts
* Default Periodic also does daily bulk pass on the meta-data to free space
* Automatic compression (controllable on directory recursion and per-file basis)
* Automatic de-duplication
* Future master/slave mechanism
* Utilizes a dynamic radix tree
* 64-bit hardlink counter
* 2^63 logical file size limit
* Recursive check codes to detect corruption
* Any number of pseudo-filesystem volumes for each physical hammer2 disk image (also used by snapshots).
https://www.dragonflybsd.org/hammer/
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
Additional Reference Material
HAMMER2 Design v6 (08-Dec-2018)
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
Quote from Hammer2 page
Because HAMMER2 is a block copy-on-write filesystem, the "atime" field is not supported and will typically just reflect local system in-memory caches or mtime.
The radix tree is dynamic in that each entry can dynamically control how many bits it chops off. This allows small files to be contained in just one or two levels regardless of the block seek positions. The depth of the radix tree is increased as needed via a splitting mechanism, and will also be recombined if it grows smaller. All block references are 64-bit aligned-byte-indexed references and thus portable regardless of physical sector size changes between underlying block devices.
Inodes are 1KB of which 512 bytes are used for the top-level radix tree OR 512 bytes of data. Any file less than or equal to 512 bytes stores its data directly in the inode. Files up to 256KB can be accommodated with direct inode block references.
Directory entries are hashed (semi-sorted hash algorithm), and directly embedded in the radix table's blockref structure for maximum performance. Files with very long filenames will contain a dataref, otherwise filenames are embedded in the directory entry itself. Because directory entries are hashed, seeking and lookups are able to use a radix search and no linear scan of the directory is needed.
The inode and directory entry structure is extremely well suited for any file size or directory size, from tiny to huge.
Because of the block-copy-on-write nature of the filesystem, the filesystem is able to create a snapshot trivially simply by copying the volume header's root block table (4 blockref entries). The directory topology actually starts with a SUPERROOT, and volume ROOTs are directory entries under the SUPERROOT. Though the entries are actually special-cased a bit and actually part of the root inode for each filesystem root. And since physical freeing of space is handled via a bulk meta-data scan, destroying a snapshot or volume can be done simply by wiping the inode and ignoring everything under it... the next bulkfree scan will reclaim any reclaimable space. Similarly with file deletions... the top-level data blockrefs can simply be removed. The inode can simply be removed from the radix tree.
Performance is very good. HAMMER2 uses a variable-sized block in powers of two, starting at 1KB, up to 64KB, for the last block of the file (straddling EOF). All earlier blocks in the file, if any, use 64KB blocks. The freemap is organized by domain to cluster various meta-data types together. Indirect blocks can be one of two sizes: 16KB or 64KB, allowing medium-sized files and directories to be optimally allocated. In addition, file data compression of a logical block can result in a smaller physical block. The physical layer always does 64KB I/O and can cluster the I/O on top of that.
https://www.dragonflybsd.org/hammer/
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
The amazing DragonFlyBSD has the fantastic
Hammer2 filesystem:
* Block copy-on-write filesystem
* Instant recovery on mount
* Instant snapshots
* Mounted snapshots are writable
* Automatic snapshotting can be enabled at the system level via periodic scripts
* Default Periodic also does daily bulk pass on the meta-data to free space
* Automatic compression (controllable on directory recursion and per-file basis)
* Automatic de-duplication
* Future master/slave mechanism
* Utilizes a dynamic radix tree
* 64-bit hardlink counter
* 2^63 logical file size limit
* Recursive check codes to detect corruption
* Any number of pseudo-filesystem volumes for each physical hammer2 disk image (also used by snapshots).
https://www.dragonflybsd.org/hammer/
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
Additional Reference Material
HAMMER2 Design v6 (08-Dec-2018)
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
The amazing DragonFlyBSD has the fantastic
Hammer2 filesystem:
* Block copy-on-write filesystem
* Instant recovery on mount
* Instant snapshots
* Mounted snapshots are writable
* Automatic snapshotting can be enabled at the system level via periodic scripts
* Default Periodic also does daily bulk pass on the meta-data to free space
* Automatic compression (controllable on directory recursion and per-file basis)
* Automatic de-duplication
* Future master/slave mechanism
* Utilizes a dynamic radix tree
* 64-bit hardlink counter
* 2^63 logical file size limit
* Recursive check codes to detect corruption
* Any number of pseudo-filesystem volumes for each physical hammer2 disk image (also used by snapshots).
https://www.dragonflybsd.org/hammer/
#filesystem #programming #BSD #dragonflyBSD #freeBSD #OpenSource #technology #no #FSK
Beardy Star Stuff 🏴🌹🇵🇸
and 1 other
boosted
Masto Re-Introduction
I'm a Linux Administrator and DevOps Engineer, foss & self-host enthusiast, linux gamer, BSD weirdo, and producer of electronic music. Also have an interest learning more about philosophy, left-wing anarchism/syndicalism/mutualism and decentralized systems (outside of crypto context).
Looking to connect with anyone who regularly posts about or engages in those types of interests.
#introduction #linux #linuxgaming #bsd #electronicmusic #anarchism #decentralization #foss
2 media
Masto Re-Introduction
I'm a Linux Administrator and DevOps Engineer, foss & self-host enthusiast, linux gamer, BSD weirdo, and producer of electronic music. Also have an interest learning more about philosophy, left-wing anarchism/syndicalism/mutualism and decentralized systems (outside of crypto context).
Looking to connect with anyone who regularly posts about or engages in those types of interests.
#introduction #linux #linuxgaming #bsd #electronicmusic #anarchism #decentralization #foss
Every now and then when I come back to use my daily driver running #Debian #Linux, I got surprised why #apt still does not provided short-formed commands like #pkg in #FreeBSD and #pkgin in #NetBSD do such as:
# FreeBSD#Unix #BSD #FOSS
pkg ins vim # same as pkg install vim
pkg sea vim # same as pkg search vim
# NetBSD
pkgin in vim # same as pkgin install vim
pkgin se vim # same as pkgin search vim
# while in Debian
apt search vim # no apt se/sea
apt install vim # no apt in/ins
Installing #Slackware #Linux using #vmm on #OpenBSD. Got some help from this video on getting the console to display correctly in the terminal. 
#RunBSD #BSD #virtualization
https://www.youtube.com/watch?v=sZnM-T6Os-s
Planning on using this as a practice Linux system for my Linux+ studies. 
@rl_dane It does actually remind me of PowerShell in a few ways, but in a good way. I'll keep learning it and find out more of what I think.
Random but with `*` filename matching, you can use modifiers in brackets. Yesterday I did `mkdir old` and then wanted to do `mv * old`, but found out I could instead do `mv *[but:old] old`.
Also TUI file selector via Ctrl+L.
When I find something I like, I end up feeling like a salesman and I don't like it 😆
> When I find something I like, I end up feeling like a salesman and I don't like it 😆
No shame in that, I'm still waiting for my fat commission check from Big #BSD. 😂
Social Media Channel
boosted
🌟 Introducing BSD.cafe 🌟
Excited to present the first building block of the BSD Cafe project! When I registered this domain months ago, I envisioned a themed bar where we can casually chat about *BSD systems, Linux, and Open-Source technology among friends, acquaintances, and patrons. But like any bar, discussions can cover a wide range of topics while respecting everyone.
BSD.cafe will be a hub for various tools and services, powered by *BSD.
The first brick is a new Mastodon instance, a gateway to the Fediverse. Registration is open, and the server will be moderated under clear guidelines promoting good behavior and zero tolerance for hate towards anyone. Inclusivity, respect, and constructive dialogue are the key values of this new instance.
The main server is currently hosted in Finland on a small VM, based on #FreeBSD. Services are divided into VNET jails, connected in a LAN via a local bridge. A VPN system is also present and have been able to move individual jails to different, more powerful, machines.
Multimedia data and cache are hosted on another physical server (FreeBSD, within a jail), with Cloudflare in front. The aim is to cache and geodistribute data, reducing network traffic on the main VPS.
Reverse proxy (frontend), mail server, media server, and the instance itself are reachable via #ipv6.
The instance started empty. No unnecessary content was pre-loaded; I want it to grow organically based on users' interests and following. There won't be any preemptive blocks at this stage. Users are encouraged to promptly report anything they find worth flagging.
Join us at https://mastodon.bsd.cafe to build a constructive and inclusive community—a safe and relaxing space for everyone.
Our wiki, located at https://wiki.bsd.cafe, features essential links and articles related to the BSD world. It provides an overview of the tools, services, rules, uptime, and more information about the BSD Cafe Services.
A Matrix server, a Miniflux RSS Reader, the Wiki itself, and the BlendIT Lemmy instance are all part of the BSD Cafe services, with more to come.
#BSD #OpenSource #Fediverse #Community #Tech #Networking #Mastodon #Inclusivity #FreeBSD #NetBSD #OpenBSD #DragonflyBSD #Linux #OSS #SysAdmin #Miniflux #RSS #Matrix