Here is the fix for:
7304 zfs filesystem/snapshot counts should be read-only
This issue was found by the folks at Delphix and the fix was suggested by
Sara Hartse.
Because this is so simple I have just included the diffs here:
--- a/usr/src/common/zfs/zfs_prop.c
+++ b/usr/src/common/zfs/zfs_prop
Matt,
Yes, I'll move them.
Thanks,
Jerry
On Wed, Aug 17, 2016 at 2:30 PM, Matthew Ahrens wrote:
> This looks good, can you also move these readonly props to the section
> above, labeled /* readonly number properties */.
>
> --matt
>
> On Tue, Aug 16, 2016 at 5:45 AM,
This is the diff I've tested within an lx-branded zone with a delegated
dataset. Running "/native/usr/sbin/zfs mount -a" now works.
--- a/usr/src/lib/libzfs/common/libzfs_mount.c
+++ b/usr/src/lib/libzfs/common/libzfs_mount.c
@@ -662,8 +663,9 @@ _zfs_init_libshare(void)
static int
zfs_init_libs
I just opened the following bug on illumos:
https://www.illumos.org/issues/8574
I don't have enough zfs knowledge to know if the fix we had been using for
this bug prior to the integration of illumos#3821 is the best way forward
here, or if there is something better.
I'd be interested to hear any
IL
> operations (that was the original motivation for the change). It'd be great
> to get some additional testing from others before submitting the RTI to get
> it into illumos/openzfs.
>
> On Fri, Aug 11, 2017 at 6:14 AM, Jerry Jelinek
> wrote:
>
>> I just opened th
Is it intentional that ZFS does not read from a hot spare under a mirror,
even after the resilver has completed?
We have observed this behavior and I spent some time digging into it. Here
is an example of the zpool status once the resilver has completed:
NAME STATE READ WRITE
* attempt to free them up now so that they can be used
Thanks,
Jerry
On Thu, Jul 5, 2018 at 10:29 AM, Jerry Jelinek
wrote:
> Is it intentional that ZFS does not read from a hot spare under a mirror,
> even after the resilver has completed?
>
> We have observed this be
Hi Matt,
We didn't get to the new trim work today, but you could put my name down
for that. I have the original Nexenta code ported to the latest illumos
code and basic testing is done. It is out for internal CR at Joyent and I
could send out a pointer for general CR.
Thanks,
Jerry
On Tue, Oct
I have taken the Nexenta TRIM work that was originally out for code review
last year and updated it to work with the latest version of ZFS. The code
passes the new trim tests and I have done some additional manual testing
with DTrace to verify that the trim requests pass down into the scsi driver
a
The changes at https://cr.joyent.us/#/c/4929 do not include everything from the
original PR. The driver changes to support unmap were split out into a separate
commit and those have already integrated into illumos as commit 047c81d31. The
current set of changes is the rest of the changes for TRI
umos-joyent tree for cherry-pick ?
>
> -Igor
>
>
> On Oct 10, 2018, at 7:26 PM, Jerry Jelinek
> wrote:
>
> I have taken the Nexenta TRIM work that was originally out for code review
> last year and updated it to work with the latest version of ZFS. The code
> passes the new
ating trim segments across multiple TXG's). It would be good to
> verify that this complexity is worth it.
>
> --matt
>
> On Wed, Oct 10, 2018 at 9:27 AM Jerry Jelinek
> wrote:
>
>> I have taken the Nexenta TRIM work that was originally out for code
>> review
would be good to
> verify that this complexity is worth it.
>
> --matt
>
> On Wed, Oct 10, 2018 at 9:27 AM Jerry Jelinek
> wrote:
>
>> I have taken the Nexenta TRIM work that was originally out for code
>> review last year and updated it to work with the latest
e is still interest or if there are any other issues that
I can try to address.
Thanks,
Jerry
On Mon, Oct 22, 2018 at 11:30 AM Jerry Jelinek
wrote:
> I have merged all of the patches from last years openzfs pull request and
> ported that code to the latest version of zfs. There were two si
This is a fix for a performance problem we've hit at Joyent.
https://us-east.manta.joyent.com/jjelinek/public/webrevs/10221/index.html
Thanks,
Jerry
--
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/Te98a45cd38e36a58-M
t; -Igor
>
> On Jan 11, 2019, at 8:04 PM, Jerry Jelinek
> wrote:
>
> This is a fix for a performance problem we've hit at Joyent.
>
> https://us-east.manta.joyent.com/jjelinek/public/webrevs/10221/index.html
>
> Thanks,
> Jerry
>
>
> *openzfs <h
d() rather than having
> the callers do it?
>
Originally I was thinking that we would only set this when we knew the txg,
which is related to your previous question. However, now I think it is
cleaner to set it in metaslab_load and I could simply pass 0 for the call
path which doesn't
This is a fix for a problem we found with a syscall fuzzer.
https://us-east.manta.joyent.com/jjelinek/public/webrevs/10230/index.html
Thanks,
Jerry
--
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/Tdb8ec7781d11ac91-M4
I’m also surprised to see someone else fuzzing on illumos. What tool are
> you using?
>
> - Andy.
>
> > On 14 Jan 2019, at 14:46, Jerry Jelinek
> wrote:
> >
> > This is a fix for a problem we found with a syscall fuzzer.
> >
> >
> https://us-east.
This is a ZFS fix for missing ioctl log entries in dbgmsg. I could modify
the exact ioctl information being logged if anyone has suggestions for
something different.
https://us-east.manta.joyent.com/jjelinek/public/webrevs/10276/index.html
Thanks,
Jerry
--
In the openzfs meeting today, the topic of ZoL portability issues was
raised. Since I've been porting a lot of the ZoL work back to illumos, I
have some notes on a few different things I've run into.
- Code uses a Linux errno (EREMOTEIO) that is not available in illumos
kernel.
- SPL cv_timedwait
21 matches
Mail list logo
