Now contains the send/recv fixes from ZOL. Please test.
--
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/124#issuecomment-324526413
--
@lundman pushed 1 commit.
57291b0 de-linting
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/124/files/8e2c3b855a7eb155744586ec610d642c2c46a5c9..57291b074f93cd588106df1a5c0147778c600c6e
ahrens approved this pull request.
It would be nice to clean up DBUF_IS_L2CACHEABLE so that the logic isn't
duplicated with DBUF_IS_L2CACHEABLE_IMPL, but I won't make that a requirement.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
> l2arc_noprefetch=0 is useless because prefetched buffers are not
> ARC_FLAG_L2CACHE flagged
If a buffer is prefetched but not hit, it will not be L2ARC eligible, because
it will not be flagged accordingly, so l2arc_noprefetch=0 has no effect on this
buffer here
I agree; I'll accept this PR
Given no interest in reviewing this, I'm going to close the PR and try to RTI
this as is.
--
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/416#issuecomment-324478316
Closed #416.
--
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/416#event-1218744542
--
openzfs-developer
Archives:
ahrens commented on this pull request.
> @@ -347,6 +347,12 @@ boolean_t dbuf_is_metadata(dmu_buf_impl_t *db);
(dbuf_is_metadata(_db) && \
((_db)->db_objset->os_secondary_cache == ZFS_CACHE_METADATA)))
I guess that doesn't really work (it
Closed #189.
--
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/189#event-1218736634
--
openzfs-developer
Archives:
I'm not convinced that people are "used to the fact that this command blindly
zeroes 512KiB at the beginning and the end of the disk". I think that this
command is seldom-used, and when it's used it's for the documented purpose:
"Removes ZFS label information." That said, I'm open to evidence
ahrens commented on this pull request.
/*
* All forms of zfs create (create, mkdir, mkxattrdir, symlink)
* eventually end up in zfs_mknode(), which assigns the object's
-* creation time and generation number. The generic VOP_CREATE()
-* doesn't have
Problem
The current implementation of zil_commit() can introduce significant
latency, beyond what is inherent due to the latency of the underlying
storage. The additional latency comes from two main problems:
1. When there's outstanding ZIL blocks being written (i.e. there's
already a
Closed #421.
--
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/421#event-1218292532
--
openzfs-developer
Archives:
Good news (at least for this change !), thank you @prakashsurya
--
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/189#issuecomment-324371112
--
@benrubson I don't think that failure is due to this change; rather, think that
failure is due to a prior commit:
https://github.com/openzfs/openzfs/commit/d28671a3b094af696bea87f52272d4c4d89321c7
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
grwilson commented on this pull request.
There are lots of good comments in the pull request that aren't referenced in
the actual code. It would be good to incorporate some of these as comments.
/*
* All forms of zfs create (create, mkdir, mkxattrdir, symlink)
*
@ahrens Hi Matthew, what do you think about my previous comments ? Can we leave
the default options as they are ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Test passed, thank you for having launched it @prakashsurya
I'm pretty convinced prefetched buffers should be `ARC_FLAG_L2CACHE` flagged
(what this PR currently does), as `l2arc_noprefetch` user tunable will then
control whether or not these buffers can be L2 backed.
This gives a nice
17 matches
Mail list logo
