zfs discuss - Mar 2007 - (1) zfs list memory usage (2) zfs send/recv safety

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.

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? Similarly, if a stream
were to be corrupted in transit, is it possible that the recv could somehow
corrupt the destination filesystem/pool?

Thanks in advance for any info.
 
 
This message posted from opensolaris.org

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