it incompatible to use with other licenses, in
> particular GPL3-only.
>
> To address this issue, change the project license to GPL-2.0-or-later
> and libimaevm to LGPL 2.0 or later.
>
> Signed-off-by: Dmitry Kasatkin
Acked-by: George Wilson
or making comparison with intel
> white papers which used for x86, ARM, and PowerPC GCM implementations in
> OpenSSL library?
Gladly.
>
> regards,
> Mamone
--
George Wilson
IBM Linux Technology Center
Security Development
___
nettle-b
es.
> >
> > I haven't yet had the time to read the code carefully.
> >
>
> You see, the alignment of each element is 0x100 (256). The table has 16
> elements and you got the size of the table 4096 which is reasonable because
> 16*256=4096
>
> regards,
> Mamone
> _
I'm voting:
Proposal 0001: Yes
Proposal 0002: Yes
On Sat, 14 Nov 2020 at 03:10, Rebecca Skinner
wrote:
>
> I'm voting:
>
> Proposal 0001: Yes
> Proposal 0002: Yes
>
> On Thu, Nov 12, 2020 at 4:00 PM Tikhon Jelvis wrote:
>>
>> I'm voting:
>>
>> Proposal 0001: Yes
>> Proposal 0002: Yes
>>
>> On
multiplication
> > +vpmsumdF2,H1L,C1
> > +vpmsumdR2,H1M,C1
> > +vpmsumd F,H2L,C0
> > +vpmsumdR,H2M,C0
> > +
> > +C deferred recombination of partial products
> > +vxor F,F,F2
> > +vxor
ertainly that is the case
> for RackTop.
>
>
>
> Automatic conversion (or simply using a single shared value) only makes
> sense when there is broad agreement about the property contents. Absent
> that, namespace separation, **without** naïve attempts to convert, is
> probably
A couple of months ago we discussed the issues surrounding zfs properties
which have platform specific implementations. The example given was
“sharenfs” which has platform-specific syntax and platform-specific
implementations. Having platform-specific syntax for these types of
properties means
, the committee, including the new member,
will hold a discussion and elect a new chair from amongst ourselves.
Regards,
George Wilson
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
, the committee, including the new member,
will hold a discussion and elect a new chair from amongst ourselves.
Regards,
George Wilson
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
are on
https://wiki.haskell.org/Haskell.org_committee
If you have any questions about the process, please feel free to
e-mail us at committee at haskell.org, or contact one of us
individually.
Regards,
George Wilson
___
Haskell mailing list
Haskell@haskell.org
We just hit a similar issue on Ubuntu 18.04. From the crash dump, I'm
able to see this stack:
[12929.914040] kworker/u4:5D0 27285 2 0x8080
[12929.914053] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[12929.914055] Call Trace:
[12929.914075] __schedule+0x291/0x8a0
We just hit a similar issue on Ubuntu 18.04. From the crash dump, I'm
able to see this stack:
[12929.914040] kworker/u4:5D0 27285 2 0x8080
[12929.914053] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[12929.914055] Call Trace:
[12929.914075] __schedule+0x291/0x8a0
grwilson commented on this pull request.
> @@ -1039,6 +1039,13 @@ metaslab_group_allocatable(metaslab_group_t *mg,
> metaslab_group_t *rotor,
if (mg->mg_no_free_space)
return (B_FALSE);
+ /*
+* Relax allocation throttling
grwilson approved this pull request.
--
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/687#pullrequestreview-160374250
--
openzfs:
@citrus-it in the past we've seen storage arrays that have zeroed out blocks
behind the scenes leading to ZFS reported checksums. We wanted to have a
default value that would not be confused with that type of corruption. We did
make this a global parameter (`zfs_initialize_value`) so that it
Thumbs up. It looks like a good selection to me.
On 9 April 2018 at 05:52, Gershom B wrote:
> I wanted to call people's attention to this PR:
>
> https://github.com/haskell-infra/hl/pull/229
>
> The videos are overdue for updating, and the suggestions look good to
> me, but a
ctually, I tried to communicate my interest for 'Summer of
> Haskell' program (I was unaware at that time that it was only for years when
> Haskell didn't participate in GSoC) to the general committee
> (commit...@haskell.org) from where George Wilson sir directed me towards Alp
> and Jared sir
You could go through and `dd` to every disk before adding it to the pool and
that is the common practice used by many. The problem that this is trying to
solve is to be able to avoid the delay of having to wait for every disk to be
pre-warmed before using it. Also, people often forget to "warm"
Reviewed by: John Wren Kennedy
Reviewed by: Matthew Ahrens
Reviewed by: Pavel Zakharov
Reviewed by: Prakash Surya
PROBLEM
The first access to a block incurs a performance penalty on some
grwilson approved this pull request.
--
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/558#pullrequestreview-99102002
--
openzfs-developer
grwilson requested changes on this pull request.
This change looks good, can you also change `arc_loan_buf` to mimic this
change. I think we should always rely on `arc_buf_size` to determine the
correct value to pass to `arc_loaned_bytes_update`
--
You are receiving this because you are
@grwilson pushed 1 commit.
1d7e2b0 all bits
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/505/files/445e55128ca0a1cf9b0a7013d996edd50da3a0f4..1d7e2b0d0cb2416d9838f0bd25fc174f31c4be09
@grwilson pushed 1 commit.
445e551 predefine child bits
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/505/files/b1342b226af1aa8a39cbcbe3b59a9270765c8ef2..445e55128ca0a1cf9b0a7013d996edd50da3a0f4
One of the guiding principles for zfs is simple administration and it seems
like we're exposing way too many knobs to the administrator. These knobs expose
the internals of the product. For example, if I want to clear the labels, why
wouldn't I just run `zpool labelclear` and have the command
@youzhongyang @avg-I can you take another look to make sure I've address all of
your concerns?
--
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/505#issuecomment-364239237
Your comments are considered and I will be pushing a new commit with the
updated logic. I've tried several variations to the suggestions to find which
looks the best and has the least amount of impact. The suggested
`ZIO_CHILD_BIT` option looks the best so I've gone with that option.
--
You
grwilson commented on this pull request.
I have concerns about the ultimate goal for this command. It's unclear if we
really want to "wipe" or just "forget" about this device.
> @@ -709,8 +751,12 @@ zpool_do_labelclear(int argc, char **argv)
}
if (zpool_read_label(fd, ) != 0)
grwilson commented on this pull request.
> @@ -209,12 +209,13 @@ enum zio_flag {
ZIO_FLAG_CANFAIL)
enum zio_child {
- ZIO_CHILD_VDEV = 0,
- ZIO_CHILD_GANG,
- ZIO_CHILD_DDT,
- ZIO_CHILD_LOGICAL,
- ZIO_CHILD_TYPES
+ ZIO_CHILD_VDEV = 1 << 0,
PROBLEM
It's possible for a parent zio to complete even though it has children
which have not completed. This can result in the following panic:
> $C
ff01809128c0 vpanic()
ff01809128e0 mutex_panic+0x58(fb94c904, ff597dde7f80)
ff0180912950
grwilson commented on this pull request.
> @@ -1567,7 +1569,7 @@ arc_cksum_is_equal(arc_buf_hdr_t *hdr, zio_t *zio)
bzero((char *)cbuf + csize, HDR_GET_PSIZE(hdr) - csize);
BTW, this wasn't part of your change but this also looks broken. I believe that
we should be
grwilson approved this pull request.
Changes look good. Make sure you open up an illumos bug for this this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Andriy,
I'm not familiar with spa_async_thread_vd() (I don't believe that is
upstreamed yet) so I can't comment on what is the correct thing to do
there. As for spa_async_thread(), I think we can ignore all tasks when the
pool is read-only. You'll probably need to update the call to vdev_probe()
parser.c
> create mode 100644 include/linux/keyctl.h
> create mode 100644 security/keys/keyctl_pkey.c
>
Hi David,
To lend support for this patch series, we have a compelling use case in
OpenPOWER
firmware. We need to verify that our key management command queue elements are
properly signed.
parser.c
> create mode 100644 include/linux/keyctl.h
> create mode 100644 security/keys/keyctl_pkey.c
>
Hi David,
To lend support for this patch series, we have a compelling use case in
OpenPOWER
firmware. We need to verify that our key management command queue elements are
properly signed.
parser.c
> create mode 100644 include/linux/keyctl.h
> create mode 100644 security/keys/keyctl_pkey.c
>
Hi David,
To lend support for this patch series, we have a compelling use case in
OpenPOWER
firmware. We need to verify that our key management command queue elements are
properly signed.
This
> should work, but at the cost of the less uniform bio handling code.
>
> So, I wanted to see which of the solutions would be better from the point
> of
> view of the general zio pipeline architecture.
>
> Thank you.
>
> On 14/09/2017 18:48, George Wilson wr
Andriy,
The ZIO_STAGE_VDEV_IO_DONE is not necessary for ZIO_IOCTL_PIPELINE and
that's why it was removed. At least in illumos, there is no functional
reason for calling it. To add it back would require a small amount of
change which should not be a big deal. Can you provide some context around
grwilson approved this pull request.
--
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/422#pullrequestreview-58790150
--
openzfs-developer
grwilson approved this pull request.
--
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/409#pullrequestreview-58659280
--
openzfs-developer
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)
*
On Tue, Jul 25, 2017 at 10:36:11AM -0700, James Bottomley wrote:
> On Tue, 2017-07-25 at 15:04 +0200, Michal Suchánek wrote:
> > Hello,
> >
> > in commit 9754d45e9970 ("tpm: read burstcount from TPM_STS in one
> > 32-bit transaction") you change reading of two 8-bit values to one
> > 32bit read.
On Tue, Jul 25, 2017 at 10:36:11AM -0700, James Bottomley wrote:
> On Tue, 2017-07-25 at 15:04 +0200, Michal Suchánek wrote:
> > Hello,
> >
> > in commit 9754d45e9970 ("tpm: read burstcount from TPM_STS in one
> > 32-bit transaction") you change reading of two 8-bit values to one
> > 32bit read.
On Tue, Jul 25, 2017 at 10:36:11AM -0700, James Bottomley wrote:
> On Tue, 2017-07-25 at 15:04 +0200, Michal Suchánek wrote:
> > Hello,
> >
> > in commit 9754d45e9970 ("tpm: read burstcount from TPM_STS in one
> > 32-bit transaction") you change reading of two 8-bit values to one
> > 32bit read.
he pointer.
>
>
> I opened an issue for Wget2 at https://gitlab.com/gnuwget/wget2/issues/234
> .
>
>
> With Best Regards, Tim
>
>
>
> On 07/20/2017 04:44 AM, Frederick George Wilson wrote:
> > Those pesky manifest.mpd URLs -- the noncompliant (unverifiable) ones
grwilson approved this pull request.
--
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/310#pullrequestreview-43429326
--
openzfs-developer
grwilson commented on this pull request.
> ARCSTAT_INCR(arcstat_l2_size, write_sz);
- ARCSTAT_INCR(arcstat_l2_asize, write_asize);
- vdev_space_update(dev->l2ad_vdev, write_asize, 0, 0);
+ ARCSTAT_INCR(arcstat_l2_asize, write_psize);
I agree. These variables and their
@grwilson pushed 2 commits.
7900469 Merge branch 'master' into metaslab_selection
86d718e git-zfs-make-Wed Sep 21 15:56:55 EDT 2016
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
+1 Thanks guys!
On Mon, Aug 1, 2016 at 4:52 PM, Matthew Ahrens wrote:
> Thank you for your work on this, Chris and DJ. I look forward to seeing
> this change upstreamed to illumos.
>
> --matt
>
> On Mon, Aug 1, 2016 at 4:36 PM, Dj Hoffman wrote:
>
>>
On Wed, Jul 27, 2016 at 10:31:52AM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 27, 2016 at 11:05:14AM -0500, George Wilson wrote:
>
> > > Yes, generally Linux expects DT to be set correctly by the boot
> > > firmware. Early firmware needs to know the TPM type anyhow to do
On Tue, Jul 26, 2016 at 03:03:44PM -0600, Jason Gunthorpe wrote:
> On Tue, Jul 26, 2016 at 03:39:02PM -0500, George Wilson wrote:
> > > Generally speaking probing is somewhat discouraged, currently we only
> > > probe for PC platform tis (and even that might be a mistake), al
traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2d
Andriy,
I think this is basically a rule, although I don't think it's stated
anywhere. We do rely heavily on this locking strategy since there are many
places that will hold the namespace lock to prevent spa config changes but
yet wait for a txg to sync.
Is it honored everywhere? Well, I hope so
Andriy,
Can you give me some details about how you're able to reproduce this panic.
I would like to help debug this. I'm also looking into the range_tree()
panic, so any details you can provide would be very helpful.
If you can publish the crash dumps, I can also download them and take a
look.
LGTM
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/47#issuecomment-165781640___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
LGTM.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/43#issuecomment-161622259___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
LGTM
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/44#issuecomment-161621968___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
> @@ -1508,7 +1509,15 @@ exi_cache_trim(struct exportinfo *exi)
>* used for NFSAUTH_CACHE_TRIM seconds.
>*/
> for (c = avl_first(tree); c != NULL; c = AVL_NEXT(tree, c)) {
> - rw_enter(>authc_lock, RW_WRITER);
> +
LGTM
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/22#issuecomment-152831278___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
Looks good to me
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/31#issuecomment-152831553___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
LGTM
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/21#issuecomment-152831323___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
sues/6292
>
>
> Repository: illumos-gate
>
>
> Description
> ---
>
> 6292 exporting a pool while an async destroy is running can leave entries in
> the deferred tree
> Reviewed by: Paul Dagnelie <p...@delphix.com>
> Reviewed by: Matthew Ahrens
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/258/#review826
---
Ship it!
Ship It!
- George Wilson
On Oct. 10, 2015, 11:15 p.m
I don't think L2ARC can be shared only spare devices can be shared.
- George
On Fri, Sep 11, 2015 at 7:23 AM, Andriy Gapon
wrote:
>
> I am curious what was the original reason to not allow sharing of cache
> devices
> (L2ARC) between pools?
> After all, the main ARC
. It would not be a trivial
implementation but seems doable.
- George
On Fri, Sep 11, 2015 at 7:40 AM, Andriy Gapon <andriy.ga...@clusterhq.com>
wrote:
> On 11/09/2015 16:36, George Wilson wrote:
> > I don't think L2ARC can be shared only spare devices can be shared.
>
> But why
Jorgen,
Since you're unloading the pool, there should not be any new allocations or
frees happening. This is actually prevented by the call to txg_sync_stop()
from spa_unload(). Here it should perform the final txg_wait_synced() to
clear out all the ms_freetrees and stop the sync thread.
You
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/229/#review764
---
Ship it!
Ship It!
- George Wilson
On June 25, 2015, 12:34 p.m
like to see review from Saso and George as well.
George, Saso, ping.
- Andriy
On June 25th, 2015, 3:34 p.m. EEST, Andriy Gapon wrote:
Review request for OpenZFS Developer Mailing List, Justin Gibbs, George
Wilson, Matthew Ahrens, and Saso Kiselkov.
By Andriy Gapon.
*Updated June 25
Jorgen,
Can you provide some details about the stack trace when you hit this
failure. All of the ms_freetrees should be empty by the time you can
range_tree_destroy(). So to debug this we need to understand the calling
stack to determine why that isn't happening.
Thanks,
George
On Sat, Aug 22,
Greetings all,
I have been looking around and am having a hard time finding a definitive
solution but we are having an issue with an AngularJS based Java
application deployed to WebLogic. Ideally, any files which are updated
following a new build would be updated and served to the browser. This
I added the following line in a call to myApp.config():
$httpProvider.defaults.headers.common['Cache-Control'] = 'max-age=0,
must-revalidate';
This appears to have corrected it but a colleague is verifying.
On Thursday, August 6, 2015 at 9:34:06 AM UTC-7, George Wilson wrote:
Greetings all
.
- George Wilson
On May 6, 2015, 12:21 p.m., Andriy Gapon wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/219/
---
(Updated May 6
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/217/#review728
---
Ship it!
Ship It!
- George Wilson
On May 8, 2015, 3:29 a.m., Gleb
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/226/#review735
---
Ship it!
Ship It!
- George Wilson
On May 27, 2015, 1:51 p.m
christopher.si...@delphix.com
Original author: George Wilson
Diffs
-
usr/src/uts/common/fs/zfs/dmu_traverse.c
14eef2e7516c9b5e717ef318321ee137dcd19c9f
Diff: https://reviews.csiden.org/r/172/diff/
Testing
---
ztest; zfs test suite
http://jenkins/job/zfs-precommit
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/167/#review543
---
Ship it!
Ship It!
- George Wilson
On Feb. 27, 2015, 7:45 p.m., Xin
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/163/#review530
---
Ship it!
Ship It!
- George Wilson
On Feb. 21, 2015, 5:34 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/155/#review477
---
Ship it!
Ship It!
- George Wilson
On Feb. 4, 2015, 4:59 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/152/#review461
---
Ship it!
Ship It!
- George Wilson
On Jan. 27, 2015, 5:55 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/147/#review407
---
Ship it!
Ship It!
- George Wilson
On Dec. 16, 2014, 6:39 a.m., Xin
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/128/#review408
---
Ship it!
Ship It!
- George Wilson
On Dec. 2, 2014, 12:22 p.m
Comment block missing start and end lines.
usr/src/uts/sparc/stmf_sbd/Makefile
https://reviews.csiden.org/r/131/#comment348
Comment block missing start and end lines.
- George Wilson
On Dec. 15, 2014, 4:48 a.m., Justin Gibbs wrote
On 10/25/14, 2:09 PM, Alexander Pyhalov wrote:
One other question, do you have an old 'zpool status' of the pool
you're trying to import? I'm trying to verify that the pool
configuration shown above under $import looks correct to you. Should
that pool have more than one device? Is that the
This looks like it could be caused by illumos bug# 5213. We are trying
to push a fix upstream but it's still out for review:
https://reviews.csiden.org/r/110/
Can you please provide the ::spa -v output from the core file?
Thanks,
George
On 10/24/14, 9:48 AM, Alexander Pyhalov via
On 7/7/14, 3:33 AM, Jan Schmidt via illumos-zfs wrote:
On Wed, June 25, 2014 at 16:15 (+0200), Keith Wesolowski Via Illumos-zfs wrote:
On Wed, Jun 25, 2014 at 01:47:54PM +0200, Jan Schmidt via illumos-zfs wrote:
That patch looks somewhat promising, though I have not tried it yet. How did
On 5/7/14, 10:55 AM, Steven Hartland wrote:
- Original Message - From: George Wilson
george.wil...@delphix.com
To: Steven Hartland kill...@multiplay.co.uk; developer@open-zfs.org
Sent: Wednesday, May 07, 2014 3:07 PM
Subject: Re: [OpenZFS Developer] zfs zio reordering
On 5/7/14, 11:46 AM, Steven Hartland wrote:
- Original Message - From: George Wilson
george.wil...@delphix.com
There are a couple of cases where it can work but I'm going to make
it such that requires you to always return back ZIO_PIPELINE_STOP.
Otherwise it's makes it too easy
On 5/7/14, 12:50 PM, Steven Hartland wrote:
- Original Message - From: George Wilson
george.wil...@delphix.com
On 5/7/14, 11:46 AM, Steven Hartland wrote:
- Original Message - From: George Wilson
george.wil...@delphix.com
There are a couple of cases where it can work
Steven,
I think there is probably another way we can solve this problem but I
first want to get a better understanding of the corruption. We have not
integrated the TRIM support upstream and I suspect that's the source of
most of the problems. Can you confirm that with TRIM disabled that most
Hmm, 'zpool scrub' should be able to clear that error. Can you tell me
which options you used to 'zinject' and I'll try reproducing it here.
Thanks,
George
On 2/26/14 4:22 AM, Andriy Gapon wrote:
I did some experimenting and used zinject to introduce some non-correctable data
errors while
- Shell: long-lived CLI process for Maven
A Maven shell? Interesting idea, how does that work? It seems like the idea
behind maven is set it and forget it.
On Wed, Jan 15, 2014 at 5:08 PM, Dan Tran dant...@gmail.com wrote:
is it a new baby from Sonatype?
-D
On Wed, Jan 15, 2014 at 10:26
Sounds interesting. I signed up for the webinar and look forward to hearing
more.
On Thu, Jan 16, 2014 at 10:53 AM, Jason van Zyl ja...@takari.io wrote:
Sorry I'm responding out of the original thread, but realized I had the
wrong account subscribed to the user list. So I'll respond to the
LGTM.
- George
On 1/14/14 12:57 PM, Saso Kiselkov wrote:
On 1/14/14, 11:51 AM, Andriy Gapon wrote:
Recently I noticed that on one of our systems l2arc_feed_thread was consuming
non insignificant amount of CPU time. I looked at some stats (FreeBSD has local
changes that add a few kstats for
Ilya,
I think there is a bigger problem here that your vdev_mirror() change
would cover up. The problems is that we should never have a bp with a
dva that is out of range. So we need to understand how that is occurring.
As for you question about metaslab_allocate_dva(), I'm assuming you're
On 12/17/13 5:21 AM, Gaurav Mahajan wrote:
Hi all,
I am trying to understand relations of root ZIO and children ZIO.
This is what I have understood.. Please correct me if I'm wrong.
Usually whenever we want to do a series of IO operations like in sync
thread.
We create a root ZIO with
Andriy,
The fix looks good but I have a couple of questions:
1. Are you sure you want the TRIM priority to be lower than SCRUB?
2. You have zfs_vdev_trim_max_active set to 1 with an /* XXX */ next to
it. Does this mean you haven't settled on the final value for active max?
Thanks,
George
On
FWIW, I tend to think less about the particular definitions and
semantics of testing types and think more about the needs associated
with tests. For tests which depend on deployed resources, etc... I use
failsafe. For tests which can be handled locally whether resources are
mocked or called
James, see my response. It sounds to me like you may need to use
Failsafe- particularly if you need to deploy your artifact to your
application server and access system resources. If you are doing
simple HTTP requests and want to set it up as a unit test- my advise
if capture a response and save
Unfortunately, my company's security policies do not allow for the
downloading and building of external projects without approval from IT
and security so I cannot really test your code (not without going to a
committee, etc...). Any chance you can post the errors you are
getting? Is this a JVM
? On a personal
machine while at work? Not being able to try out code from the Internet
seems like a crippling restriction to me.
-Curtis
On Nov 13, 2013 1:34 PM, George Wilson rmws...@gmail.com wrote:
Unfortunately, my company's security policies do not allow for the
downloading
: UTF-8
OS name: mac os x, version: 10.9, arch: x86_64, family: mac
$ jar tf code/target/code-0.1.0.jar |wc
11 11 270
$ jar tf resources/target/resources-0.1.0.jar |wc
65547 65547 2151861
George Wilson wrote:
the restriction is in regards to building a larger project
1 - 100 of 267 matches
Mail list logo