> If there were a “zfs send” datastream saved someplace, is there a way to
> verify the integrity of that datastream without doing a “zfs receive” and
> occupying all that disk space?
Depending of your version of OS, I think the following post from Richard Elling
will be of great interest to you:
>> Depending of your version of OS, I think the following post from Richard
>> Elling will be of great interest to you:
> Where exactly do you get zstreamdump?
> I found a link to zstreamdump.c ... but is that it? Shouldn't it be part of
> a source tarball or something?
> Does it matter what OS?
>> Creating a slice, instead of using the whole disk, will cause ZFS to
>> not enable write-caching on the underlying device.
> Correct. Engineering trade-off. Since most folks don't read the manual,
> or the best practices guide, until after they've hit a problem, it is really
> just a CYA entr
> Sigh. Richard points out in private email that automatic savecore
> functionality is disabled in OpenSolaris; you need to manually
> set up a dump device and save core files if you want them.
> However, the stack may be sufficient to ID the bug.
The dump device is present, so no need to set up o
>> I am sorry, we don't have oracle databases on zfs filesystems
>> (colleagues of mine are currently exploring RMAN to backup oracle
>> databases, that reside on a ufs filesystem, however).
>>
>> We are doing backups of zfs storage pools with about 2000 filesystems
>> (basically home directories).
> Did the ZFS gzip compression feature (i.e. "zfs set compression=gzip")
> make it in to Solaris 10 U4? I was looking forward to being able to use it
> in a production Solaris release without having to compile my OpenSolaris
> build, but it doesnt' seem to be there.
No. This feature was introduce
