Samuel Hexter wrote:
Hi all,
Two separate questions:
1. We have a pool with 134 filesystems which collectively have about
75000 snapshots. The "zfs list" command grows to over 650MB resident
before printing its output. This doesn't overly bother me since the
box in question (snv53) has plenty of memory but I thought I'd ask
whether it is a known area for improvement since it does seem a
little excessive.
I'm not aware of that... Since the output it sorted, clearly we must use
O(snapshots+filesystems) memory, but 8k per snapshot seems excessive.
I've filed 6539380 to track this issue.
2. I have a couple of safety-related questions about zfs send/recv.
The first is about the versioning of these streams -- if a version
incompatibility exists, will the recv complain or is the behaviour
undefined?
recv will complain.
> Similarly, if a stream were to be corrupted in transit, is
it possible that the recv could somehow corrupt the destination
filesystem/pool?
The stream is checksummed, so we would detect the corruption and abort
the recv.
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
