ewwhite

Oh, the memories! We're still around. I remember when you handed the torch off to me on the leaderboard.

The real life examples and synergies were a plus. I got so much work from that ServerFault presence.

17 years and 202,000 internet points -https://stackexchange.com/leagues/2/alltime/serverfault

I contributed heavily to that site and spent the meat of my IT career posting about my gained experience. It helped me get jobs, and opened all sorts of consulting opportunities. I used to proudly point at that body of work because Stack Exchange and ServerFault were universally known in the industry.

It is wild knowing the LLMs were trained on these contributions. And today, I encounter IT professionals who confidently say, "I've never used anything from that site"

Do you know if those contributors were able to get their accounts back? I was a heavy contributor in a couple of technological subs, and my account was shadowbanned and then removed with no recourse or way to regain access.

That was entirely digestible and an interesting view.

This was user error and a major misunderstanding and mischaracterization of an issue that caused a bit of unexpected panic.

It's insane and horribly disrespectful. I don't understand the animus either. I just sent a $ donation to the maintainer.

The response to this bug is completely over the top. He found a security issue in an optional feature, immediately fixed it over the New Year holiday, and provided clear documentation about who was affected and how to address it. That's exactly how responsible disclosure should work.

The level of hostility - especially over adding optional features that people can simply choose not to use - suggests this is more about bandwagoning than legitimate criticism. We should be supporting developers who maintain critical open source infrastructure, not attacking them over a prompt response to a contained issue.

ZFS on Linux is absolutely fine in high-performance and critical computing applications.

I also owned a Thumper and Thor running Solaris in 2009. Much prefer Linux and the hardware solutions today.

This is a bit ranty.

ZFS is maturing on Linux and the codebase and general focus is on Linux today. Hardware compatibility and mindshare are also big factors.

It seems like a subset of the TrueNAS community reveled in the fact that Core was FreeBSD-based. Maybe just a bit contrarian.

I've had meh experiences supporting, repairing and transitioning installations away from ixSystems. I wouldn't advocate their offerings in the first place, but it does seem like you have unrealistic expectations from ixSystems.

It depends on the use case. For high-speed microscopes, I may get a request that says, "we need to support 4.2 Gigabytes/second of continuous ingest for an 18-hour imaging run." - In those situations, it's best to test with realistic data.

For general video and media workloads, it may be something like, "we have to accommodate 40 editors working over 10GbE (2 x 100GbE at the server) and minimize contention while ingesting from these other sources".

I work with iozone to establish a baseline. I also have a "frametest" utility that helps when mimicking some of the video characteristics.

There are definitely better ways to benchmark.

I design similar NVMe-based ZFS solutions for specialized media+entertainment and biosciences workloads and have put massive time into the platform and tuning needs.

Also think about who will be consuming data. I've employed the use of an RDMA-enabled SMB stack and client tuning to help get the best I/o characteristics out of the systems.

We had the CGI Massachusetts state exchange business, which led to [additional exchange work](https://www.datacenterknowledge.com/archives/2014/02/25/mana...) in the lead-up. There were many last- minute changes and very little load testing, but I was instrumental in getting core VMware infrastructure onto HPE equipment instead of Supermicro. The firm was a private cloud and infrastructure services group, [LogicWorks](https://www.logicworks.com).

I was there and lead Linux engineer with the hosting firm CGI outsourced this effort to...

Syncoid is the way. Zrepl was more fraught in my use cases and significantly more complicated.

Oh, that's a bit cluttered...

Yeah, that's a myth now. It's not current advice.

What about it?

Basically. I'm holding onto my 1999 1200's forever.

MELS?

Truth. And they scared much of their customer base away.

Yep, I remember those days.

As #1 (now #2) on ServerFault.com for many years, it opened a lot of doors for me as a consultant. I could reference my reputation as a "body of work" and it carried a lot of weight. Most employers, staff, recruiters are familiar with the sites, and it made things relatable.

I orchestrate ZFS snapshots using Monit and Syncoid.

See: https://serverfault.com/a/842740/13325

I mean, mrskin.com

Why do you want to be in "the middle"?

I've used UDT via UDR for rsync optimization and transfers over high-latency links: https://github.com/LabAdvComp/UDR

I've been using this kexec-reboot utility for years.

https://github.com/error10/kexec-reboot

What happened?

I feel like we're missing a lot of detail between Vancouver, WA and how you ended up in rural Japan... Can you fill some of that in? How did you end up there?

In every ZFS on Linux discussion, there's a question like this. The short answer is that nobody really wants to be forced to run FreeBSD just for ZFS...

Also consider hardware support, mindshare and the flexibility/need to use more of the OS than just the filesystem.

I began with ZFS on Solaris, then Nexenta... then jumped to ZFS on Linux in 2012. FreeBSD was a non-starter because my hardware platform (HPE ProLiant) was poorly supported under FreeBSD. That killed it as an option.

I'm surprised how often people ask this.