4 Feb
2021
4 Feb
'21
10:49 p.m.
On 2/4/21 10:32 AM, Dan Cross wrote:
On Thu, Feb 4, 2021 at 10:47 AM Will Senn
<will.senn(a)gmail.com
<mailto:will.senn@gmail.com>> wrote:
[snip]
In response to the negative vibes around ZFS. [snip]
I think the discordance is around the semantics ZFS's implementation
implies. Larry's point about mmap() vs a buffer cache is entirely
valid; it took lots of people heroic amounts of work worthy of Greek
sagas to bridge the difference between the original buffer and VM page
caches, but ZFS says, "meh. too much work; not worth it." The
practical implication of that is that memory mapped IO (via `mmap`) is
no longer coherent with file IO (via `open`/`close`/`read`/`write`)
without lots of work that both degrades performance and add complexity.
The question that a lot of folks who use ZFS regularly ask is, "does
that matter?" And perhaps it doesn't: if I've got a file server
sitting there serving NFS, do I care what it's kernel is doing? As
long as it's saturating the network and disks, and it's reliable...not
really. (Incidentally, that was kind of the philosophy behind the
original plan9 file server kernel...as I heard the story, the rate of
change of the plan9 kernel proper was too high, so Ken split off the
file server portion into its own, special-purpose kernel, and it
stayed like that for ~20 years). Similarly, if I'm on the local
machine and the required coherence code is there and largely works,
then again, perhaps as a consumer of the filesystem, I just don't
care. After all, one can still get work done, and ZFS has a bunch of
other features that make it very attractive, right? In particular,
it's very good at NOT losing my data, kernel purity be damned.
On the other hand, if we're discussing OS design and implementation,
(re)splitting the VM and buffer caches is a poor decision. One might
well ask, "why?" and the answer may be, "because it adds significant
complexity to the kernel." This to me seems like the crux of the
disagreement. Satisfied users of ZFS might legitimately ask, "who
cares?" and one might respond, "kernel maintainers." If the kernel is
mostly transparent as far as a particular use case goes, though, then
I can see why one would bulk at the suggestion that this matters. If
one is concerned with the design and implementation of kernels, I
could see why one would care very much.
Like many things, it's a matter of perspective.
- Dan C.
Thanks for the comments, Dan. I see your point. I was thinking as a
user/admin. In this light, I'll admit that I'm not an expert on the
internals and say that I can only imagine the breadth of design
tradeoffs that were contemplated and the many decisions that were made
when coming up with ZFS. I'm glad somebody thought through them, and
worked through them, though. So I could consume their work,
Frankensteinian though it may be. Now, if somebody would only get it
working properly in Linux (boot environments included), or even get
BTRFS to be more realiable, I'd be a happy camper, at least for a while :).