[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)
I have now litterally written hundreds of GB using dd and zfs send with enabled kmem_flags, but i was unable to reproduce the crash, I will keep on trying. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/489#issuecomment-365165038 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T91797982fdd5b7d9-M6bf829a127e72828e5e7e94a Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)
ahrens commented on this pull request.
> + */
+static void
+zfs_dispatch_mount(libzfs_handle_t *hdl, zfs_handle_t **handles,
+size_t num_handles, int idx, zfs_iter_f func, void *data, taskq_t *tq)
+{
+ mnt_param_t *mnt_param = zfs_alloc(hdl, sizeof (mnt_param_t));
+
+ mnt_param->mnt_hdl = hdl;
+ mnt_param->mnt_tq = tq;
+ mnt_param->mnt_zhps = handles;
+ mnt_param->mnt_num_handles = num_handles;
+ mnt_param->mnt_idx = idx;
+ mnt_param->mnt_func = func;
+ mnt_param->mnt_data = data;
+
+ (void) taskq_dispatch(tq, zfs_mount_task, (void*)mnt_param, TQ_SLEEP);
>From looking at the code, if libzfs_printerr is set then libzfs will call
>exit() on memory allocation failure. This is not set by default, but it is
>set by the zfs, zpool, zinject, libshare, dumpadm, and swap commands. So for
>the common ways of hitting this code ("zfs mount", "zfs share", "zpool
>import"), libzfs_printerr will be set, indicating that the desired behavior is
>to exit. The only caller of this code that might not have libzfs_printerr set
>is syseventd (it does this when a pool goes from being FAULTED (or worse) to
>DEGRADED or HEALTHY).
In practice, it looks like lots of (but not all) callers are assuming that we
will die if allocation fails (see callers of no_memory(), like zfs_alloc() and
the comments above them - the assume that libzfs_printerr is always set so we
always exit on failure).
So I'd say this is in keeping with the current behavior of handling allocation
failures poorly :-(
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/536#discussion_r167727390
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-Ma2fd472957defdae8fc6d719
Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 9091 Add mdb smart write (#544)
@sdimitro pushed 1 commit. a96b5da apply feedback -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/openzfs/openzfs/pull/544/files/f17764a59fa855e38e6044d0020648f07dd07599..a96b5daac5b0059e9074f0b59b8f9529d2157797 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Ta82fe96bb714cae3-M48b5f4a0ef5423040df0fa4a Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)
prakashsurya commented on this pull request. > @@ -88,6 +89,9 @@ #include #defineMAXISALEN 257 /* based on sysinfo(2) man page */ +static int mount_tq_nthr = 512;/* taskq threads for multi-threaded mounting */ I talked to Seb about this today, and it's like I was assuming. The number 512 here isn't necessarily special (we could change it), we just want a number large enough such that we can create enough threads to saturate the storage IOPs. Since each thread performing a mount will generally be IO bound, we want to have enough threads mounting concurrently, so that we more effectively utilize the storage IOPs. As far as CPU caps and zone considerations, I _think_ 512 should be fine. The performance consideration here is to make sure we issue enough IO, so we still want to have multiple threads issues mounts concurrently, even if we can only have a single thread running at a time. i.e. we want to be able to issue another mount, when the previous thread/mount blocks on IO. With that said, I'm not familiar with the CPU caps available, so perhaps I'm overlooking something. Let me know if you'd like some more information, and/or if you still have concerns here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/536#discussion_r167648019 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-Ma5151a88b3323f09b4774cf3 Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 9075 Improve ZFS pool import/load process and corrupted pool recovery (#539)
pzakha commented on this pull request. > @@ -461,6 +461,16 @@ kernel_fini(void) system_taskq_fini(); } +/* ARGSUSED */ +uint32_t +zone_get_hostid(void *zonep) After further investigation I'd propose to keep this in `libzpool` as the generic `libfakekernel` implementation should probably just be calling `gethostid()`. I'll add a comment in `zone_get_hostid()` to explain this special behaviour. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/539#discussion_r167639415 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T603f896faeeb4d25-Mfff1a50084e79626569abdbb Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8857 zio_remove_child() panic due to already destroyed parent zio (#505)
@grwilson pushed 1 commit. 1d7e2b0 all bits -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/openzfs/openzfs/pull/505/files/445e55128ca0a1cf9b0a7013d996edd50da3a0f4..1d7e2b0d0cb2416d9838f0bd25fc174f31c4be09 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Td0adf1bfacf39ae0-M94874194d6bc4b41eff311de Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 9075 Improve ZFS pool import/load process and corrupted pool recovery (#539)
pzakha commented on this pull request. > @@ -461,6 +461,16 @@ kernel_fini(void) system_taskq_fini(); } +/* ARGSUSED */ +uint32_t +zone_get_hostid(void *zonep) I'll need to look into it. It seems like `zone_get_hostid()` has a behaviour specific to libzpool as the value returned will either be `0` or `gethostid()` depending on the mode passed in `kernel_ini()` (see initialization of `hw_serial`). This might not be what we want for all users of libfakekernel. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/539#discussion_r167605634 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T603f896faeeb4d25-Me665b69855cad3830e663b8b Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#546)
@prakashsurya pushed 2 commits. ed3f718 Revert "9024 rework PV-HVM disk device handling" 2586d09 Revert "9023 port Delphix Xen-related fixes" -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/openzfs/openzfs/pull/546/files/8dc8d15df69ae501a45425d7c1ac54792d2af174..2586d09f2ce20f2353d9e28a79a3a5046cce95a7 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tef361ad06d3250ed-Mf8f44032de5800f923acb00d Powered by Topicbox: https://topicbox.com
[developer] [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#546)
You can view, comment on, or merge this pull request online at: https://github.com/openzfs/openzfs/pull/546 -- Commit Summary -- * 8792 mac_tx_srs_quiesce() can kill a maxbw link * 8652 Tautological comparisons with ZPROP_INVAL (followup) * 8760 troff: variable 'type' set but not used * 8967 libipmi: add support for GET_CHASSIS_STATUS command * 8493 kmem_move taskq appears to be inducing significant system latency * 8805 xattr_dir_lookup() can leak a vnode hold * 8731 ASSERT3U(nui64s, <=, UINT16_MAX) fails for large blocks * 8680 Time of Day clock error * 8985 update tzdata to 2018c * 8389 Convert rm(1) manpage to mdoc(5) * 8986 loader: try_multiple_kernels does not try multiple kernels * 8987 bootadm: add bootfile fallback to unix * 8685 uts and mdb: do not build 32bit kernel * 8997 ztest assertion failure in zil_lwb_write_issue * 8571 Makefile.master should not trust $PATH * 8990 /opt/onbld/gk is useless * 8991 pmodes is useless and can be deleted * 8992 checkproto is useless and can be deleted * 8998 depcheck is useless and should be removed * backout: 8571 Makefile.master should not trust $PATH (insufficient testing, broke bootstrap) * 8994 libc-tests: nl_langinfo_test fails after 1198 * 9003 libc-tests: newlocale_test silently fails after CLDR updates * 8668 mac_srs_change_upcall() is unused * 8969 Cannot boot from RAIDZ with parity > 1 * 8809 libzpool should leverage work done in libfakekernel * 9015 krb5-config emits unnecessary -R flags * 6690 set_nfsv4_ephemeral_mount_to() tries to read AUTOMOUNT_TIMEOUT from defunct /etc/default/autofs * 9007 import AT regex test suite * 9012 cmd/grep: don't use obsolete REG_ANCHOR * 9013 cmd/vi: don't use obsolete REG_WORDS * 9001 cdm is useless, remove it * 9005 remove .hgignore * 9006 parallel loader builds fail sporadically * 9023 port Delphix Xen-related fixes * 9024 rework PV-HVM disk device handling * 8914 loader: gcc 4.4.4 fails to allocate register for do_cpuid() * 8498 ficl: variable 'count' might be clobbered by 'longjmp' or 'vfork' * 9029 libc: duplicate 'const' declaration specifier * 8999 SMBIOS: cleanup 32-bit specific code * 9000 unix: cleanup 32-bit specific code in fakebop * 8210 uts: remove kb streams module * 9017 Introduce taskq_empty() * 9018 Replace kmem_cache_reap_now() with kmem_cache_reap_soon() * 9028 libc: comparison between pointer and zero character constant * 9027 Makefiles need to specify C99 mode consistently * 9022 loader.efi: module placement must check memory map * 9039 tcp(7p): Duplicate paragraph * 8966 Source file zfs_acl.c, function zfs_aclset_common contains a use after end of the lifetime of a local variable * 7638 Refactor spa_load_impl into several functions * 8961 SPA load/import should tell us why it failed * 8962 zdb should work on non-idle pools * 8706 libc lint library missing endian.h functions * 8472 Want docs for iports, tgtmaps, and friends * 8733 cxgbe: variable 'execute' set but not used * 9031 sgs/libld: comparison between pointer and zero character constant * 9032 sgs: this statement may fall through * 9034 pfexecd: duplicate lint target in Makefile * 9035 zfs: this statement may fall through * 9036 zfs: duplicate 'const' declaration specifier * 9037 pfexecd: this statement may fall through * 9038 fs.d/nfs: this statement may fall through * 9040 libnsl: unused local typedef in rpc code * 9025 libzfs missing dependency on libcmdutils * 9026 lib/fm missing dependency on libsff * 9033 nightly MUST use cw in tools proto * 8408 dsl_props_set_sync_impl() does not handle nested nvlists correctly * 8477 Assertion failed in vdev_state_dirty(): spa_writeable(spa) * 8520 lzc_rollback_to should support rolling back to origin * 8941 zpool add: assertion failed in get_replication() with nested interior VDEVs * 8942 zfs promote .../%recv should be an error * 9004 Some ZFS tests used files removed with 32 bit kernel * 8965 zfs_acl_ls_001_pos fails due to no longer supported grep regex * 9064 ZFS test remove_mirror should wait for device removal to complete * 8989 Allow IKEV2 pf_key(7P) key management cookies to be updated after set * 8933 libefi: Add definitions and utilities for EFI drivers * 9043 ipadm(1M) is misrendering the create-addr subcommand description * 9069 libfru: comparison between pointer and zero character constant * 9066 xdf devices attach hybrid VTOC/EFI label * 9070 Remove wanboot from gate * 8871 Want means of toggling data link LEDs * 8867 add MAC_CAPAB_TRANSCEIVER support for cxgbe * 8866 bnxe MAC_CAPAB_TRANSCEIVER support * 7094 mdb can't print types from an object file with ctf * 6653 dtrace modifies ELF string table causing problems for linker * 8571 Makefile.master should not trust $PATH * 8960 libefi: import efichar.c for ucs2 support * 9068 libgen: this statement may fall through * 9087 9001 forgot to remove
