I am using LLM to build some security tool, and I ran into this a few times. I have to come up with a reasoning to convince (?!!) Fable to continue the work without downgrading.
I assume Anthropic will continue to tune the model, so I am not too bothered by this.
I ran 5 external USB + SMR hard disks in RAIDZ 5 for 10 years. The only thing I had to change was to use Highpoint's enterprise level USB controllers- commercial USB controllers from Realtek and Renasus are junk and will drop the drives after a while.
Even then, I had multiple cases where files were corrupted, and once the whole array refused to be online due to corrupted metadata. I had to make ZFS to replay the journal log with undocumented commands. Sometimes it takes a few days of hair-rising recovery but I always manage to get the array back intact.
The files that are corrupted are always extremely large files (>50 GB) with many small read/writes (eg. iSCSI image files.)
It's pretty impressive how resilient ZFS is, really, given I had what likely to be the worst possible hardware combination.
Except zvols present as real-live block devices that can do block-device things instead of regular-file things, and that's important for some stuff.
But AFAICT, iSCSI targets on Linux are not one of those things. They don't care; they work the ~same whether backed by files or block devices.
And on the performance benchmarks I find that compare performance of zvols-vs-files on ZFS, files usually win.
> Why use zvols?
Probably for the same reasons that people recommended separate disk partitions for /var, /usr, and such as was the case ~30 years ago when I got started with desktop *nix systems.
That reason seemed to boil down to: "If it was good for a Sun/3 in 1986, then it must also be good for a Linux box in 1996." It was a dumb reason.
> That reason seemed to boil down to: "If it was good for a Sun/3 in 1986, then it must also be good for a Linux box in 1996." It was a dumb reason.
ext2 disk corruption, especially on power failure or a crash, was a common threat in the 1990s. Not merely to the point of requiring fsck and a bunch of orphaned files (which was inevitable on an unclean shutdown), but just totally fubar'd, requiring a reformat. The only thing worse was then trying to reinstall Slackware from the floppy disks, at least one of which had a better than even chance of corruption from just sitting in the drawer since the last reinstall, requiring another long night nursing a download over the 2400 baud modem.
I use OpenBSD, and while FFS2 has been far more robust than 1990s Linux ext2, smart partitioning is still warranted, not just for minimizing blast radius, but also for managing backups, etc. I haven't had the chance to use ZFS, and it might be the only filesystem I might consider skipping partitioning for on a workhorse system, but even if you trust the design and code quality of ZFS, it's running unprotected alongside a bunch of horribly buggy kernel subsystems and drivers, so....
You raise an interesting point. Please allow me to enhance it.
It could get worse than reinstalling Slackware, again, from floppies. I didn't get to experience corrupted floppies; I instead had a habit of recycling my Slackware disksets for other purposes after the system was up and running. So any complete re-install started by booting up MS-DOS to run Telemate to start downloading them fresh from Sunsite...again.
But at least it was Telemate, so I could manage files to free up more floppy disks while this process slowly continued at [I guess I was fortunate] 9600 or 14.4kbps. ;)
I don't recall much difficulty with ext2 being fragile (though I can provide horror stories about OS/2's HPFS). If I had issues with it, they didn't leave any scars.
But I accept your correction. It may have been the case that splitting the filesystem into different partitions made sense because ext2 was fickle, and I was just very lucky in deliberately ignoring that advice after the first time I misjudged the partition sizes at install and ran out of space in some directory or other.
Hard drives seemed so small back then. Installing a real OS meant a serious tradeoff in the ratio between user data and system data.
---
Anyway, ZFS. The ZFS way is that it owns the whole disk -- for a long time, the preferred method didn't even use partitions at all. Nowadays OpenZFS does create one partition for itself by default, but it uses the whole disk just the same.
Blast radius is limited by having different datasets (think "filesystem-light"), and read-only snapshots, and easy, consistent backups (if you have a compatible device or service to send them to -- otherwise, it's ~the same backup dance as any other filesystem with snapshots).
It's a different way of doing things, like a subsystem in and of itself. It keeps its own caches and generally wants to be as close to the metal as it can be. Which sounds scary, but meh: Almost everything worth doing gets done with two commands, zfs and zpool, and the syntax has been consistent enough over the years that old documentation from Sun still has value.
I've been using it for most of a decade now and I find it to be ridiculously good. My only wish is that it could be a first-rate player on Linux, but license incompatibilities be that way sometimes.
- serving a bunch of storage as a blob is a common use case for e.g. iSCSI exporting, and so, if you want to be able to zfs snapshot/send/rollback/etc on the level of "one logical disk", it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
- avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Of course, in the era where you're sad that inline compression/checksum/etc are bottlenecking your 48 NVMe pool, that probably isn't where you'd reach for optimizing first...or second...
But just exposing the block storage is sufficiently useful that at least one of the original projects to port ZFS on Linux wasn't planning to implement the FS layer, they just wanted block storage for Lustre.
I felt the same way about it as you before I started looking for benchmarks as I wrote my previous comment. :)
After all: Why would zvols exist at all if they weren't superior in important ways?
> it makes sense to have an optimized route to expose that rather than making you expose a filesystem that only has one file on it to do the same dance
It's important to note that additional datasets are essentially free on ZFS; it's no big deal to have lots of them (millions of millions of them is A-OK), and datasets don't have a pre-determined size like zvols do.
Although zvols can also be grown and shrunk, just as files [within datasets] can be.
Both datasets and zvols make the same kind of mess out of zfs list's unfiltered output.
But zvols introduce a new concept, while anyone who uses ZFS is already familiar with datasets that contain files.
I think this part is a wash, and that it comes down to operator preference.
> avoiding unnecessary overhead/complexity from the FS layer being involved when all you really care about is exposing a single block device of storage
Maybe? Again, the benchmarks I found (hours ago now and tabs long-closed; I'll find more if anyone insists) suggested that files were faster than zvols, which suggests reduced overhead. (It's very possible that the tests I found were naively implemented, but then: It's also possible for any of us to do something naive.)
Anyway, it's interesting to think about.
It seems like the right answer is to test with one's own workload and find the best fit, instead of assume that one way is better than the other.
For its part, ZFS should handle a zvol and a file-on-a-dataset with equal stoicism and reliability.
Sure, I'm not suggesting that they're a good idea to use blindly at this point - I think most people are building on filesystem-based setups so most of the polish is going there.
But that was the original logic.
I also would be curious to see benchmarks for them on FBSD and Linux, because FBSD and Linux (the platforms at large) diverged in how they handle "disks", with FBSD opting for only character devices (unbuffered) and Linux only block devices (buffered).
Because all the educated Indians moved to US and contributed to the American economy, versus the Chinese who get educated in America, then move back to China to work there.
English is a major reason- Indians are just better at speaking English than Chinese and thrives in corporate America. Whereas mainland Chinese couldn't climb the corporate ladder and have to seek better opportunities back in China.
Find me a tech executive in a Big Tech firm who is from mainland China. You can't find one. Both Lisa Su of AMD and Jensen Huang of Nvidia are Taiwanese immigrants who grew up in US in the 70s and thus speak fluent English.
2 companies have functionally similar products, but behaves completely different. One company makes technical decisions with security as the fundamental principal, while for the other company, security is not a consideration.
Having it running on host (!), and the metadata for all guest VMs stored and managed by the same memory/service (!!), with no clear security boundary (!!!).
It's like storing all your nuke launch codes in the same vault, right in the middle of Washington DC national mall. Things are okay, until they are not okay.
As someone who had worked adjacent to the functionally-same components (and much more) at your biggest competitor, you have my sympathy.
Running 167 agents in the accelerator? My gawd that would never fly at my previous company. I'd get dragged out in front of a bunch of senior principals/distinguished and drawn and quartered.
And 300k manual interventions per year? If that happened on the monitoring side , many people (including me) would have gotten fired. Our deployment process might be hack-ish, but none of it involved a dedicated 'digital escort' team.
I too have gotten laid off recently from said company after similar situation. Just take a breath, relax, and realize that there's life outside. Go learn some new LLM/AI stuff. The stuff from the last few months are incredible.
We are all going to lose our jobs to LLM soon anyway.
- Local LLM, with a powerful debugger as its oracle, is now powerful enough to run rudimentary malware analysis without consulting with external sources.
- More complex malwares are still beyond what local LLMs can handle. The local LLM can see all the behaviors by the malware, but the LLM fails to put the analysis together to deduce the true intention of a binary.
- Local LLM is a very lost-cost way to do malware analysis (about 5 US cents of electricity.)
- The biggest killer-app feature is having the LLM writes its analysis back to Ghidra. The more you interact with the LLM, the more data it will write back to Ghidra. This could potentially saves hours per manual debugging by skipping function/resources/variables labeling.
The "NemoClaw vs. OpenClaw" section is absolutely ridiculous.
OpenClaw vs NemoClaw (NVIDIA)
Developer Peter Steinberger (individual project) vs NVIDIA Corporation
Current Status Acquired by OpenAI (Feb 2026) vs Upcoming release (GTC 2026)
Target Market General-purpose consumer AI assistant vs Enterprise AI agent platform
Core Strength Rapid deployment, viral adoption vs Security, privacy, enterprise reliability
Ecosystem Community-driven (NanoClaw variants) vs NVIDIA NeMo & NIM integration
Governance Transitioning to foundation management vs NVIDIA-backed with open-source access
GPU Acceleration Not natively optimized vs Native NVIDIA GPU acceleration
NemoClaw is not even out yet, so who knows what it might look like. I guess if you sprinkle the word 'Nvidia' around enough, your product is automatically better than the rest.
I don't even like OpenClaw, but this is just silly.
Insurance and overhead (eg. safety harass) exist for a reason other than to drain your wallet. Roofing is also a physically difficult job. You won't find many 50+ year old to couch on a rooftop all day, regardless of pays.
I assume Anthropic will continue to tune the model, so I am not too bothered by this.
reply