Helping @dexter with the #OpenZFS User and Developer Summit this weekend.
EDIT: Streaming through Tuesday, links on https://openzfs.org/wiki/OpenZFS_Developer_Summit
#Tag
Helping @dexter with the #OpenZFS User and Developer Summit this weekend.
EDIT: Streaming through Tuesday, links on https://openzfs.org/wiki/OpenZFS_Developer_Summit
The 2025 #OpenZFS User and Developer Summit is live!
PeerTube and YouTube links are on the wiki:
Helping @dexter with the #OpenZFS User and Developer Summit this weekend.
EDIT: Streaming through Tuesday, links on https://openzfs.org/wiki/OpenZFS_Developer_Summit
The 2025 #OpenZFS User and Developer Summit is live!
PeerTube and YouTube links are on the wiki:
The 2025 #OpenZFS User and Developer Summit begins Saturday!
SWAG and Food are in-hand and it’s not too late to register for an online participation ticket that includes a T-shirt mailed anywhere in the world!
https://openzfs.org/wiki/OpenZFS_Developer_Summit_2025
See you in Portland and online!
The 2025 #OpenZFS User and Developer Summit begins Saturday!
SWAG and Food are in-hand and it’s not too late to register for an online participation ticket that includes a T-shirt mailed anywhere in the world!
https://openzfs.org/wiki/OpenZFS_Developer_Summit_2025
See you in Portland and online!
Quick question, for #OpenZFS users and devs both: is there interest in having the OpenZFS tools translated to languages other than English?
Pros: it's always nice to use your computer in your native language
Cons: need people to do the translations, extra code complexity, slower, harder to test, etc
My actual reason for asking is that I notice we call `gettext()` for most of our output strings right now, but we do not have any message catalogs (and I didn't quickly see any in illumos either). So we're already paying some (small) maintenance cost, for no gain.
I could remove them, or I could set up the translation infrastructure. What's the better choice at this moment in time? (obviously, we can add it all back in the future if we want).
Quick question, for #OpenZFS users and devs both: is there interest in having the OpenZFS tools translated to languages other than English?
Pros: it's always nice to use your computer in your native language
Cons: need people to do the translations, extra code complexity, slower, harder to test, etc
My actual reason for asking is that I notice we call `gettext()` for most of our output strings right now, but we do not have any message catalogs (and I didn't quickly see any in illumos either). So we're already paying some (small) maintenance cost, for no gain.
I could remove them, or I could set up the translation infrastructure. What's the better choice at this moment in time? (obviously, we can add it all back in the future if we want).
The 2025 #OpenZFS User and Developer Summit is taking place October 25 through 28th in Portland, Oregon, USA.
It’s not too late to register and we have added an online ticket option that includes discussion participation and a mailed T-shirt!
The 2025 #OpenZFS User and Developer Summit is taking place October 25 through 28th in Portland, Oregon, USA.
It’s not too late to register and we have added an online ticket option that includes discussion participation and a mailed T-shirt!
Really nice article about some ZFS basics, written by Klara Systems: https://klarasystems.com/articles/advanced-zfs-dataset-management/
Really nice article about some ZFS basics, written by Klara Systems: https://klarasystems.com/articles/advanced-zfs-dataset-management/
The draft schedule of the 2025 #OpenZFS User and Developer Summit is up!
The draft schedule of the 2025 #OpenZFS User and Developer Summit is up!
I yapped pretty hard about my own thoughts and opinions on some #OpenZFS stuff today, including:
- how we could make `zfs diff` nicer by tracking all hardlink parents
- some of the stuff that OpenZFS knows internally but doesn't currently expose to userspace, but could if anyone asked
- per-vdev queue tuning via properties instead of global tunables
- initial musings on a dataset type that exposes a S3-compatible API
- the size and scope of a flash-friendly redesign
On that last, the simplest and most important question was asked: how much $$$? I've been thinking about that all morning; not just the amount, but how there are people out there with cash that actually want stuff, but they aren't just gonna hand it out without a plan. This is obvious, but I'm just a tiny baby in the programmer-for-hire world; I learn slowly 😅 Some ideas are brewing, more on that soon I hope.
Thanks @dexter for the platform (and the patience; he's been subject to similar yaps from me in private, and is always a thoughtful and gracious host)!
2.4 getting close now! #OpenZFS
The recording of the October 1st, 2025 #OpenZFS Production User Call is up:
We discussed the upcoming User and Developer Summit, libzfs, 'zfs diff' behavior, orphaned files, extended attributes, metadata handling, stream(8), flash-native OpenZFS, a hypothetical S3 front-end for the OpenZFS object store, reproducible workloads, drama generators, and more!
"Don't forget to slam those Like and Subscribe buttons."
You now can support Call For Testing on Patreon: https://patreon.com/CallForTesting
I yapped pretty hard about my own thoughts and opinions on some #OpenZFS stuff today, including:
- how we could make `zfs diff` nicer by tracking all hardlink parents
- some of the stuff that OpenZFS knows internally but doesn't currently expose to userspace, but could if anyone asked
- per-vdev queue tuning via properties instead of global tunables
- initial musings on a dataset type that exposes a S3-compatible API
- the size and scope of a flash-friendly redesign
On that last, the simplest and most important question was asked: how much $$$? I've been thinking about that all morning; not just the amount, but how there are people out there with cash that actually want stuff, but they aren't just gonna hand it out without a plan. This is obvious, but I'm just a tiny baby in the programmer-for-hire world; I learn slowly 😅 Some ideas are brewing, more on that soon I hope.
Thanks @dexter for the platform (and the patience; he's been subject to similar yaps from me in private, and is always a thoughtful and gracious host)!
The recording of the October 1st, 2025 #OpenZFS Production User Call is up:
We discussed the upcoming User and Developer Summit, libzfs, 'zfs diff' behavior, orphaned files, extended attributes, metadata handling, stream(8), flash-native OpenZFS, a hypothetical S3 front-end for the OpenZFS object store, reproducible workloads, drama generators, and more!
"Don't forget to slam those Like and Subscribe buttons."
You now can support Call For Testing on Patreon: https://patreon.com/CallForTesting
2.4 getting close now! #OpenZFS
I 💝 OpenZFS
Working on research for a HPC storage cluster, one of my architecture doc sections quote this information from the wonderful group at Klara:
> OpenZFS In the Wild
>
> .. Lawrence Livermore National Laboratory (LLNL) undertook porting ZFS to Linux, to form the backbone of their Lustre distributed filesystem. They noted that OpenZFS facilitated building a storage system that could support 1 terabyte per second of data transfer at less than half the cost of any alternative filesystem.
>
> Based on the success seen at LLNL, Los Alamos National Laboratory (LANL) started using ZFS as well.
>
> In the latest example, just a few months ago the U.S. Department of Energy’s Oak Ridge National Laboratory announced it had built Frontier, the world’s first exascale supercomputing system and currently the fastest computer in the world, backed by Orion, the massive 700 Petabyte ZFS based file system that supports it. This impressive system contains nearly 48,000 hard drives and 5,400 NVMe devices for primary storage, and another 480 NVMe just for metadata.
#openzfs #zfs #freebsd #linux #engineering #supercomputing #hpc
A space for Bonfire maintainers and contributors to communicate