similar to: Export ZFS via ISCSI to Linux - Is it stable for production use now?

http://defect.opensolaris.org/bz/show_bug.cgi?id=2114 Summary: delegation_004: a non-root user can''t do ''zfs key -c'' with keychange delegated Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: normal

In another thread recursive snapshot creation was found atomic so that it is done quickly, and more important, all at once or nothing at all. Do you know if recursive destroying and renaming of snapshots are atomic too? Regards Henrik Heino

http://defect.opensolaris.org/bz/show_bug.cgi?id=2033 Summary: ''zfs create'' causes panic if key file doesn''t exist Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: minor Priority: P2 Component:

As part of looking into a minor issue with the group listed when using runat(1) on a UFS filesystem for Johannes (my Google Summer of Code student work on new basic file privs), I discovered an even bigger issue with UFS and extended attributes. I''ve cc''d ZFS discuss because I used ZFS as the comparison and I believe that ZFS is acting correctly but even then it might not be

http://defect.opensolaris.org/bz/show_bug.cgi?id=631 Summary: zpool get with no pool name dumps core in zfs-crypto Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: minor Priority: P4 Component: other AssignedTo:

http://defect.opensolaris.org/bz/show_bug.cgi?id=1986 Summary: ''zfs destroy'' hangs on encrypted dataset Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other

I thought I recalled reading somewhere that in the situation where you have several zfs filesystems under one top level directory like this: rpool rpool/ROOT/osol-112 rpool/export rpool/export/home rpool/export/home/reader you could do a shapshot encompassing everything below zpool instead of having to do it at each level. (Maybe it was in a dream...)

http://defect.opensolaris.org/bz/show_bug.cgi?id=782 Summary: zfs keysource=raw fails with keyscope=dataset when file doesn''t exist Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: minor Priority: P4

Hi, I am having a problem porting Solaris R/W lock functionality to Linux. The problem is that RW_LOCK_HELD() doesn''t have an equivalent function in pthreads. This was not a problem before because RW_LOCK_HELD() was only used in ASSERT statements. In this case, I was able to make it work by making it behave a bit differently (specifically, it would return true if *any* thread was

http://defect.opensolaris.org/bz/show_bug.cgi?id=2247 Summary: tests/functional/cli_root/zpool_upgrade/zpool_upgrade_00 7_pos panics - zfs snapshot Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority:

http://defect.opensolaris.org/bz/show_bug.cgi?id=2334 Summary: zpool destroy panics after zfs_force_umount_stress Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other AssignedTo:

The subject says it all.

Anthony Scarpino wrote (elsewhere): > While writing up the man page.. I thought of a few things that I was > wondering if you considered.. > > Can an encrypted dataset (keytype=dataset) reside in a non-encrypted (no > kek defined) pool? I can see a case for and against allowing this when considering it purely at the feature level as users/admins see things. The admin can

Anthony Scarpino wrote (elsewhere): > While writing up the man page.. I thought of a few things that I was > wondering if you considered.. > > Can an encrypted dataset (keytype=dataset) reside in a non-encrypted (no > kek defined) pool? I can see a case for and against allowing this when considering it purely at the feature level as users/admins see things. The admin can

http://defect.opensolaris.org/bz/show_bug.cgi?id=1657 Summary: tests/functional/acl/nontrivial/zfs_acl_cp_001_pos causes panic Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: critical Priority: P2

I''m pleased to announce that the ZFS Crypto project now has Alpha release binaries that you can download and try. Currently we only have x86/x64 binaries available, SPARC will be available shortly. Information on the Alpha release of ZFS Crypto and links for downloading the binaries is here: http://opensolaris.org/os/project/zfs-crypto/phase1/alpha/ Please pay particular note to

I''m pleased to announce that the ZFS Crypto project now has Alpha release binaries that you can download and try. Currently we only have x86/x64 binaries available, SPARC will be available shortly. Information on the Alpha release of ZFS Crypto and links for downloading the binaries is here: http://opensolaris.org/os/project/zfs-crypto/phase1/alpha/ Please pay particular note to

http://defect.opensolaris.org/bz/show_bug.cgi?id=752 Summary: zfs set keysource no longer works on existing pools Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: blocker Priority: P1 Component: other AssignedTo:

http://defect.opensolaris.org/bz/show_bug.cgi?id=2175 Summary: running full test/cli tests cause panic after a number of tests run.. Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: normal Priority: P2

http://defect.opensolaris.org/bz/show_bug.cgi?id=971 Summary: zfs key -l fails after unloading (keyscope=dataset) Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other AssignedTo: