>>>>> "bc" == Bryan Cantrill <b...@eng.sun.com> writes: >>>>> "jz" == Joseph Zhou <j...@excelsioritsolutions.com> writes:
bc> most of the people I talk to are actually _using_ NetApp's
bc> technology, a practice that tends to leave even the most
bc> stalwart proponents realistic about the (many) limitations of
bc> NetApp's
same applies to ZFS pundits!
As Tim said, the one-filesystem-per-user thing is not working out.
O(1) for number of filesystems would be great but isn't there.
Maybe the format allows unlimited O(1) snapshots, but it's at best
O(1) to take them. All over the place it's probably O(n) or worse to
_have_ them. to boot with them, to scrub with them.
I think the winning snapshot architecture is more like source code
revision control: take infinitely-granular snapshots, a continuous
line, and run a cron service to trim the line into a series of points.
The management can be delegated, but inspection commands are not safe
and can lock the whole filesystem, and 'zfs recv'ing certain streams
panics the whole box so backup cannot really be safely delegated either.
The panic-on-import problems are bad for delegation because you can't
safely let users mount things, which to my view is where delegated
administration begins. It's too unstable to think of delegating
anything---it's all just UI baloney until the panics are fixed and
failures are contained within one pool.
The scalability to multiple cores goals are admirable, but only
certain things are parallelized. You can only replace one device at a
time, which some day will not be enough to keep up with natural
failure rates. I think 'zfs send' does not use multiple cores well,
right? AIUI people are getting non-scaling performance in send/recv
while the ordinary filesystem performance does scale, and thus getting
painted into a corner.
Yeah there's compression, but as Tim said people are getting more
savings from dedup, which goes naturally with writeable clones too.
Also the NetApp dedup is a background thread while the ZFS compression
is synchronous with writing. as well as not scaling to multiple cores
and seeming to have some bugs in the gzip version.
Yeah there is some heirarchical storage in it, but after half a year
still a slog cannot be removed?
In general I think ZFS pundits compliment the architecture and not the
implementation.
The big compliment I have for it is just that the ZFS piece is free
software, even though large chunks of OpenSolaris aren't. That's a
gigantic advantage, especially over NetApp, which probably has about
as much long-term future as Lisp.
jz> As a friend, and trusting your personal integrity, I ask you,
jz> please, don't get mad, enjoy the open discussion.
Joseph, I don't see the problem and think it's fine to excited so long
as actual information comes out. There's nothing ad-hominem in the
discussion yet, and being ordered not to get mad will make any normal
person furious, especially if you make the order based on ``trust''
and ``personal integrity''---why bring up such things at all? I
almost feel like you're baiting them! I know it's normal for
sysadmins to be dry and menial, but it's still a technical discussion,
so I hope it doesn't upset anyone because it's not boring.
pgpxsvjCwkKjS.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
