[developer] used > 0 || dsl_dir_phys(dd)->dd_used_breakdown[type] >= -used

provide any additional data that can be queried from the pool and from the crash dump. -- Andriy Gapon --- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce

Re: [developer] spa_namespace_lock vs sync thread

fficiently exercise their code to make sure > they don't violate this. > > Have you seen instances where we deadlock as a result of this? > > Thanks, > George > > On Fri, Jul 8, 2016 at 9:40 AM, Andriy Gapon <mailto:a...@freebsd.org>> wrote: > > >

[developer] spa_namespace_lock vs sync thread

ock. Is this a real rule? Do we always honor it? Thank you! -- Andriy Gapon --- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subs

Re: [developer] panic: solaris assert: ba.ba_phys->bt_bytes == 0 (0x400 == 0x0)

y more with full list > of zfs tests, what availabe on illumos tree. > > best regards, > -Igor > > >> On Jun 22, 2016, at 5:17 PM, Andriy Gapon > <mailto:a...@freebsd.org>> wrote: >> >> >> I am not yet convinced that the problem has anything to

[developer] metaslab_free_dva: "allocating allocated segment" panic

8770}, io_trim_node = { avl_child = 0xf800295b8b00, avl_pcb = 0}, io_trim_link = {list_next = 0x0, list_prev = 0x0}} -- Andriy Gapon --- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/me

Re: [developer] panic: solaris assert: ba.ba_phys->bt_bytes == 0 (0x400 == 0x0)

have no experience with clang. > > best regards, > -Igor > > >> On Jun 22, 2016, at 4:21 PM, Andriy Gapon > <mailto:a...@freebsd.org>> wrote: >> >> >> I am getting the following panic using the latest FreeBSD head that is >> synchronized wit

[developer] panic: solaris assert: ba.ba_phys->bt_bytes == 0 (0x400 == 0x0)

load, but I do not have a concise reproduction scenario. Every time the panic happens bt_bytes is 0x400, I haven't seen any other number there. Does anyone have an idea what could be causing this? I can try any diagnostic code that might shed more light. Thank

Re: [developer] [openzfs/openzfs] 6939 add sysevents to zfs core for commands (#101)

On 03/05/2016 19:31, Garrett D'Amore wrote: > 1. Will sysevents in the core create challenges for portability to other OS? > (Matt? Andriy? Brian?) It seems like in FreeBSD we already have a compatibility shim for sysevents, at least log_sysevent. -- A

[developer] review request: 5380 call recv_incremental_replication only for recusrive streams

https://reviews.csiden.org/r/269/ https://www.illumos.org/issues/5380 Thanks! -- Andriy Gapon --- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062

[developer] Re: Review Request 257: libzfs_core: remove the dependency of the interface on sys/fs/zfs.h

> On Nov. 10, 2015, 11:29 p.m., Matthew Ahrens wrote: > > Do you want to open a pull request for this to get the automated testing? > > Andriy Gapon wrote: > I am in the process of setting up a ZFS test suite environment locally. > I'll try to test this change in

Re: [OpenZFS Developer] Review Request 141: zfs send -p -I: send properties only for snapshots that are actually sent

> On Feb. 15, 2015, 2:29 p.m., Andriy Gapon wrote: > > usr/src/lib/libzfs/common/libzfs_sendrecv.c, line 628 > > <https://reviews.csiden.org/r/141/diff/1/?file=11927#file11927line628> > > > > As @dweeezil correctly noted this simple solution breaks several

Re: [OpenZFS Developer] [openzfs] 6404, 6405 zvol test suite fixes (#27)

> @@ -51,7 +51,7 @@ typeset -i min max mem > ((min = 2 * 1024 * 1024 * 1024)) > ((max = 16 * 1024 * 1024 * 1024)) > > -for vbs in 512 1024 2048 4096 8192 16384 32768 65536 131072; do > +for vbs in 8192 16384 32768 65536 131072; do > for multiplier in 1 32 16384 131072; do >

Re: [OpenZFS Developer] [openzfs] 6404, 6405 zvol test suite fixes (#27)

> @@ -51,7 +51,7 @@ typeset -i min max mem > ((min = 2 * 1024 * 1024 * 1024)) > ((max = 16 * 1024 * 1024 * 1024)) > > -for vbs in 512 1024 2048 4096 8192 16384 32768 65536 131072; do > +for vbs in 8192 16384 32768 65536 131072; do > for multiplier in 1 32 16384 131072; do >

Re: [OpenZFS Developer] Review Request 257: libzfs_core: remove the dependency of the interface on sys/fs/zfs.h

> On Nov. 10, 2015, 11:29 p.m., Matthew Ahrens wrote: > > Do you want to open a pull request for this to get the automated testing? > > Andriy Gapon wrote: > I am in the process of setting up a ZFS test suite environment locally. > I'll try to test this change in

Re: [OpenZFS Developer] Review Request 257: libzfs_core: remove the dependency of the interface on sys/fs/zfs.h

Diff: https://reviews.csiden.org/r/257/diff/ Testing --- Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] [openzfs] Properly handle updates of variably-sized SA entries. (#24)

@ahrens, @behlendorf, I've tested my proposed code on FreeBSD and I am going to test it on ZoL. BTW, the diff against the current ZoL code is not that dramatic: ClusterHQ/zfs@aef0142ffe7d280ba32a7d97a7f83cf52cd03514 I'd even dare to say that it is trivial / cosmetic. --- Reply to this email direc

[OpenZFS Developer] [openzfs] 5778 nvpair_type_is_array() does not recognize DATA_TYPE_INT8_ARRAY (#34)

Tested using a trivial program. You can view, comment on, or merge this pull request online at: https://github.com/openzfs/openzfs/pull/34 -- Commit Summary -- * 5778 nvpair_type_is_array() does not recognize DATA_TYPE_INT8_ARRAY -- File Changes -- M usr/src/common/nvpair/nvpair.c (1)

Re: [OpenZFS Developer] [openzfs] Properly handle updates of variably-sized SA entries. (#24)

Following up to my earlier comment regarding `j++` in the `SA_REMOVE` case. As far as I can that code is not present in the latest ZoL, so that bug must have been fixed as a separate ZoL change. --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/24#is

Re: [OpenZFS Developer] [openzfs] 6051 lzc_receive: allow the caller to read the begin record (#30)

@ahrens So far, the only testing of the new function is via the following Python code: https://github.com/ClusterHQ/pyzfs/commit/340f585d100e4e8cca82e620b0d44e7da314e4cb#diff-34194bfc890283f17239b29a5346b088R2416 --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/op

Re: [OpenZFS Developer] [openzfs] 6051 lzc_receive: allow the caller to read the begin record (#30)

> @@ -548,8 +548,9 @@ recv_read(int fd, void *buf, int ilen) > } > > static int > -lzc_receive_impl(const char *snapname, nvlist_t *props, const char *origin, > -boolean_t force, boolean_t resumable, int fd) > +recv_impl(const char *snapname, nvlist_t *props, const char *origin, I renamed

Re: [OpenZFS Developer] [openzfs] 6051 lzc_receive: allow the caller to read the begin record (#30)

@ahrens I've updated the code. --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/30#issuecomment-153418653___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] [openzfs] Fix gcc warnings (#5)

@allanjude if you need any help with that, just let me know - I have OI Hipster running on bhyve --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/5#issuecomment-153180402___ developer mailing list developer@

Re: [OpenZFS Developer] [openzfs] sa_find_sizes() may compute wrong SA header size (#14)

This pull request as well #24 present an interesting challenge. In order to verify that they do the right thing on illumos it would be nice to reproduce the problems that they fix and then to verify that the problems are indeed fixed. But illumos does not support `xattr=sa` (seems to be ZoL

Re: [OpenZFS Developer] [openzfs] Properly handle updates of variably-sized SA entries. (#24)

This is what I have in mind: avg-I/openzfs@61e95060c4cd009e56f3034b0cdc7624ced3217b --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/24#issuecomment-152715803___ developer mailing list developer@open-zfs.org

Re: [OpenZFS Developer] [openzfs] 6051 lzc_receive: allow the caller to read the begin record (#30)

> @@ -594,9 +595,14 @@ lzc_receive_impl(const char *snapname, nvlist_t *props, > const char *origin, > (void) strlcpy(zc.zc_string, origin, sizeof (zc.zc_string)); > > /* zc_begin_record is non-byteswapped BEGIN record */ > - error = recv_read(fd, &zc.zc_begin_record, siz

Re: [OpenZFS Developer] [openzfs] 5752 dump_nvlist() is not aware of boolean array (#20)

@ahrens I would like it to be I am juggling commits between multiple repositories with different configuration, sometimes that leads to confusions. --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/20#issuecomment-152715681

Re: [OpenZFS Developer] [openzfs] Properly handle updates of variably-sized SA entries. (#24)

@trisk As an author of the FreeBSD change I see the following pluses in it. It improves the description for `sa_modify_attrs`. The code restructuring allows to increment `length_idx` in only one place under a very clear condition. Compare that to the ZoL change where the increment is done in tw

[OpenZFS Developer] [openzfs] 6051 lzc_receive: allow the caller to read the begin record (#30)

The begin record contains useful information that the caller might want to have the access to, so that it can be used to derive values for 'snapname' and 'origin' parameters. New lzc_receive_with_header function is added. Review request on the reviewboard: https://reviews.csiden.org/r/256/ An exam

Re: [OpenZFS Developer] Review Request 256: lzc_receive: allow the caller to read the begin record

views.csiden.org/r/256/#review851 --- On Oct. 30, 2015, 12:54 p.m., Andriy Gapon wrote: > > --- > This is an automatically generated e-mail. To reply,

Re: [OpenZFS Developer] [openzfs] 6385 Fix unlocking order in zfs_zget() (#6)

@ahrens yes. --- Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/6#issuecomment-152092710___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] pyzfs: python wrapper for libzfs_core

ore extensions that we are submitting for review separately. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] [openzfs] sa_find_sizes() may compute wrong SA header size (#14)

I think that the problem fixed by this change is still present in FreeBSD as well as in illumos. The fix looks good to me. I think that the problem that it solves is that the current code stops adding to `hdrsize` once we get into the trailing `blkptr_t`-sized area. So, if we (almost) fill the

[OpenZFS Developer] [openzfs] 5752 dump_nvlist() is not aware of boolean array (#20)

Issue: https://www.illumos.org/issues/5752 FreeBSD commit: https://svnweb.freebsd.org/base?view=revision&revision=282121 You can view, comment on, or merge this pull request online at: https://github.com/openzfs/openzfs/pull/20 -- Commit Summary -- * 5752 dump_nvlist() is not aware of boolea

Re: [OpenZFS Developer] avl_is_empty(&dn->dn_dbufs) assert in dnode_sync_free

e(ff014c2c, 233d6) ff0004819c20 txg_sync_thread+0x260(ff01495d7e80) ff0004819c30 thread_start+8() On 28/09/2015 17:25, Andriy Gapon wrote: > > There are several reports from FreeBSD users about getting a panic because of > avl_is_empty(&dn->dn_dbufs) assertion

Re: [OpenZFS Developer] zfs receive: -u can be ignored sometimes

So, should I open a bug report about this? On 21/10/2015 16:25, Andriy Gapon wrote: > On 21/10/2015 16:08, Andriy Gapon wrote: >> >> It seems that zfs receive -F -u would mount a received filesystem after >> receiving a full stream if a destination filesystem already e

Re: [OpenZFS Developer] Review Request 256: lzc_receive: allow the caller to read the begin record

his is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/256/#review825 --- On Oct. 9, 2015, 11:55 a.m., Andriy Gapon wrote: > > --- > This i

Re: [OpenZFS Developer] Review Request 256: lzc_receive: allow the caller to read the begin record

-- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/256/#review825 --- On Oct. 9, 2015, 11:55 a.m., Andriy Gapon wrote: > >

Re: [OpenZFS Developer] zfs receive: -u can be ignored sometimes

On 21/10/2015 16:08, Andriy Gapon wrote: > > It seems that zfs receive -F -u would mount a received filesystem after > receiving a full stream if a destination filesystem already existed (and, > thus, > got destroyed and re-created) and was mounted. > Is this a bug? >

[OpenZFS Developer] zfs receive: -u can be ignored sometimes

? [*] [*] As it is now, the interaction of -F and receiving a full stream is not documented at all. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Review Request 257: libzfs_core: remove the dependency of the interface on sys/fs/zfs.h

bdd6c951ee496dc1e21a297e7a69b1342aecf79b Diff: https://reviews.csiden.org/r/257/diff/ Testing --- Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Review Request 256: lzc_receive: allow the caller to read the begin record

ecf79b Diff: https://reviews.csiden.org/r/256/diff/ Testing --- Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] Review Request 255: 6295 metaslab_condense's dbgmsg should include vdev id

--- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/255/#review812 --- Ship it! Looks good. - Andriy Gapon On Oct. 7, 2015, 7:38 a.m

Re: [OpenZFS Developer] Review Request 250: DLPX-37488 exporting a pool while an async destroy is running can leave entries in the deferred tree

--- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/250/#review811 --- Ship it! Looks good to me. - Andriy Gapon On Oct. 7, 2015, 6:02 a.m

Re: [OpenZFS Developer] Review Request 247: 6286 ZFS internal error when set large block on bootfs

--- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/247/#review810 --- Ship it! Looks god to me. - Andriy Gapon On Oct. 6, 2015, 6:56 p.m

Re: [OpenZFS Developer] Review Request 245: 6267 dn_bonus evicted too early

o, as far as our testing and workloads go, I do not see any regressions. - Andriy Gapon On Oct. 6, 2015, 9:39 p.m., Justin Gibbs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews

Re: [OpenZFS Developer] Review Request 240: 2605 want to resume interrupted zfs send

tps://reviews.csiden.org/r/240/#comment595> Since `zfs_send_resume_token_to_nvlist` is a non-trivial function, perhaps split the defintion and initialization of `resume_nvl`? - Andriy Gapon On Sept. 23, 2015, 6:48 p.m., Matthew Ahrens

[OpenZFS Developer] avl_is_empty(&dn->dn_dbufs) assert in dnode_sync_free

ituation is harmless and the assertion can be removed. I agree with him. But on the other hand, I wonder if something could be done in the DSL to avoid the described situation. I mean, it seems that bpo_cached_dbuf is a rare (the only?) case where a dbuf can be held beyon

Re: [OpenZFS Developer] lzc_receive: add a possibility to take the snapshot name from the stream

On 11/08/2015 20:54, Matthew Ahrens wrote: > On Fri, Aug 7, 2015 at 7:18 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > Your proposal seems like a more flexible approach. One thing that bothers > me a > little bit is that every consumer of t

Re: [OpenZFS Developer] cache device sharing

ent l2arc which never > fails over but can be added to multiple pools. It would not be a trivial > implementation but seems doable. Well, given that the cache device has just a cache of data it can easily follow its pool by simply discarding the cached data. Loss of a cache device is harmless

Re: [OpenZFS Developer] cache device sharing

nd level caching of data from any pool. > On Fri, Sep 11, 2015 at 7:23 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > I am curious what was the original reason to not allow sharing of cache > devices > (L2ARC) between pools? > Aft

[OpenZFS Developer] cache device sharing

pools can be cached on this pool's cache devices. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] Review Request 232: lzc_receive: add a possibility to take the snapshot name from the stream

st and I will create a new one for the approach that you suggested. - Andriy --- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/232/#review761 ------

Re: [OpenZFS Developer] Review Request 229: account for ashift when choosing buffers to be written to l2arc device

it: https://reviews.csiden.org/r/229/#review754 --- On June 25, 2015, 3:34 p.m., Andriy Gapon wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https

Re: [OpenZFS Developer] lzc_receive: add a possibility to take the snapshot name from the stream

t; > > --matt > > On Fri, Jul 3, 2015 at 10:46 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > Currently lzc_receive() requires that its 'snapname' argument is a > snapshot name > (contains '@'). zfs receive a

Re: [OpenZFS Developer] zfs_ioc_snapshot_list_next: ENOENT -> ESRCH

ean some different error, but I > don't see what. I'd be open to changing this if that's your thinking. > > --matt > > On Thu, Jul 2, 2015 at 11:02 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > zfs_ioc_snapshot_list_next() con

Re: [OpenZFS Developer] lzc_receive: add a possibility to take the snapshot name from the stream

On 03/07/2015 20:46, Andriy Gapon wrote: > > Currently lzc_receive() requires that its 'snapname' argument is a snapshot > name > (contains '@'). zfs receive allows to specify just a dataset name and would > try > to deduce the snapshot name from the s

[OpenZFS Developer] lzc_receive: add a possibility to take the snapshot name from the stream

c_begin_record.drr_toname, '@'); + if (atp == NULL) + return (EINVAL); + if (strlen(zc.zc_value) + strlen(atp) >= sizeof(zc.zc_value)) + return (ENAMETOOLONG); + strcat(zc.zc_value, atp); + } + /*

[OpenZFS Developer] listing things

e not ideal from the points of view of the performance and the memory requirements. I think that a more balanced and universal approach could be to get entries via the iteration but with getting more than one entry per an iteration if the allocated memory allows that. Just thinking out loud... -- A

[OpenZFS Developer] zfs_ioc_snapshot_list_next: ENOENT -> ESRCH

I wonder what is the reason for that? Thanks! -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Interesting ZoL commits

/7290cd3c4ed19fb3f75b8133db2e36afcdd24beb And I find the following feature to be a nice addition: Zdb should be able to open the root dataset https://github.com/zfsonlinux/zfs/commit/b1b85c8772ed28d2c8227e6d32905740817ae2c3 -- Andriy Gapon

[OpenZFS Developer] Review Request 229: account for ashift when choosing buffers to be written to l2arc device

iff: https://reviews.csiden.org/r/229/diff/ Testing --- FreeBSD only. Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] Review Request 112: account for ashift when choosing buffers to be written to l2arc device

> On April 9, 2015, 4:04 a.m., Bayard Bell wrote: > > usr/src/uts/common/fs/zfs/arc.c, line 4740 > > > > > > Nit: generally following Matt's general philosophy of helping the > > compiler be our friend for safety, if we

Re: [OpenZFS Developer] Review Request 228: 5984 zfs clone should not mount the clone if canmount == noauto

in `zfs_do_clone()` similar to those in `zfs_do_create()`. Diffs (updated) - usr/src/cmd/zfs/zfs_main.c ff04e3a1c6e32918aa6a93aa184942f5511e3bec Diff: https://reviews.csiden.org/r/228/diff/ Testing --- `zfs clone -o canmount=noauto` on FreeBSD. Thanks, Andriy Gapon

Re: [OpenZFS Developer] automatically mount a clone iff canmount == on

On 03/06/2015 18:54, Andriy Gapon wrote: > > I found line wrapping that resulted from deep nesting to be quite unpleasing > aesthetically, so I did a little bit more work than a minimal patch would > require: > https://gist.github.com/avg-I/d38f670b8a86613fa458 > > Could y

Re: [OpenZFS Developer] automatically mount a clone iff canmount == on

at > check once. e.g.: > > if (prop_valid_for_type(CANMOUNT)) { > if (prop_get_init(CANMOUNT) == ON)) { > zfs_mount() > } > } > > On Mon, May 25, 2015 at 11:06 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > ZoL has the

Re: [OpenZFS Developer] Temporary in-core DSL Pool metadata snapshots

ting over directory entries (e.g. if a file/directory is concurrently > renamed, "find" can list it 0, 1, or 2 times). Concurrent renames are pretty > difficult to deal with. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] Review Request 225: 5946 zfs_ioc_space_snaps: check that firstsnap and lastsnap are snapshots

ode. Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Review Request 225: 5946 zfs_ioc_space_snaps: check that firstsnap and lastsnap are snapshots

e4abdc325428189825507b76570b9e89c2578868 Diff: https://reviews.csiden.org/r/225/diff/ Testing --- ZFS/FreeBSD with DEBUG-enabled ZFS code. Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo

[OpenZFS Developer] automatically mount a clone iff canmount == on

ZoL has the following change: https://github.com/FransUrbo/zfs/commit/dd0e0e69f5b1c83bf2895ac00a0b83af77473175 https://github.com/zfsonlinux/zfs/issues/2241 I think that that change is correct, because creating a clone does not imply a wish to mount it. What do you think? -- Andriy Gapon

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 06/05/2015 02:29, Matthew Ahrens wrote: > > > On Fri, Apr 24, 2015 at 6:29 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > BTW, there is another boundary case for zfs_ioc_recv(). > If the desired destination snapshot already exists t

Re: [OpenZFS Developer] Review Request 220: 5912 full stream can not be force-received into a dataset if it has a snapshot

den option perhaps? - Andriy --- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/220/#review690 --- On May 6, 2015,

Re: [OpenZFS Developer] DS_FLAG_NOPROMOTE

not need to track (in the deadlists) blocks that were > born before the origin. Sounds cool! Thanks for the heads-up. > On Wed, May 6, 2015 at 5:27 AM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > > DS_FLAG_NOPROMOTE seems to be a read-only flag. That i

[OpenZFS Developer] DS_FLAG_NOPROMOTE

DS_FLAG_NOPROMOTE seems to be a read-only flag. That is, it's checked in two places, but it is never set. Is this some left-over that can be cleaned up? -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zf

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

e. > Thank you! BTW, I have a test case for this scenario in our lzc python wrapper. Perhaps it would be worthwhile converting some of our tests to ztest test, but maybe that won't be necessary once we publicly release the code and the test

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

[ping] I would like to get a preliminary review for the change suggested below . Or should I rather open an issue and submit the change for a review via the reviewboard? Thanks! On 24/04/2015 14:38, Andriy Gapon wrote: > On 24/04/2015 02:25, Matthew Ahrens wrote: >> I think that'

[OpenZFS Developer] receiving incremental clone stream without creating clone

am with the clone flag to be received into an existing filesystem (provided that all other things matched) ? -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Review Request 206: 5870 dmu_recv_end_check() leaks origin_head hold if error happens in drc_force branch

u_send.c c4575f8f6dc2453d8483a7e566dafdce2f3f49ff Diff: https://reviews.csiden.org/r/206/diff/ Testing --- FreeBSD-only, using libzfs_core. Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

EEXIST -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] zfs_rezget() succeeds even when IFTOVT(z_mode) changes

ys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c#1330 -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] z_root change after recv -F

https://www.illumos.org/issues/5867 > On Thu, Apr 23, 2015 at 5:00 AM, Andriy Gapon > wrote: > > > A semi-theoretical question: can z_root - or, to be correct, ZFS_ROOT_OBJ > - > value change after a filesystem has its content replaced by zfs recv -F > of a

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

do not have a strong opinion about the return code. EEXIST makes sense to me, but possibly some other code like ENODEV or ETXTBUSY makes even more sense. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

On 24/04/2015 00:00, Matthew Ahrens wrote: > On Thu, Apr 23, 2015 at 1:24 PM, Andriy Gapon > wrote: > It seems that any filesystem is considered modified when compared to > $ORIGIN. > And ds_prev of a filesystem without any real snapshots points to $ORIGIN. >

Re: [OpenZFS Developer] receiving non-incremental stream into existing fs

f a target filesystem. That's a little > bit > confusing since we have a full stream. Maybe it would have better to > return > EEXIST signalling that the target filesystem exists. > > > -- > Paul Dagnelie -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] z_root change after recv -F

well happened because of my playing with the code, but in general the root object does not have a fixed ID. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] libzfs_core and dmu_objset_type_t

Any interest in this topic at all? On 18/03/2015 18:55, Andriy Gapon wrote: > I think that we should try to isolate libzfs_core API and ABI as much as > possible from ZFS implementation details. > In this respect it seems that there is no good reason to use dmu_objset_type_t > wit

[OpenZFS Developer] receiving non-incremental stream into existing fs

e target filesystem exists. -- Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] kernel panic in an edge case of bookmarks creation

n it. > On Mon, Apr 13, 2015 at 11:01 PM, Andriy Gapon <mailto:andriy.ga...@clusterhq.com>> wrote: > > On 14/04/2015 08:04, Andriy Gapon wrote: > > So, I pass the following bookmarks nvlist to lzc_bookmark(): > > { > > "

Re: [OpenZFS Developer] kernel panic in an edge case of bookmarks creation

On 14/04/2015 08:04, Andriy Gapon wrote: > So, I pass the following bookmarks nvlist to lzc_bookmark(): > { > "pool/fs#bookmark": "pool/fs@snap", > "pool/fs#another_bookmark": "pool/fs@snap" > } > > That is, I am trying to

[OpenZFS Developer] kernel panic in an edge case of bookmarks creation

_thread() The panic confuses me a lot, because I couldn't figure out how dsl_dataset_hold could return ENOENT. I only have a guess: I think that the way of how dsl_dataset_zapify() works might cause this. Additional note: the panic happens on FreeBSD, bu

Re: [OpenZFS Developer] Fw: [REVIEW] 5610 zfs clone from different source and target pools produces coredump

ev/alhazred/5610/ >>> <http://cr.illumos.org/%7Ewebrev/alhazred/5610/> >>> >>> Tested with zfs test suite. >>> >>> -- >>> Alexander >> >> > > > Thanks to Andriy for suggestion, > I’ve updat

[OpenZFS Developer] libzfs_core and dmu_objset_type_t

we go for the change then it would present a challenge of its own, because the stable lzc API would have to be modified. What would be the best way to do that? Or does this concern alone kill the whole proposal? Thanks! -- Andriy Gapon ___ developer

Re: [OpenZFS Developer] Review Request 141: zfs send -p -I: send properties only for snapshots that are actually sent

cluded into a full stream produced with zfs send -p pool/ds@snap. Most likely the original performance issue better be fixed at the receiving end. - Andriy Gapon On Dec. 2, 2014, 2:11 p.m., Andriy Gapon wrote: > > ---

Re: [OpenZFS Developer] Review Request 141: zfs send -p -I: send properties only for snapshots that are actually sent

ttps://reviews.csiden.org/r/141/#review393 --- On Dec. 2, 2014, 2:11 p.m., Andriy Gapon wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.csiden.org/r/141/ >

Re: [OpenZFS Developer] Review Request 112: account for ashift when choosing buffers to be written to l2arc device

you! - Andriy --- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/112/#review378 --- On Oct. 8, 2014, 4:57 p.m., And

Re: [OpenZFS Developer] Review Request 128: 5313 Allow I/Os to be aggregated across ZIO priority classes

6d9bcb17d00fd70d1585b9c2218086ca2239aab6 Diff: https://reviews.csiden.org/r/128/diff/ Testing --- Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

[OpenZFS Developer] Review Request 141: zfs send -p -I: send properties only for snapshots that are actually sent

and ZoL. None for illumos. Thanks, Andriy Gapon ___ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer

Re: [OpenZFS Developer] Review Request 129: [5314] Remove "dbuf phys" db->db_data pointer aliases in ZFS

> On Nov. 25, 2014, 1:48 p.m., Andriy Gapon wrote: > > usr/src/uts/common/fs/zfs/sys/dsl_dir.h, line 87 > > <https://reviews.csiden.org/r/129/diff/3/?file=11663#file11663line87> > > > > This change seems to imply that dd_dbuf and dd_pool fields are mutable,

Re: [OpenZFS Developer] Review Request 129: [5314] Remove "dbuf phys" db->db_data pointer aliases in ZFS

/to/, but otherwise looks good to me. - Andriy Gapon On Nov. 21, 2014, 6:38 p.m., Justin Gibbs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.csid

Re: [OpenZFS Developer] Review Request 129: [5314] Remove "dbuf phys" db->db_data pointer aliases in ZFS

instead of the removed fields rather than the accessor functions? If yes, was that considered too dangerous with respect to a potential name clash? - Andriy Gapon On Nov. 21, 2014, 6:38 p.m., Justin Gibbs wrote: > > --- > T

Re: [OpenZFS Developer] Review Request 129: [5314] Remove "dbuf phys" db->db_data pointer aliases in ZFS

g/r/129/#comment301> This change seems to imply that dd_dbuf and dd_pool fields are mutable, are they? - Andriy Gapon On Nov. 21, 2014, 6:38 p.m., Justin Gibbs wrote: > > --- > This is an automatically generated e-mail.

  1   2   >