search for: dsl_dataset

Line 71 of http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/zfs/sys/dsl_dataset.h#dsl_dataset_phys says uint64_t ds_pad[8]; /* pad out to 256 bytes for good measure */ But that padding actually increases dsl_dataset_phys to 320 bytes total; the structure is already 256 bytes without the padding. This message posted from opensolaris.org

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=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

...test case: tests/cli/zfs_key_l_008 | UNSUPPORTED Running root test case: tests/cli/zfs_key_u_001 | another run saw a panic occur after zfs_set_keysource_001.. panic[cpu0]/thread=2a100787ca0: assertion failed: used == ds->ds_phys->ds_unique_bytes (0x0 == 0x400), file: ../../common/fs/zfs/dsl_dataset.c, line: 1641 000002a1007874c0 genunix:assfail3+98 (7b31ba28, 0, 7b31aec0, 400, 7b31adb0, 669) %l0-3: 00000000f4eef4ee 00000000f4eef400 0000000000000000 00000000018a2400 %l4-7: 0000000000000000 0000000001853800 000000000136a000 0000000000000000 000002a100787580 zfs:dsl_dataset_destroy_sync+958...

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

ZFS documentation lists snapshot limits on any single file system in a pool at 2**48 snaps, and that seems to logically imply that a snap on a file system does not require an update to the pool?s currently active uberblock. That is to say, that if we take a snapshot of a file system in a pool, and then make any changes to that file system, the copy on write behavior induced by the changes will

...num, DMU_OT_DSL_DIR, - mdn, stack))) + if (errnum = dnode_get(mosmdn, objnum, DMU_OT_DSL_DIR, + mdn, stack)) return (errnum); *fsname = ch; @@ -958,7 +1099,7 @@ get_objset_mdn(dnode_phys_t *mosmdn, cha *obj = headobj; skip: - if ((errnum = dnode_get(mosmdn, headobj, DMU_OT_DSL_DATASET, mdn, stack))) + if (errnum = dnode_get(mosmdn, headobj, DMU_OT_DSL_DATASET, mdn, stack)) return (errnum); if (issnapshot) { uint64_t snapobj; @@ -966,13 +1107,13 @@ skip: snapobj = ((dsl_dataset_phys_t *)DN_BONUS(mdn))-> ds_snapnames_zapobj; - if ((errnum = dnode_get(mosmdn...