>>>>> "nw" == Nicolas Williams <nicolas.willi...@sun.com> writes:
nw> For NFSv4 clients that support mirror mounts its not a problem
nw> at all.
no, 3000 - 10,000 users is common for a large campus, and according to
posters here, sometimes that many users actually can fit into the
bandwidth of a single pool. But ZFS is not useable with that many
filesystems. booting, 'zfs create', 'zfs list', all take hours. see
list archives.
If the on-disk format is theoretically capable of achieving O(1) for
number of filesystems, that's nice! It's just not an advantage over
NetApp when it's not working yet. And, with any project, sometimes the
last 5% of the work never gets done.
so I'm making a desperate call to start basing punditry on experience
rather than white papers and optimistic architecture documents.
OpenSolaris could have an advantage here---it's much easier to get
experience with Solaris than NetApp because it's not (a) expensive and
(b) locked behind a bunch of licenses, agreements and contracts,
unshareable documentation, private censored web forums (NOW site),
u.s.w., so OpenSolaris punditry could one day become a lot more
trustworthy than NetApp punditry.
nw> You're not required to go with one-filesystem-per-user though!
It was pitched as an architectural advantage, but never fully
delivered, and worse, used to justify removing traditional Unix
quotas. Consequently, quota-wise, ZFS becomes a regression w.r.t. UFS
rather than an evolution, because of over-focusing on the virtues of
the architecture rather than the delivered implementation.
I don't use quotas and don't care, but it's a good example of broken
advocacy.
nw> It's NOT O(N) to boot because of snapshots, nor to scrub.
I think it is. try it and see. :/
That was Tim's point as I read it. Jeff claimed ``unlimited snapshots
and clones'' as a ZFS advantage over NetApp, and Tim said open bugs or
subtle limitations make the supposed advantage a fantasy, even a
liability:
``"unlimited snapshots". Do I even need to begin to tell you what a
horrible, HORRIBLE idea that is? "Why can't I get my space back?"
Oh, just do a snapshot list and figure out which one is still
holding the data. What? Your console locks up for 8 hours when
you try to list out the snapshots? Huh... that's weird.''
...and to add to that, the snapshot list in ZFS does a better job of
showing which one's using the space if there are fewer snapshots.
with hundreds of snapshots 'zfs list' shows a USED column full of
zeroes, correctly, because you won't save any space by deleting just
one---you have to delete a range of snapshots to get some space back.
Of course that's not the same thing as being O(N), that's just
annoying.
and I don't know that it's really O(N)---it could be better or worse
than O(N). It's not O(1) though, to boot, list, or scrub snapshots.
and if it's not O(1) because of some unnecessary high-level ioctl
accidentally called in some obscure, abstract library by the
``simple'' user interface, it's still not O(1)! For practical users,
that library could remain suboptimal for the next two years, and I
don't want to spend those two years enduring a bunch of blogging about
nonexistent O(1) snapshots just because the on-disk format
theoretically doesn't impede delivering them.
pgpflzCqrMev9.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
