[developer] Re: [openzfs/openzfs] Merge remote-tracking branch 'illumos/master' into illumos-sync (#546)

2018-02-15 Thread Prakash Surya
@prakashsurya pushed 1 commit. 74f5fe6 Revert "8685 uts and mdb: do not build 32bit kernel" -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

2018-02-15 Thread Jorgen Lundman
It is interesting that `l2arc_write_buffers` is one of the places the merge was not smooth. Re-porting the function from clean did not change much alas, adding flag `ARC_FLAG_L2_WRITING` . The IllumOS version has an extra chunk of code that the other platforms have: ```

[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

2018-02-15 Thread Jorgen Lundman
@lundman pushed 1 commit. 5ebecdd Re-port l2arc_write_buffers just in case -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[developer] Re: [openzfs/openzfs] 9112 Improve allocation performance on high-end systems (#548)

2018-02-15 Thread Matthew Ahrens
I think the change as proposed does have "safe defaults and tunable as a last resort". We're speculating here about the impact on locality. I think we should measure that before going with a lower default value (which would decrease the benefit to high-performance systems and require tuning

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

2018-02-15 Thread Andrew Stormont
andy-js 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 suppose this could be made a tuneable through

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

2018-02-15 Thread Andrew Stormont
andy-js commented on this pull request. > -#ifdef __cplusplus -extern "C" { -#endif - -#include -#include -#include -#include -#include -#include - -#ifdef __cplusplus -} -#endif - -#endif /* _SYS_ZFS_CONTEXT_H */ I'm glad to see this file go. Too bad we can't also drop the one in

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

2018-02-15 Thread Prakash Surya
@rmustacc any more questions/comments on this? -- 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#issuecomment-366075230 -- openzfs-developer

[developer] Re: [openzfs/openzfs] 9112 Improve allocation performance on high-end systems (#548)

2018-02-15 Thread Alexander Motin
Safe defaults and tunables are fine as last resort. -- 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/548#issuecomment-366072630 --

[developer] Re: [openzfs/openzfs] 8727 Native data and metadata encryption for zfs (#489)

2018-02-15 Thread Prakash Surya
So, in this case, we appear to be attempting a write, but the `io_abd` field of the `zio` is `NULL`. ``` > ff03e497c630::print zio_t io_abd io_abd = 0 ``` I think we're here in `vdev_disk_io_start`: ``` 785 if (zio->io_type == ZIO_TYPE_READ) { 786 bp->b_un.b_addr =

[developer] Re: [openzfs/openzfs] 9112 Improve allocation performance on high-end systems (#548)

2018-02-15 Thread Andrew Stormont
Am I right in thinking these are the changes that were presented an OpenZFS Europe a couple of years back? -- 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/548#issuecomment-366071890

[developer] Re: [openzfs/openzfs] 9112 Improve allocation performance on high-end systems (#548)

2018-02-15 Thread Paul Dagnelie
I would be open to suggestions on how to implement self-tuning behavior for this; we spent some time thinking about it, but didn't have any great solutions. In absence of a good self-tuning mechanism, picking a safe default and giving users the option to tweak for better performance is probably

[developer] [openzfs/openzfs] Add Jenkins job to verify illumos commits (#549)

2018-02-15 Thread Prakash Surya
In an effort to more easily find "bad" commits when syncing with the upstream illumos repository, this change adds a Jenkins job that will iterate through all of the illumos commits not yet applied to OpenZFS, and verify the build, upgrade, and boot of each commit. You can view, comment on, or

[developer] Re: [openzfs/openzfs] 9112 Improve allocation performance on high-end systems (#548)

2018-02-15 Thread Alexander Motin
I don't believe in tunables for production systems. Users always tend to misuse them or simply don't know about them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: