In D26196#582083, @mmacy wrote:In D26196#582060, @mahrens wrote:Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?
Changes to contrib should always be made in the following order when possible:
a) update upstream
b) update vendor branch with latest changeset
c) merge vendor branch in to HEADThus the first step is to open a PR with openzfs.
We may eventually relax the ordering if this proves too onerous for something as tightly coupled as ZFS and transition to "eventual consistency" whereby contrib + vendor + upstream are eventually the same.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Jun 8 2021
Jun 8 2021
mahrens committed rGc81f1790e28a: Metaslab max_size should be persisted while unloaded (authored by pcd_delphix.com).
mahrens committed rG99e755d653ae: Don't wakeup unnecessarily in 'zpool events -f' (authored by DeHackEd <DeHackEd@users.noreply.github.com>).
mahrens committed rG809846555818: Test cancelling a removal in ZTS (authored by Serapheim Dimitropoulos <serapheim@delphix.com>).
mahrens committed rGcae97c88c4ed: List log_spacemap feature in zpool-features.5 manual (authored by Serapheim Dimitropoulos <serapheim@delphix.com>).
mahrens committed rG1ba4f3e7b4e1: 9072 handle error of zap_cursor_retrieve() for log spacemap zap (authored by Serapheim Dimitropoulos <serapheim@delphix.com>).
mahrens committed rG48be0dfba19f: lockdep false positive - move txg_kick() outside of ->dp_lock (authored by jdike <52420226+jdike@users.noreply.github.com>).
mahrens committed rGa6c82894735a: install path fixes (authored by Michael Niewöhner <c0d3z3r0@users.noreply.github.com>).
mahrens committed rG2fcf4481a6f6: mismerged log spacemap comment for metaslab_verify_weight_and_frag (authored by Serapheim Dimitropoulos <serapheim@delphix.com>).
mahrens committed rG85ce79bbc8cf: Increase default zcmd allocation to 256K (authored by Michael Niewöhner <c0d3z3r0@users.noreply.github.com>).
mahrens committed rGd8d418ff0cc9: ZVOLs should not be allowed to have children (authored by loli10K <loli10K@users.noreply.github.com>).
mahrens committed rG4417096956f7: Pool allocation classes misplacing small file blocks (authored by loli10K <loli10K@users.noreply.github.com>).
mahrens committed rG779a6c0bf6df: deadlock between mm_sem and tx assign in zfs_write() and page fault (authored by ilbsmart <wgqimut@gmail.com>).
Aug 26 2020
Aug 26 2020
mahrens added a comment to D26196: Fix -Werror,-Wmacro-redefined when building with CROSS_TOOLCHAIN=llvm10.
mahrens added a comment to D26196: Fix -Werror,-Wmacro-redefined when building with CROSS_TOOLCHAIN=llvm10.
Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?
Could we change the contrib files upstream (OpenZFS), rather than maintaining the diffs?
Sep 25 2019
Sep 25 2019
the interfaces look good to me.
Jun 11 2018
Jun 11 2018
Apr 18 2018
Apr 18 2018
Apr 17 2018
Apr 17 2018
Thanks!
Dec 5 2017
Dec 5 2017
So you only have one new compression value in the BP? Have you looked at how this interacts with L2ARC when compressed ARC is disabled? See arc_cksum_is_equal(), I don't think this will work right, because you won't be able to reproduce the on-disk compressed data without knowing the compression level.
Sep 20 2017
Sep 20 2017
@seanc OpenZFS/illumos has been at 4K chunk size since ABD was introduced. I'm not aware of any discussion around changing that.
Sep 17 2017
Sep 17 2017
FYI - we use 1K ABD chunks at Delphix (on illumos), and we've found that up to 40% of memory can end up being wasted because of memory fragmentation. At least on illumos, the 1K ABD kmem cache will use slab size 4K (one page), so there are 4 chunks per slab. After eviction, we may have many partially-full slabs, which wastes the free chunks. We are considering implementing a kmem_move callback which would allow the free chunks to be consolidated, reducing the potential for memory waste. But it isn't done yet.
Jul 19 2016
Jul 19 2016
Jun 13 2016
Jun 13 2016
Dec 23 2015
Dec 23 2015
looks good. Happy to have this upstream too.
Nov 10 2015
Nov 10 2015
You can use the instructions here: https://github.com/openzfs/openzfs to submit a pull request and get regression tests. Then solicit code reviews to developer@lists.illumos.org.
Nov 2 2015
Nov 2 2015
What is the use case for this? AFAIK it isn't possible to create all those holds with one zfs command (there's just "zfs holds -r <snapshot>" which creates a hold on one snapshot per filesystem.
Oct 25 2015
Oct 25 2015
mahrens added inline comments to D3994: Extend 'zfs holds -r' to accept a dataset, instead of only a snapshot as input.
Oct 24 2015
Oct 24 2015
mahrens added a comment to D3994: Extend 'zfs holds -r' to accept a dataset, instead of only a snapshot as input.
This is a good start, but you also need to update the manpage and help message (see get_usage()).
Jun 20 2015
Jun 20 2015
Jun 18 2015
Jun 18 2015
Looks fine to me. FWIW, illumos appears to have flsll() in userland but not kernel. It's implemented similarly to highbit().
Jun 11 2015
Jun 11 2015
Jun 10 2015
Jun 10 2015
Mar 15 2015
Mar 15 2015
Aug 7 2014
Aug 7 2014
Jul 24 2014
Jul 24 2014