Lots of good info here. I've copied Matt's reply to the project page on the
open-zfs wiki: http://open-zfs.org/wiki/Projects#Sorted_Scrub
On Sat, Jul 9, 2016 at 2:24 PM, Matthew Ahrens wrote:
> We had an intern work on "sorted scrub" last year. Essentially the idea
> was to read the metadata to
:+1: LGTM. I agree, constructs like that always confuse me.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/66#issuecomment-182008121___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.or
@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/56#issuecomment-173937993___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/56#issuecomment-171836010___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/57#issuecomment-171732006___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/51#issuecomment-170807104___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
It looks like this failed the regression tests in the recent runs:
1. http://build.prakashsurya.com:8080/job/openzfs-regression-tests/138/
2. http://build.prakashsurya.com:8080/job/openzfs-regression-tests/140/
To help with debugging these failures, I've tar-ed up the workspace of the
ztest fail
@ahrens I've opened an illumos bug for this here:
https://www.illumos.org/issues/6531 .. Additionally, I've updated the title of
this pull request, but you'll have to make sure to manually update the commit
message before landing this.
---
Reply to this email directly or view it on GitHub:
http
On Fri, Dec 18, 2015 at 10:41 AM, Matthew Ahrens
wrote:
> I have 2 outstanding review requests that I could use feedback on. These
> have been open for quite a while so I'm probably going to RTI them this
> weekend.
>
> Provide mechanism to artificially limit disk performance
> https://github.co
@zettabot go
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/47#issuecomment-165751107___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
sure thing, this is on my laptop with ZFS on Linux installed:
# zfs create -o compress=off -o dedup=off zfs/foo
# dd if=/dev/urandom of=/zfs/foo/bar bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 7.60125 s, 13.8 MB/s
# dd if=/dev/ur
@avg-I do you think the "trivial program" you used to test this change would be
useful to incorporate into the test suite?
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/34#issuecomment-156212917___
develo
LGTM!
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/34#issuecomment-156196743___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
Would it make sense to include this description in the commit message of
the proposed patch? It looks like we're allowing more detailed commit
messages in the openzfs repository, so I'd vote to include this explanation
along with the diff.
Cheers,
Prakash
On Tue, Nov 10, 2015 at 7:07 PM, Matthew
Sweet, I'm on board with moving the OpenZFS build slaves over to OmniOS
r151016 and use the new process.
I won't be able to make that shift immediately, given some other things on
my plate, but I opened a bug to
make sure I don't forget: https://github.com/openzfs/openzfs-build/issues/22
Thanks f
> You mention that the diffs may be slightly different by the time they land in
> illumos. Lets say that for a certain patch, the OpenZFS group approves it as
> it is tn the GH PR. Then when it goes to illumos for RTI, they would prefer
> an ASSERT be added. Weeks later after the next illumos me
The current strategy we've decided on, to keep us in sync with illumos,
is to merge in changes from illumos into the OpenZFS repo on a recurring
basis (daily, weekly, monthly, w/e). Thus, the current work flow looks a
bit like this:
Closed #15 via 1fca7708f413485fdb627167c79743ae69764c78.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/15#event-452263463___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/
@ahrens I opened an illumos bug for this, but never circled back to updating
this issue with that bug: https://www.illumos.org/issues/6371
Should I update this pull request with the correct illumos bug and reviewers,
or would you like to go ahead and do that?
---
Reply to this email directly or
I'm not sure off the top of my head, but we're building on a stock OmniOS
r151014 image using this script:
https://github.com/openzfs/openzfs-build/blob/master/ansible/roles/openzfs-jenkins-slave/files/usr/local/build-os.sh
Any configuration of the OmniOS image (e.g. packages installed) can also
@ahrens do you think we should open bugs in the openzfs-build repo to track
these failures?
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/28#issuecomment-152584626___
developer mailing list
developer@open
oh, that's interesting.. the build for this pull request in queued waiting for
prior jobs to finish. so it doesn't have a `BUILD_NUMBER` yet, which is
probably why the variable `$BUILD_NUMBER` leaked through instead of the actual
value (since there is not value yet). Sounds like a Jenkins bug, b
ugh, that's obviously broken. thanks for the heads up.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/26#issuecomment-152043611___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mai
And re-reading @wca comment, that might actually be exactly what was suggested.
I just didn't make the jump from having a "illumos-6403-final" to "opening a
new pull request", but I don't see how we'd integrate the new branch without a
new pull request. That sounds like a good plan to me.
---
R
FWIW, I think folks in the ZFS on Linux project have done something similar to
the "use two branches" technique.. i.e. they open the first pull request,
iterate with comments, and follow up patches, but *don't* force update to
ensure the history is intact.. then when the patch as a whole is in a
On Mon, Oct 26, 2015 at 10:03 AM, Will Andrews wrote:
> On Mon, Oct 26, 2015 at 10:37 AM, Prakash Surya
> wrote:
> > This is just my personal opinion, but disabling tests that fail is
> practically equivalent to
> > removing the test altogether. I've seen tests
See inline.
On Mon, Oct 26, 2015 at 9:01 AM, Will Andrews wrote:
> On Mon, Oct 26, 2015 at 9:06 AM, Prakash Surya
> wrote:
> > I see the following all fail on illumos master when we run it through the
> > regression suite at Delphix:
> >
>
I see the following all fail on illumos master when we run it through the
regression suite at Delphix:
cli_root/zfs_property/zfs_written_property_001_pos
cli_root/zfs_mount/zfs_mount_all_001_pos
mdb/mdb_001_pos
rsend/rsend_009_pos
zvol/zvol_swap/zvol_swap_004_pos
rootp
whoa, is zettamail forwarding to and from the mailing list?
also worth noting, this failed lint (not sure if it's a cascading error due to
build failure):
```
"../../common/fs/zfs/spa_history.c", line 449: warning: implicit function
declaration: kmem_vasprintf (E_NO_IMPLICIT_DECL_ALLOWED)
"../..
ked here:
http://jenkins.delphix.com/job/zfs-precommit/2972/ .. For anybody not on our
VPN and would like a copy of the results, drop me an email and I'll get them to
you.
- Prakash Surya
On Sept. 15, 2015, 11:36 p.m., Justin Gibbs wrote:
>
> --
> On Sept. 15, 2015, 4:24 a.m., Prakash Surya wrote:
> > I've kicked off revision 3 this review to our internal ZFS regression
> > suite; for those on Delphix's VPN the link is here:
> > http://jenkins.delphix.com/job/zfs-precommit/2968/
> >
> > I&#
ssion suite;
for those on Delphix's VPN the link is here:
http://jenkins.delphix.com/job/zfs-precommit/2968/
I'll add another comment to this review once I get the results from that test
run.
- Prakash Surya
On Sept. 15, 2015, 1:56 a.m., Jus
ge
Bugs: 5963
https://www.illumos.org/projects/illumos-gate//issues/5963
Repository: illumos-gate
Description (updated)
---
5963 rmis should be removed from arcstat manpage
Original author: Prakash Surya
Diffs (updated)
-
usr/src/man/man1m/arcstat.1m e4a0eca43ef69446f8b47800a7748
: 5564
https://www.illumos.org/projects/illumos-gate//issues/5564
Repository: illumos-gate
Description
---
5564 arcstat does not work after 5497 (fix manpage)
Original author: Prakash Surya
Diffs
-
usr/src/man/man1m/arcstat.1m e4a0eca43ef69446f8b47800a77481c87d93c852
Diff
: George Wilson
Original author: Prakash Surya
We need to remove the "recycle_miss" field from the arcstat.pl
script. A unit test should be added to the zfs test suite to ensure
this doesn't come up in the future. I've opened an internal Delphix
issue to track that work (the a
-
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/151/#review429
---
On Dec. 30, 2014, 11 p.m., Matthew Ahrens wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http
ust ask for your help again. Thank you!
>
> Prakash Surya wrote:
> Andriy, I'll allocate some time to test this on illumos/DelphixOS. Is
> there any specific test you need me to run? or just the usual pre-commit
> regression tests?
>
> Prakash Surya wrote:
>
> On Dec. 17, 2014, 4:31 p.m., Prakash Surya wrote:
> > This is failing a number of tests in the zfs test suite that aren't
> >
> > known to be problematic (which hints
ust ask for your help again. Thank you!
>
> Prakash Surya wrote:
> Andriy, I'll allocate some time to test this on illumos/DelphixOS. Is
> there any specific test you need me to run? or just the usual pre-commit
> regression tests?
>
> Prakash Surya wrote:
>
ve kicked off another test run just to make
sure the failures weren't due to some internal infrastructure issue:
http://jenkins/job/zfs-precommit/1406/
- Prakash Surya
On Dec. 5, 2014, 5:46 p.m., Xin LI wrote:
>
> ---
> T
cture:
http://jenkins/job/zfs-precommit/1399/ (link is useless outside of Delphix's
network)
- Prakash Surya
On Dec. 5, 2014, 5:46 p.m., Xin LI wrote:
>
> ---
> This is an automatically generated e-mail. To re
ust ask for your help again. Thank you!
>
> Prakash Surya wrote:
> Andriy, I'll allocate some time to test this on illumos/DelphixOS. Is
> there any specific test you need me to run? or just the usual pre-commit
> regression tests?
Since I haven't heard b
> On Nov. 30, 2014, 9:02 p.m., Matthew Ahrens wrote:
> > You will need to test on illumos too, at least some minimal sanity
> > checking. Let me know if you need help with that.
>
> Andriy Gapon wrote:
> I am still not set up for illumos testing :-(
> So I must ask for your help again.
On Wed, Dec 03, 2014 at 08:47:21PM -0500, Josef 'Jeff' Sipek via illumos-zfs
wrote:
> On Wed, Dec 03, 2014 at 05:41:31PM -0800, Matthew Ahrens wrote:
> > On Wed, Dec 3, 2014 at 5:37 PM, Josef 'Jeff' Sipek via illumos-zfs <
> > z...@lists.illumos.org> wrote:
> >
> > > So, the reason I managed to f
ow we expect this to be handled
> > thereafter, given that we don't handle it in these code paths, such that we
> > know that we are doing the right thing, minimally for the range of errors
> > that metaslab_init() can currently be passed by space_map_open().
>
> Pr
pport the possiblity
of this function failing.
- Prakash
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/110/#review273
----------
: Prakash Surya
Diffs
-
usr/src/uts/common/fs/zfs/vdev.c 7571b21a5f8cd5c0a1d6406556bcc22fcaceb814
usr/src/uts/common/fs/zfs/sys/metaslab.h
7fd47c08c9df5a7a3f6f24c6a4deda84502d0b19
usr/src/uts/common/fs/zfs/metaslab.c a33ec7f628108f5c3d2206583b060e2d580a7dca
Diff: https://reviews.csiden.org
That's interesting, just looking at the commit message. I've hit the
"can't remove file from full filesystem" issue most often when running
Lustre on top of the ZFS on Linux port, which makes heavy usage of fat
zaps.
--
Cheers, Prakash
On Tue, Jul 01, 2014 at 10:21:21PM -0700, Matthew Ahrens via
I'm curious, the allocation functions can return NULL on the OSX port?
That just seems like a recipe for disaster, if so. The code is written
with the assumption that allocations will never return NULL (IIRC, the
illumos allocation semantics guarantee success or hang).
--
Cheers, Prakash
On Mon
On Sun, Jun 22, 2014 at 08:14:01PM -0700, Matthew Ahrens wrote:
> On Mon, Jun 16, 2014 at 12:42 PM, Lakhinder Walia
> wrote:
> Hi.
>
> I have a FreeBSD 10.0-STABLE #0 r264414 based system with 32 GB RAM
> running ZFS/Geli.
>
> I would like to understand if the response patte
I'm assuming you're using ZFS on Linux? You might want to head over to
that mailing list (zfs-disc...@zfsonlinux.org), as there might be better
ZoL support. But, with that said; on Ubuntu that file is provided by the
'kmod-zfs-devel' package:
$ dpkg -S /usr/src/zfs-0.6.3/3.16.0-999-generic/zfs
Do they come with a free flight as well?? ;)
--
Cheers, Prakash
On Wed, Mar 26, 2014 at 03:15:03AM +0900, Matthew Ahrens wrote:
> I will be speaking about OpenZFS at dotScale, May 19th in Paris.
>
> http://www.dotscale..eu/
>
> I have a limited number of free tickets to dotScale, exclusively f
On Fri, Feb 28, 2014 at 08:52:17AM -0800, Richard Elling wrote:
> I'm not 100% sure of the provenance of the ARC code in ZoL. Are you saying
> that the breakage is specific to ZoL and does not affect upstream? Or do youÂ
> believe the issues have been around for a long time?
The biggest breakage I
On Sun, Feb 23, 2014 at 06:56:39PM -0800, Richard Elling wrote:
> On Feb 10, 2014, at 11:26 AM, Prakash Surya wrote:
> --
> Cheers, Prakash
>
> On Sun, Feb 09, 2014 at 10:28:44PM -0800, Richard Elling wrote:
> Hi Prakash,
>
> On
On Mon, Feb 10, 2014 at 08:14:10AM +0100, Udo Grabowski (IMK) wrote:
> On Feb 7, 2014, at 10:41 AM, Prakash Surya wrote:
> >>And here's a snippet from the pull request description with a summary of
> >>the benefits this patch stack has shown in my testing (go check ou
--
Cheers, Prakash
On Sun, Feb 09, 2014 at 10:28:44PM -0800, Richard Elling wrote:
> Hi Prakash,
>
> On Feb 7, 2014, at 10:41 AM, Prakash Surya wrote:
>
> > Hey guys,
> >
> > I've been working on some ARC performance work targeted for the ZFS on
> >
Hey guys,
I've been working on some ARC performance work targeted for the ZFS on
Linux implementation, but I think some of the patches I'm proposing
_might_ be useful in the other implementations as well.
As far as I know, the ARC code is largely the same between
implementations. Although, on Lin
to be consistent with the "dn_datablkszsec"
field in that structure. The only draw back to using "bytes" is it would
consume more space in the dnode_phys_t than a "count" of 512b chunks.
Personally, "bytes" is easier to reason with, but I'm not sure it's
w
Hi,
I have a compelling use case for larger dnodes and have spent a small
amount of time looking into a potential way of implementing this. But,
before I spend any more time on it, I want to get some buy in from the
community and upstream on the implementation details
My current plan for adding s
On Tue, Oct 22, 2013 at 11:23:43AM -0700, Richard Elling wrote:
> On Oct 21, 2013, at 2:40 PM, Keith Wesolowski
> wrote:
>
> On Mon, Oct 14, 2013 at 01:22:45PM -0700, Matthew Ahrens wrote:
>
> commit 9dcb97198338ba2d8764dd5604b278118612f74d
> Author: Brian Behlendorf
>
An illumos based image would be great if we plan to do any upstreaming
of the Linux patches to illumos. I have no idea how to go about
compiling/testing patches on illumos at the moment.
--
Cheers, Prakash
On Sat, Oct 19, 2013 at 11:55:25AM +0100, Luke Marsden wrote:
> On 19/10/13 10:39, Joerg S
On Fri, Oct 18, 2013 at 06:07:30PM -0700, Richard Elling wrote:
> On Oct 18, 2013, at 10:44 AM, Prakash Surya wrote:
>
> Well, the more I think about it, the less it worries me. Let's ignore
> that statement for now.
>
> We have users tweaking the ARC lim
size is
only 2% the size of ARC max. Not bad, imo.
--
Cheers, Prakash
On Fri, Oct 18, 2013 at 10:15:40AM -0700, Matthew Ahrens wrote:
> On Fri, Oct 18, 2013 at 8:36 AM, Prakash Surya wrote:
> Other than what Matt brought up, it would be nice to have a way to
> override the
On Thu, Oct 17, 2013 at 01:47:15AM -0400, Richard Yao wrote:
>
>
> On Oct 16, 2013, at 8:13 PM, Saso Kiselkov wrote:
>
> > On 10/17/13 12:42 AM, Richard Yao wrote:
> >> One of these days, I will learn to include the CC list when using my
> >> iPad. Anyway, I like being able to tell people that
Other than what Matt brought up, it would be nice to have a way to
override the default values without recompiling. But we can add that to
the Linux port as needed. I don't really know how you guys support that
sort of thing.
Also, it _might_ be useful to move statements like:
Using the defau
On Thu, Oct 17, 2013 at 01:11:32AM +0100, Saso Kiselkov wrote:
> On 10/17/13 1:03 AM, Matthew Ahrens wrote:
> > On Wed, Oct 16, 2013 at 5:00 PM, Steven Hartland
> > How about the case where the admin has specifically sized a smaller
> > zfs_arc_max to keep ZFS / ARC memory requirements down
On Wed, Oct 16, 2013 at 10:34:24PM +0100, Saso Kiselkov wrote:
> On 10/16/13 8:57 PM, Prakash Surya wrote:
> > Well, we're just increasing the size of the hash. So, given enough RAM,
> > the problem of having enough buffers in the cache to cause large chains
> > sti
On Wed, Oct 16, 2013 at 12:57:18PM -0700, Prakash Surya wrote:
> On Wed, Oct 16, 2013 at 06:40:12PM +0100, Saso Kiselkov wrote:
> > On 10/16/13 6:27 PM, Prakash Surya wrote:
> > > On Wed, Oct 16, 2013 at 02:57:08AM +0100, Saso Kiselkov wrote:
> > >> On 10/16/1
On Wed, Oct 16, 2013 at 04:01:16PM -0400, Richard Yao wrote:
> On 10/16/2013 03:57 PM, Prakash Surya wrote:
> > On Wed, Oct 16, 2013 at 06:40:12PM +0100, Saso Kiselkov wrote:
> >> On 10/16/13 6:27 PM, Prakash Surya wrote:
> >>> If the completely dynamic approach
gt; the SPARC variants that have such support anyway.)
I believe the current solution auto tunes the hash table based on the
physical RAM size.
--
Cheers, Prakash
>
> - Garrett
>
> On Oct 16, 2013, at 11:07 AM, Richard Yao wrote:
>
> > On 10/16/2013 01:27 PM, Praka
On Wed, Oct 16, 2013 at 06:40:12PM +0100, Saso Kiselkov wrote:
> On 10/16/13 6:27 PM, Prakash Surya wrote:
> > On Wed, Oct 16, 2013 at 02:57:08AM +0100, Saso Kiselkov wrote:
> >> On 10/16/13 2:42 AM, Prakash Surya wrote:
> >>> OK, that is where I assumed the spe
On Wed, Oct 16, 2013 at 02:57:08AM +0100, Saso Kiselkov wrote:
> On 10/16/13 2:42 AM, Prakash Surya wrote:
> > OK, that is where I assumed the speed up was coming from (shorter
> > chains leading to faster lookups).
> >
> > I also assumed there would be a "bucket
On Tue, Oct 15, 2013 at 10:47:22PM +0100, Saso Kiselkov wrote:
> On 10/15/13 10:26 PM, Prakash Surya wrote:
> > On Sun, Oct 13, 2013 at 12:21:05AM +0100, Saso Kiselkov wrote:
> >> The performance gains from this are pretty substantial in my testing.
> >> The time neede
On Sun, Oct 13, 2013 at 12:21:05AM +0100, Saso Kiselkov wrote:
> The performance gains from this are pretty substantial in my testing.
> The time needed to rebuild 93 GB worth of ARC buffers consisting of a
> mixture of 128k and 8k blocks (total number of ARC buffers: 6.4 million,
> or ~15.4k avera
Perhaps I just overlooked this, but what is the context for *why* this
change is needed? Is it just to remove a single large allocation by
breaking it up into multiple smaller allocations? I feel like I'm
missing the "bigger picture" here.
--
Cheers, Prakash
On Tue, Oct 15, 2013 at 03:10:10PM +0
75 matches
Mail list logo
