From owner-freebsd-geom@freebsd.org Tue Sep 12 11:55:13 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79693E05769 for ; Tue, 12 Sep 2017 11:55:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 918D56E7B0; Tue, 12 Sep 2017 11:55:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA12909; Tue, 12 Sep 2017 14:55:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1drjmV-000Nqt-52; Tue, 12 Sep 2017 14:55:07 +0300 To: freebsd-geom@FreeBSD.org From: Andriy Gapon Subject: "unspoilable" geom labels Message-ID: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> Date: Tue, 12 Sep 2017 14:54:11 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 11:55:13 -0000 At the moment all GEOM labels are spoilable in a sense that opening a provider in the write mode spoils GEOM labels that are attached as other consumers. The reason for that behavior is that the writer may modify the (meta-)data in such a way that the label would have to change. Here is a modest proposal to make some labels "unspoilable". Indeed, it's not necessary that the writer is always able to modify the label. The best example would be the disk ID labels that are based on the disk serial numbers. It is not possible to modify the serial number by means of the regular access to the disk. Similarly, the GPT-based labels can not be modified by opening a partition for writing. They can be modified only by changing the partition tables which requires opening the enclosing disk. For the sake of completeness, here is an example of a spoilable label: a label that's based on a filesystem ID that's recorded in a superblock or its equivalent. The goal of this proposal is to make the labels slightly stabler and slighly more usable. A preliminary patch can be found here: https://people.freebsd.org/~avg/geom-unspoilable-labels.diff I'd be first to admit that the proposal is just a minor improvement and does not solve all the problems with the labels. I think that the whole design for the GEOM labels needs to be changed. For example, I am not a big fan of adding another NOP geom between a driver and a real consumer in the I/O path. Perhaps, making labels be additional providers of an underlying geom would be a better solution. Maybe something else. Anything to make the GEOM labels look more like aliases for original GEOM providers. Because right now they look like completely independent providers and you have to follow the GEOM graph to discover the relations (even if the original provider and its label are removed by just a single edge). Another thing that seems to be desirable is a better integration between CAM userland and GEOM. For instance, I would like to be able to do things like camcontrol standby /dev/diskid/DISK-MK0351YVKNNX3A Unfortunately, that's not possible at present because the CAM code does not expect to see any alias (or a symbolic link) as the device name and the name is always expected to be in the form . It would be good if the code tried to follow links and it was able to understand GEOM labels / aliases. -- Andriy Gapon From owner-freebsd-geom@freebsd.org Tue Sep 12 12:23:07 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EA34E070E9 for ; Tue, 12 Sep 2017 12:23:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9616F805 for ; Tue, 12 Sep 2017 12:23:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA12963 for ; Tue, 12 Sep 2017 15:23:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1drkDY-000Ns1-43 for freebsd-geom@FreeBSD.org; Tue, 12 Sep 2017 15:23:04 +0300 Subject: Re: gmirror and a flaky member From: Andriy Gapon To: freebsd-geom@FreeBSD.org References: <7e4164bd-9804-02d5-5990-bc15354989e9@FreeBSD.org> <77c40117-35ab-2430-07f8-e1df6b87fe1c@FreeBSD.org> <3952383e-e03a-1b27-f798-bfb1cf0b6007@FreeBSD.org> <69d4d61c-dcb3-a7ac-ecd3-e47facd19b2e@FreeBSD.org> <22925727-315e-e109-9859-e0c32d9604ff@FreeBSD.org> Message-ID: Date: Tue, 12 Sep 2017 15:21:42 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <22925727-315e-e109-9859-e0c32d9604ff@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 12:23:07 -0000 On 07/02/2017 11:46, Andriy Gapon wrote: > I've created a review request for this: https://reviews.freebsd.org/D9463 I would like to invite again anyone interested to review the above change. Thank you! -- Andriy Gapon From owner-freebsd-geom@freebsd.org Tue Sep 12 13:29:00 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3B00E09674 for ; Tue, 12 Sep 2017 13:29:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82919715E5 for ; Tue, 12 Sep 2017 13:29:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id j141so46769983ioj.4 for ; Tue, 12 Sep 2017 06:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mRbf0Vv0qZ4N3ecN1ukjZE1HthscDjUJNChzhkCnGyU=; b=mUHzcfQuyufiM6ERHP17w/xZBGYzkai9BnjET88Goqvqk1GRN3aLGm9wMKzW5fXEDq OrPZs9vUW18Uiw2c7tWGEOgyS1qTfLnJaU1iMEfriaggMhb2Ymg6E3adjH21+rcJEg66 pxVgOtNz9qPasPhNMk4AJ908kaek4MP0wGiaKXpdvazphkL+OVYVGBF5dxYAzDN0vqjF QOqTbIy5KbL8tthdV5kFzrLpVsgaXV6aRbnCFw+NA3JmeruOrzMpMyK1sQyv87atUjDZ GHOmFNwRMo85XtrY5jglqMJ2RvGC9alGvVoJA1QoxRawv7iy0e6eOJ2zBwnzkTth8JEL 9aEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mRbf0Vv0qZ4N3ecN1ukjZE1HthscDjUJNChzhkCnGyU=; b=udjsdarNH/H7gg472kLNpXkf3hzdGBKayFFGY3W8SZmmy1cQ/JbiAelYNmHrUCrhiV BBxKaC7MpGhujigtAZLByhRY91RsPV9Nqp69dhiu91ZzPA/oV6bq4r11OaEEAx+TC4hW dTLPt9yAwzw2Nl55gwle/hDGtf4+vRAnpzW8La4EduH/5JYBfbROxYos2lsXOst6bdYL A+Ph4U3DAMaEZ1+7ej90oZii9KbQ2OTyA/qlxAuFpebJwmKDLeZc/MhKU9mf7wqNtAUm 0/HMNkB5xXY9izlHNmB+m2yaOk1Mn14M4chborJeXJ+2FmLdOBEuvTZyVgi8A/OUsBU2 iczw== X-Gm-Message-State: AHPjjUiux35vZcJF+eJDTbDN90Q4Q6tYcHpiALlG+Vmrrx/l/fJFdhzm MyRsssJTuYpsNwzwCy4fRkwbFYs+ML+H X-Google-Smtp-Source: ADKCNb5+ZCCQb6aPtlRsHg1d5QRNQDAtVhKp84epR5ehMcYz0YkTdJdAQhDaLva+0m+mOhrEH2IRnFin+wZ//qXVNig= X-Received: by 10.107.133.92 with SMTP id h89mr12942246iod.208.1505222939615; Tue, 12 Sep 2017 06:28:59 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Tue, 12 Sep 2017 06:28:58 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:809b:5e24:6d84:c8fa] In-Reply-To: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> References: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> From: Warner Losh Date: Tue, 12 Sep 2017 07:28:58 -0600 X-Google-Sender-Auth: KLpZ-c0u1jSmJXV7M_2yeY-X4Sk Message-ID: Subject: Re: "unspoilable" geom labels To: Andriy Gapon Cc: freebsd-geom@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:29:00 -0000 On Tue, Sep 12, 2017 at 5:54 AM, Andriy Gapon wrote: > > At the moment all GEOM labels are spoilable in a sense that opening a > provider > in the write mode spoils GEOM labels that are attached as other consumers. > The reason for that behavior is that the writer may modify the (meta-)data > in > such a way that the label would have to change. > > Here is a modest proposal to make some labels "unspoilable". > Indeed, it's not necessary that the writer is always able to modify the > label. > The best example would be the disk ID labels that are based on the disk > serial > numbers. It is not possible to modify the serial number by means of the > regular > access to the disk. > Similarly, the GPT-based labels can not be modified by opening a partition > for > writing. They can be modified only by changing the partition tables which > requires opening the enclosing disk. > > For the sake of completeness, here is an example of a spoilable label: a > label > that's based on a filesystem ID that's recorded in a superblock or its > equivalent. > > The goal of this proposal is to make the labels slightly stabler and > slighly > more usable. > A preliminary patch can be found here: > https://people.freebsd.org/~avg/geom-unspoilable-labels.diff > > I'd be first to admit that the proposal is just a minor improvement and > does not > solve all the problems with the labels. > I think that the whole design for the GEOM labels needs to be changed. > For example, I am not a big fan of adding another NOP geom between a > driver and > a real consumer in the I/O path. > Perhaps, making labels be additional providers of an underlying geom would > be a > better solution. Maybe something else. Anything to make the GEOM labels > look > more like aliases for original GEOM providers. Because right now they > look like > completely independent providers and you have to follow the GEOM graph to > discover the relations (even if the original provider and its label are > removed > by just a single edge). > I recently added aliases, and the thought was that once the kinks are worked out they could also be used for labels and we could eliminate the extra geom nodes. > Another thing that seems to be desirable is a better integration between > CAM > userland and GEOM. For instance, I would like to be able to do things like > camcontrol standby /dev/diskid/DISK-MK0351YVKNNX3A > Unfortunately, that's not possible at present because the CAM code does not > expect to see any alias (or a symbolic link) as the device name and the > name is > always expected to be in the form . It would be good if the > code > tried to follow links and it was able to understand GEOM labels / aliases. The CAM code expects to be able to map the name 'da0' to 'pass14' so it can send the passthrough devices. It has no clue about device names, apart from passXXX it has to open to send the commands for the thing named 'da0'. In fact, it has no clue at all about the upper layers at all. I would argue that it would be quite difficult, given the current state of geom, to properly guess. It shouldn't even try. Bad things can only come from accidentally guessing wrong. Instead, if you really want this functionality, we should create either an ioctl to get this information (perhaps in a list for the case of gmirror, but perhaps not) or a bio attribute that could be synthesized properly. The third vehicle for this would be to put the attribute in the config for geom, but that's a bit of a pain. Then again, you can't easily map an entry from /dev into a device_t that implements it (if any). You can't map a cam device, even, to a device_t either, just as far as the SIM if you look hard enough. Warner From owner-freebsd-geom@freebsd.org Tue Sep 12 14:12:39 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 845F2E0B7B6 for ; Tue, 12 Sep 2017 14:12:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D2C857368F for ; Tue, 12 Sep 2017 14:12:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA13276; Tue, 12 Sep 2017 17:12:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1drlvX-000NyK-9M; Tue, 12 Sep 2017 17:12:35 +0300 Subject: Re: "unspoilable" geom labels To: Warner Losh Cc: freebsd-geom@FreeBSD.org References: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> From: Andriy Gapon Message-ID: <62cda94e-751d-3d59-914c-c5242a8f1d81@FreeBSD.org> Date: Tue, 12 Sep 2017 17:11:39 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:12:39 -0000 On 12/09/2017 16:28, Warner Losh wrote: > I recently added aliases, and the thought was that once the kinks are worked out > they could also be used for labels and we could eliminate the extra geom nodes. I noticed that change, thanks! There is one thing that, in my opinion, is not perfect about the aliases unless I misunderstand the code. It's that unlike the current approach the aliasing is not automatically propagated up the GEOM graph and each geom class needs to be made aware of the aliases. I mean that currently we create a new geom that carries the label name and all the tasting, etc automatically happens for. It has its own problems as we know, but there is a lot of auto-magic too. With the aliases there are no additional geoms, so any classes attaching on top of geoms with aliases need to handle the aliases. E.g. the partition classes need to create an alias for each partition, etc. Also, the aliases seem to be rather adequate for the userland consumers, but they seem to be not as convenient for the in-kernel consumers that expect the names to be names of GEOM providers. But maybe I am extrapolating too much from the existing code and the bigger design for the GEOM aliases handles the mentioned issues. -- Andriy Gapon From owner-freebsd-geom@freebsd.org Tue Sep 12 14:21:52 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18A06E0BD80; Tue, 12 Sep 2017 14:21:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE6973B45; Tue, 12 Sep 2017 14:21:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA13294; Tue, 12 Sep 2017 17:21:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1drm4Q-000Nyp-9w; Tue, 12 Sep 2017 17:21:46 +0300 Subject: Re: "unspoilable" geom labels To: Warner Losh Cc: freebsd-geom@FreeBSD.org, freebsd-scsi@FreeBSD.org References: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Tue, 12 Sep 2017 17:20:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:21:52 -0000 On 12/09/2017 16:28, Warner Losh wrote: > The CAM code expects to be able to map the name 'da0' to 'pass14' so it can send > the passthrough devices. It has no clue about device names, apart from passXXX > it has to open to send the commands for the thing named 'da0'. In fact, it has > no clue at all about the upper layers at all. I would argue that it would be > quite difficult, given the current state of geom, to properly guess. It > shouldn't even try. Bad things can only come from accidentally guessing wrong. I mean that maybe it's not exactly the job of a function like cam_get_device(), maybe it's a job if its callers (like camcontrol), but at the very least we could check if /dev/$name is a symlink and resolve it. I assume that the valid device names always corresponding devices entries under /dev. And, yes, mapping a GEOM label to an original name is harder than it should be with the current implementation. Maybe it would be easier with labels implemented as aliases. > Instead, if you really want this functionality, we should create either an ioctl > to get this information (perhaps in a list for the case of gmirror, but perhaps > not) or a bio attribute that could be synthesized properly. The third vehicle > for this would be to put the attribute in the config for geom, but that's a bit > of a pain. I agree. Maybe such a method would be a good thing to have regardless of the labels implementation. > Then again, you can't easily map an entry from /dev into a device_t that > implements it (if any). You can't map a cam device, even, to a device_t either, > just as far as the SIM if you look hard enough. I think that this is a little bit different issue. I think that getting from e.g. /dev/diskid/DISK-MK0351YVKNNX3A to e.g. /dev/ada77 should be sufficient for most userland utilities. -- Andriy Gapon From owner-freebsd-geom@freebsd.org Thu Sep 14 17:00:15 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13A27E246AA for ; Thu, 14 Sep 2017 17:00:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 024A0D2C for ; Thu, 14 Sep 2017 17:00:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8EH0CBJ093985 for ; Thu, 14 Sep 2017 17:00:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 205343] [panic] [geom] [gjournal] g_journal KASSERT triggers for stable/10 Date: Thu, 14 Sep 2017 17:00:13 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 17:00:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205343 --- Comment #7 from Eugene Grosbein --- (In reply to longwitz from comment #3) A months has passed since I run this patch with my 11.1-STABLE workstation having multiple gjournals with INVARIANTS-enabled kernel and problem seems = to be gone. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-geom@freebsd.org Thu Sep 14 18:03:02 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41222E01A80 for ; Thu, 14 Sep 2017 18:03:02 +0000 (UTC) (envelope-from celina.ross@microdigitaldata.com) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-ma1ind01on0042.outbound.protection.outlook.com [104.47.100.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 948CD3B73 for ; Thu, 14 Sep 2017 18:03:01 +0000 (UTC) (envelope-from celina.ross@microdigitaldata.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2124313.onmicrosoft.com; s=selector1-microdigitaldata-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vktHtCyJERYzTAKC/EIn5iTy4AN38FJ7p+mrwe82vEI=; b=rOLbzD1fNyrWh2BTqN5pNTcgZlYq8es0KrpM4sytenlUReZf0kXCDh/bjBhvP0zBukfSa7l5RFGTtKoD/ZcGXzMdS+mERACHbUTLivi7/5jcplB3x4Iz/+KGLriUARRkviIuHYL8Y1gLcmk7JKsmbc0rwVtslZEcM86oVS73MR4= Received: from MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM (10.174.57.143) by MA1PR01MB0938.INDPRD01.PROD.OUTLOOK.COM (10.174.59.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 14 Sep 2017 18:02:57 +0000 Received: from MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM ([10.174.57.143]) by MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM ([10.174.57.143]) with mapi id 15.20.0056.010; Thu, 14 Sep 2017 18:02:57 +0000 From: Celina Ross To: "freebsd-geom@freebsd.org" Subject: Dell/EMC Users List Thread-Topic: Dell/EMC Users List Thread-Index: AdMtgc14JP9GlK+0QSa5Vx777mgPKw== Importance: high X-Priority: 1 Date: Thu, 14 Sep 2017 17:49:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=celina.ross@microdigitaldata.com; x-originating-ip: [49.207.51.177] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MA1PR01MB0938; 6:rBEW07ez2DKyLkEwhVIBnOqZ0YaJoxfe8jq5/KzArm/rgeeZ6Wy6tWSEHUAgXZzE/yHe6vX9XLUf2gqluww/0vbvN2PYxUgUbxxLDydwglDZaiv9PHcupxQtGg24nucT1AgaXGfDs4UKByVOKYtOjkGWIPAQS1UL/ZsK6C47qXA5eouP1ouV2JfZ1CabZx3fGqoKTcC/pYQ+HK9CODCwZwBP8OAUHKOG/bFtyv9wfa4rXml0pW02QETT+6Krhg6GX9UvZZ82oKY5oRCe0Bt2dS2+mYSld1duqpxnlWqwoJr8emuqBiVZXokhDjvS1Vpj5bCiPZdDJDBeAghfprDwvQ==; 5:tagmTuimxPCFydQfj/EzmXD+wby4jWkYg0j/uR8s4Ig92oVQtqt5bpbRmOv+R7M1uMjek08zaDdqjqJ2sRNW0/PJpLJjJ8z3RSId37Rwq9qBf2cALfTTG3t83jBRVFkAdJUgVI4EeyQY27dqDc/Wdg==; 24:ANcUHK929tO0asir0BXHdNnMN9PAr2tvSlDLT0SNVg5m7gqprmu/Bhf+3ttAdWr4Kp4mdtK+BXG/WiSlUOV9K3q+ap/1jgylcyUF6/9YIzA=; 7:xRr1X8tJAUSbnP4rzp5ptfb8jzQ4S1Tl/ELxHDWMUCca9rV/56hLqLUnUI88zlcPMvZ+24ygts4uQzQftVe8t5IyVGZBX8VjHaZf2pXLz1kLXxZRuv2Xad8tNdNp4wQ94G05ghYLDWFdRo6hGsp9/JEQbc7YcF203WgeK3zjp/QGO3eIV2Y5k3w+uhbZoquC6eDYRgVbcRWDY2iP/j+aM1lnid42sEBcHUvQNbs0oco= x-ms-office365-filtering-correlation-id: 2c10ff65-4ea4-4282-584f-08d4fb9ad43c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(201703131423075)(201702281549075)(201702085551020)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MA1PR01MB0938; x-ms-traffictypediagnostic: MA1PR01MB0938: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MA1PR01MB0938; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MA1PR01MB0938; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(189998001)(7696004)(74316002)(478600001)(2501003)(8676002)(5660300001)(86362001)(6916009)(53936002)(54356999)(81686999)(50986999)(110136004)(3846002)(102836003)(6116002)(101416001)(45080400002)(7736002)(106356001)(790700001)(66066001)(55016002)(5630700001)(68736007)(5640700003)(14454004)(2906002)(105586002)(316002)(626008)(2900100001)(97736004)(25786009)(54896002)(77096006)(8936002)(6306002)(33656002)(81156014)(2351001)(6436002)(81166006)(3480700004)(9686003)(3280700002)(5180700001)(6506006)(6666003)(3660700001)(19870200002); DIR:OUT; SFP:1101; SCL:1; SRVR:MA1PR01MB0938; H:MA1PR01MB0714.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microdigitaldata.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microdigitaldata.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 17:49:15.5296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 59b840ce-fb2a-4139-af60-da12547b61a4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB0938 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 18:03:02 -0000 Hello there, Hope you having a great day! Would you be interested in acquiring the list of customers or companies usi= ng Dell/EMC Users List? We also have other database Like: Spotfire, WebMethods, Informatica, Tablea= u Software, Pegasystems, Jaspersoft, Talend, Boomi, Teradata, MuleSoft, App= ian, siebel, Apigee, StreamBase Systems, LogLogic, oracle, Microsoft, Micro= Strategy, SAP BusinessObjects, Software AG, Sybase, SAS Institute, Salesfor= ce and many more... Please share your business email address and contact number if you are inte= rested to get some samples (at no cost) for your review. Await your response! Thanks, Celina Ross Demand Generation- Technology Database To Opt Out, please respond "Leave Out" in the Subject line.