From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 10:28:57 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6797C416 for ; Sun, 15 Sep 2013 10:28:57 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by mx1.freebsd.org (Postfix) with ESMTP id CD20429AF for ; Sun, 15 Sep 2013 10:28:56 +0000 (UTC) Received: from cpsps-ews01.kpnxchange.com ([10.94.84.168]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 12:27:45 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 12:27:45 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sun, 15 Sep 2013 12:27:45 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 8889116AB8 for ; Sun, 15 Sep 2013 12:27:44 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: Mounting from zfs failed with error 22 with gmirror References: <5234BE9E.1030308@FreeBSD.org> Date: Sun, 15 Sep 2013 12:27:44 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <5234BE9E.1030308@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 15 Sep 2013 10:27:45.0175 (UTC) FILETIME=[37875A70:01CEB1FE] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 10:28:57 -0000 On Sat, 14 Sep 2013 21:53:02 +0200, Daniel Gerzo wrote: > Hello list, > > I have come across this thing and I don't have an idea what to do next. > > I have this partition setup: > > [root@rescue ~]# gpart show > => 34 3907029101 ada0 GPT (1.8T) > 34 6 - free - (3.0k) > 40 1024 1 freebsd-boot (512k) > 1064 83886080 2 freebsd-swap (40G) > 83887144 3823141984 3 freebsd-zfs (1.8T) > 3907029128 7 - free - (3.5k) > > => 34 3907029101 ada1 GPT (1.8T) > 34 6 - free - (3.0k) > 40 1024 1 freebsd-boot (512k) > 1064 83886080 2 freebsd-swap (40G) > 83887144 3823141984 3 freebsd-zfs (1.8T) > 3907029128 7 - free - (3.5k) > > [root@rescue ~]# gpart show -l > => 34 3907029101 ada0 GPT (1.8T) > 34 6 - free - (3.0k) > 40 1024 1 boot0 (512k) > 1064 83886080 2 swap0 (40G) > 83887144 3823141984 3 sys0 (1.8T) > 3907029128 7 - free - (3.5k) > > => 34 3907029101 ada1 GPT (1.8T) > 34 6 - free - (3.0k) > 40 1024 1 boot1 (512k) > 1064 83886080 2 swap1 (40G) > 83887144 3823141984 3 sys1 (1.8T) > 3907029128 7 - free - (3.5k) > [root@rescue ~]# zpool import -f -o altroot=/mnt -o > cachefile=/boot/zfs/zpool.cache sys > [root@rescue ~]# zpool status > pool: sys > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > sys ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/sys0 ONLINE 0 0 0 > gpt/sys1 ONLINE 0 0 0 > > errors: No known data errors > [root@rescue ~]# zdb > sys: > version: 28 > name: 'sys' > state: 0 > txg: 13622 > pool_guid: 13749191682008517984 > hostid: 966392425 > hostname: 'rescue' > vdev_children: 1 > vdev_tree: > type: 'root' > id: 0 > guid: 13749191682008517984 > children[0]: > type: 'mirror' > id: 0 > guid: 10821644781744913225 > metaslab_array: 30 > metaslab_shift: 34 > ashift: 12 > asize: 1957443928064 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 12516881521540558071 > path: '/dev/gpt/sys0' > phys_path: '/dev/gpt/sys0' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 187152467666907385 > path: '/dev/gpt/sys1' > phys_path: '/dev/gpt/sys1' > whole_disk: 1 > create_txg: 4 > [root@rescue ~]# zpool get bootfs sys > NAME PROPERTY VALUE SOURCE > sys bootfs sys/default/root local > [root@rescue ~]# gmirror status > Name Status Components > mirror/swap COMPLETE ada1p2 (ACTIVE) > ada0p2 (ACTIVE) > > The problem is that while I do not load geom_mirror from loader.conf, > the machine boots fine, however as soon as I enable gmirror in > loader.conf the machine doesn't boot and errors with > > /Trying to mount root from zfs:sys/default/root [].../ > > /Mounting from zfs:sys/default/root failed with error 22. > / > > > and it hangs in the prompt asking me to enter device to mount root from. > > I found only this > http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037910.html > email where avg@ mentions that it might be a bug in his code, but no > further followups. However that is almost a year ago and I got trapped > by this on 9.2-RC4. > > Could anyone possibly give me some hints? (Please keep in in cc: as I am > not subscribed to fs@) > > Thank you in advance! > > Kind regards, > Daniel Is it possible you used these disks with gmirror in the past and you did not correctly clean the meta-data from the disks when you started using zfs? So gmirror now detects meta-data, starts handling the disks in some way and zfs does not get all the sectors of the disk it is expecting? Ronald. From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 13:36:15 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8266FD3C for ; Sun, 15 Sep 2013 13:36:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33A5321F4 for ; Sun, 15 Sep 2013 13:36:15 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r8FDa742044901; Sun, 15 Sep 2013 07:36:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r8FDa7WN044898; Sun, 15 Sep 2013 07:36:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 15 Sep 2013 07:36:07 -0600 (MDT) From: Warren Block To: Ronald Klop Subject: Re: Mounting from zfs failed with error 22 with gmirror In-Reply-To: Message-ID: References: <5234BE9E.1030308@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 15 Sep 2013 07:36:07 -0600 (MDT) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 13:36:15 -0000 On Sun, 15 Sep 2013, Ronald Klop wrote: > Is it possible you used these disks with gmirror in the past and you did not > correctly clean the meta-data from the disks when you started using zfs? > So gmirror now detects meta-data, starts handling the disks in some way and > zfs does not get all the sectors of the disk it is expecting? Both the gmirrored swap and the ZFS mirror are using individual partitions, so a metadata conflict is less likely than with entire disks. Error 22 is EINVAL. Maybe GEOM is hiding label or partition names because of the gmirror mount, then ZFS can't find the members of the zmirror. Booting from a liveCD, loading ZFS and gmirror, then looking at partition names and labels might show what is missing. There is a version of mfsBSD (http://mfsbsd.vx.sk/) with ZFS. From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 14:16:03 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A51917D9; Sun, 15 Sep 2013 14:16:03 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 640B023BB; Sun, 15 Sep 2013 14:16:03 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id as1so5848168iec.35 for ; Sun, 15 Sep 2013 07:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZjKB2FGfJYgqGVGEQPVWmgT8hAIk5/BSoNHWMThtkPA=; b=LIR0cKffOZJ13T8CjBNAFNnSom83RkNk5t4sM0XC0VtBlL0S6nohRdXE1o/dz9s8lV 0np7WHwWxqr8npxHgbSjbMjUIwKe2hYOrRgLV8wobHLkzXGjn/6+Frskt6F4umgySieg pZcoELZSepXrUQ3I5EJwomqCdU0Loq9dCvlbuuPnAT8vKMYlhje454JOIeHLMw4eLLTz puOIGtP8le3dXHfA9/opxAz1w4esdyZRx55BX/Zk4WqS+hrrsjQpRMlkzSM8vbZgGu9H IndDprt8SmZpXIxjFK3GTDa/Eqm9QX8YR5WRpOZejkGL/AIadJ2c84X9KpspwwFQPsp7 yCdg== MIME-Version: 1.0 X-Received: by 10.50.66.101 with SMTP id e5mr4805324igt.26.1379254562451; Sun, 15 Sep 2013 07:16:02 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Sun, 15 Sep 2013 07:16:02 -0700 (PDT) In-Reply-To: <52331179.4030201@FreeBSD.org> References: <523310E2.4050702@FreeBSD.org> <52331179.4030201@FreeBSD.org> Date: Sun, 15 Sep 2013 10:16:02 -0400 X-Google-Sender-Auth: vhrFkWX812s-mLA2bKILTXrVHto Message-ID: Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) From: J David To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:16:03 -0000 Thanks very much for the info Andriy. On Fri, Sep 13, 2013 at 9:22 AM, Andriy Gapon wrote: > Another piece of information is that neither mountpoint nor canmount property > affects ZFS root mounting. It is mountpoint=legacy that boots on this machine and mountpoint=/ that can't find init, with no other changes. So clearly under some obscure edge case, this is not strictly correct. Did your test include zpool root != filesystem root? Because as you describe one possible cause of the problem is mounting the wrong filesystem as root, one wonders if somehow with the mountpoint=/ setting the zpool root (which has no files at all) is incorrectly being chosen as fsroot with mountpoint=/ on data/root. I.e. perhaps somewhere in the code is looking for "legacy" (or skipping anything with a mountpoint set) and defaulting back to the zpool root if it is not found? Unfortunately there is no way I know of to check and see what the root filesystem turned out to be after the failure to find init. That would reduce speculation about what is happening quite a bit. Can the kernel debugger extract this info? If it matters, the pools in question are fairly complex, not just throwing everything possible on one drive. Example: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0p2 ONLINE 0 0 0 da4p2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 da1p2 ONLINE 0 0 0 da5p2 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 da2p2 ONLINE 0 0 0 da6p2 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 da3p2 ONLINE 0 0 0 da7p2 ONLINE 0 0 0 logs ada0p2 ONLINE 0 0 0 cache ada1p2 ONLINE 0 0 0 The boot order for that system begins at either ada0 or da0, not sure which without checking the BIOS. Thanks! From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 15:14:12 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 362274FD; Sun, 15 Sep 2013 15:14:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6C5265C; Sun, 15 Sep 2013 15:14:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07263; Sun, 15 Sep 2013 18:14:08 +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 1VLE1X-0009R4-TQ; Sun, 15 Sep 2013 18:14:07 +0300 Message-ID: <5235CE87.2090607@FreeBSD.org> Date: Sun, 15 Sep 2013 18:13:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: J David Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <523310E2.4050702@FreeBSD.org> <52331179.4030201@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 15:14:12 -0000 on 15/09/2013 17:16 J David said the following: > Thanks very much for the info Andriy. > > On Fri, Sep 13, 2013 at 9:22 AM, Andriy Gapon wrote: >> Another piece of information is that neither mountpoint nor canmount property >> affects ZFS root mounting. > > It is mountpoint=legacy that boots on this machine and mountpoint=/ > that can't find init, with no other changes. So clearly under some > obscure edge case, this is not strictly correct. I am sure that the same can be said about almost anything documented about any software... > Did your test include zpool root != filesystem root? Because as you > describe one possible cause of the problem is mounting the wrong > filesystem as root, one wonders if somehow with the mountpoint=/ > setting the zpool root (which has no files at all) is incorrectly > being chosen as fsroot with mountpoint=/ on data/root. I.e. perhaps > somewhere in the code is looking for "legacy" (or skipping anything > with a mountpoint set) and defaulting back to the zpool root if it is > not found? I tried to reproduce with exactly the same configuration as you described. To be specific, yes I used data/root as a root filesystem and I set its mountpoint to "/". > Unfortunately there is no way I know of to check and see what the root > filesystem turned out to be after the failure to find init. That > would reduce speculation about what is happening quite a bit. Can the > kernel debugger extract this info? Unfortunately, I am not sure if it is possible to obtain anu useful information from ddb and saving a crash dump is not possible in pre-init environment. I could write a patch that would print some useful debugging info. Will you able to use it? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 20:56:50 2013 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 027F4574; Sun, 15 Sep 2013 20:56:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD4C2560; Sun, 15 Sep 2013 20:56:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA10209; Sun, 15 Sep 2013 23:56:44 +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 1VLJN5-0009vS-Ql; Sun, 15 Sep 2013 23:56:43 +0300 Message-ID: <52361ED3.9070408@FreeBSD.org> Date: Sun, 15 Sep 2013 23:55:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Daniel Gerzo Subject: Re: Mounting from zfs failed with error 22 with gmirror References: <5234BE9E.1030308@FreeBSD.org> In-Reply-To: <5234BE9E.1030308@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 20:56:50 -0000 on 14/09/2013 22:53 Daniel Gerzo said the following: > The problem is that while I do not load geom_mirror from loader.conf, the > machine boots fine, however as soon as I enable gmirror in loader.conf the > machine doesn't boot and errors with > > /Trying to mount root from zfs:sys/default/root [].../ > > /Mounting from zfs:sys/default/root failed with error 22. > / > > > and it hangs in the prompt asking me to enter device to mount root from. > > I found only this > http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037910.html > email where avg@ mentions that it might be a bug in his code, but no further > followups. However that is almost a year ago and I got trapped by this on 9.2-RC4. At that time there was a specific new change committed and I already had a report about the kind of configurations that were broken by that change. So far, I have no idea what could cause your problem. You may want to try the following diagnostic patch: http://people.freebsd.org/~avg/zfs-root-pool-config-debug.patch If your kernel configuration doesn't have INVARIANTS then you can either add that or remove DEBUG check around the added code. Please enable verbose boot, set vfs.zfs.debug and kern.geom.mirror.debug (in loader.conf or at its prompt) and try to capture any interesting geom and ZFS related messages. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 21:09:47 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 472C4714 for ; Sun, 15 Sep 2013 21:09:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 96A6925E5 for ; Sun, 15 Sep 2013 21:09:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA10378; Mon, 16 Sep 2013 00:09:41 +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 1VLJZd-0009wV-LO; Mon, 16 Sep 2013 00:09:41 +0300 Message-ID: <523621DD.7050600@FreeBSD.org> Date: Mon, 16 Sep 2013 00:08:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andreas Longwitz Subject: Re: zfs panic during find(1) on zfs snapshot directory References: <522DF5A9.4070103@incore.de> <522E0118.5020106@FreeBSD.org> <522F25AE.1080309@incore.de> In-Reply-To: <522F25AE.1080309@incore.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 21:09:47 -0000 on 10/09/2013 16:59 Andreas Longwitz said the following: > Thanks for quick answer ! > >> My personal recommendation is to keep .zfs directory hidden and/or perform only >> basic operations on entries under it while ensuring that there is only one >> process at a time that peeks there. >> >> The gfs stuff that handles .zfs operations is really very broken on FreeBSD[*]. >> If you are interested, I have a patch that should some of the mess, but not all. >> >> [*] To see what I mean run several of the following shell loops in parallel: >> while true; do ls -l /pool/fs/.zfs/ >/dev/null; done > > Ok, I was not aware of the problematic caused by visible snapdir > property. I think your recommendation to use the default snapdir > property hidden is fine for me and the panic I have described will not > happen again. > > On the other side a panic should not happen when a user configures > something else than the default. Therefore I am interested in helping to > test the broken gfs stuff on some of my test servers, so your offered > patch is welcome. Please try this patch: http://people.freebsd.org/~avg/zfs-gfs-8.diff Thank you! > I run zfs on production for a half year now, and I like to note that > this panic was the first problem on all of my (eight) production servers > running zfs. The only open zfs problem I have is described in kern/180060. > I will try to look into this issue. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Sep 15 23:21:08 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1854CD3 for ; Sun, 15 Sep 2013 23:21:08 +0000 (UTC) (envelope-from olevole@olevole.ru) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 373E32B95 for ; Sun, 15 Sep 2013 23:21:07 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ev20so2499273lab.8 for ; Sun, 15 Sep 2013 16:21:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding:content-type; bh=4xQSK59Qc3y2mBZSRolut8/0jeumvnSHNgO2618gc8w=; b=jumKgTICZ0tLViNE3TeNbg+/kXHD+PrCdnj7HufbFow5cwAAcL4Fd+t190RON5R8L2 AH+s6Go9c5EvtsmAteBY3LqbSae3S91U3yxwg8AeUG4YRW6NLRX8uZ3rCfoRygOAqHBn 80Ygjq/Xu65hBhJaokH0b0o6KvxM3Rr8ujwo60OwxpZhtGGaJDG0zRJjdWEyIX5xQkQb /p7xa2asP+FZFEi7EDg5vkZ5HOhmexLcT6t2GYIm+03eX8OR5dZMv4peH+Ty5dHwmPEf 2eQGMyIdvZWcwuzjr8N9RG+l+QcOoo3W+AibBU2O0CXfBScljRB8TYEwOjP5w90GSN6N rBjg== X-Gm-Message-State: ALoCoQmeeJCkbnFqQoKUeXu9uc5poeAalTYBfKIVJsgq0fiizlmDKdmrA0OLrClhn3XDVv+HKpLU X-Received: by 10.152.36.98 with SMTP id p2mr22169266laj.14.1379287265523; Sun, 15 Sep 2013 16:21:05 -0700 (PDT) Received: from home.my.domain (nat-server-217.15.27.35.static.futures.ru. [217.15.27.35]) by mx.google.com with ESMTPSA id vx8sm11520967lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 16:21:04 -0700 (PDT) From: Oleg Ginzburg To: freebsd-fs@freebsd.org Subject: linkat(2) Operation not permitted Date: Sun, 15 Sep 2013 16:21:04 -0700 (PDT) Message-ID: <2628598.ea1ZiWMKQv@home.my.domain> User-Agent: KMail/4.10.5 (FreeBSD/10.0-CURRENT; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 23:21:08 -0000 Hi For some reason, creating hardlink within one UFS is failed for /usr/bin/chfn with "operation not permitted" messages (other file is ok) Looks like is UFS-specific because on another system with close revision all fine. system1, zfs, normal behavior: --- % uname -a FreeBSD fbsd.my.domain 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255570: Sat Sep 14 22:35:46 MSK 2013 root@fbsd.my.domain:/usr/obj/usr/src/sys/kernel-GENERIC- amd64-10.0 amd64 % file -s /usr/bin/chfn && ls -la /usr/bin/chfn /usr/bin/chfn: setuid ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped -r-sr-xr-x 6 root wheel 22264 Sep 14 22:25 /usr/bin/chfn % ln -f /usr/bin/chfn ole -- system2, ufs: --- % uname -a FreeBSD acer.my.domain 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #0 r255601: Mon Sep 16 02:38:06 MSK 2013 root@acer.my.domain:/usr/obj/usr/src/sys/GENERIC amd64 % mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) % pwd /root % whoami root % file -s /usr/bin/chfn && ls -la /usr/bin/chfn /usr/bin/chfn: setuid ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped -r-sr-xr-x 6 root wheel 22264 Sep 16 02:25 /usr/bin/chfn % ln -f /usr/bin/chfn ole ln: ole: Operation not permitted % truss ln -f /usr/bin/chfn ole mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366140416 (0x80061b000) issetugid(0x80081ba10,0x7fffffffefd8,0x40,0x0,0xffff80080081ca38,0x0) = 0 (0x0) lstat("/etc",{ mode=drwxr-xr-x ,inode=26323968,size=2048,blksize=32768 }) = 0 (0x0) lstat("/etc/libmap.conf",{ mode=-rw-r--r-- ,inode=26324055,size=102,blksize=32768 }) = 0 (0x0) open("/etc/libmap.conf",O_CLOEXEC,01760) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=26324055,size=102,blksize=32768 }) = 0 (0x0) mmap(0x0,102,PROT_READ,MAP_PRIVATE,3,0x0) = 34366173184 (0x800623000) close(3) = 0 (0x0) lstat("/usr",{ mode=drwxr-xr-x ,inode=11797632,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local",{ mode=drwxr-xr-x ,inode=11797634,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local/etc",0x7fffffffb708) ERR#2 'No such file or directory' munmap(0x800623000,102) = 0 (0x0) open("/var/run/ld-elf.so.hints",O_CLOEXEC,00) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80) lseek(3,0x80,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat\0",30) = 30 (0x1e) close(3) = 0 (0x0) access("/lib/libc.so.7",0) = 0 (0x0) open("/lib/libc.so.7",O_CLOEXEC,030373770) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=5377218,size=1560208,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366173184 (0x800623000) mmap(0x0,3772416,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34368245760 (0x80081d000) mmap(0x80081d000,1458176,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE| MAP_PREFAULT_READ,3,0x0) = 34368245760 (0x80081d000) mmap(0x800b81000,49152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED| MAP_PREFAULT_READ,3,0x164000) = 34371801088 (0x800b81000) mmap(0x800b8d000,167936,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED| MAP_ANON,-1,0x0) = 34371850240 (0x800b8d000) munmap(0x800623000,4096) = 0 (0x0) close(3) = 0 (0x0) munmap(0x800622000,4096) = 0 (0x0) mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366169088 (0x800622000) sysarch(0x81,0x7fffffffd0f8,0x4,0x0,0xffffffffffab3080,0x8080808080808080) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf","abort:false,junk:false",1024) = 22 (0x16) issetugid(0x800956e53,0x7fffffffc836,0x0,0x0,0x40,0xffffffff0fffffff) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34372018176 (0x800bb6000) munmap(0x800bb6000,4194304) = 0 (0x0) mmap(0x0,8384512,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34372018176 (0x800bb6000) munmap(0x800bb6000,303104) = 0 (0x0) munmap(0x801000000,3887104) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) stat("/usr/bin/chfn",{ mode=-r-sr-xr-x ,inode=11798245,size=22264,blksize=32768 }) = 0 (0x0) lstat("ole",0x7fffffffc8a8) ERR#2 'No such file or directory' stat("ole",0x7fffffffc8a8) ERR#2 'No such file or directory' lstat("ole",0x7fffffffc8a8) ERR#2 'No such file or directory' linkat(0xffffff9c,0x7fffffffddb6,0xffffff9c,0x7fffffffddc4,0x400,0x8080808080808080) ERR#1 'Operation not permitted' ln: write(2,"ln: ",4) = 4 (0x4) olewrite(2,"ole",3) = 3 (0x3) : write(2,": ",2) = 2 (0x2) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34376515584 (0x801000000) stat("/usr/share/nls/C/libc.cat",0x7fffffffc238) ERR#2 'No such file or directory' stat("/usr/share/nls/libc/C",0x7fffffffc238) ERR#2 'No such file or directory' stat("/usr/local/share/nls/C/libc.cat",0x7fffffffc238) ERR#2 'No such file or directory' stat("/usr/local/share/nls/libc/C",0x7fffffffc238) ERR#2 'No such file or directory' madvise(0x801006000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x801000030,0x800bb4ab0) = 0 (0x0) madvise(0x801007000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffb740,0x800bb4ab0) = 0 (0x0) Operation not permitted write(2,"Operation not permitted\n",24) = 24 (0x18) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM| SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ| SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) process exit, rval = 1 --- PS: On system2 ive use default kern_securelevel="-1" PPS: same behavior on 9.1-RELEASE/ufs From owner-freebsd-fs@FreeBSD.ORG Mon Sep 16 06:39:11 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6439EC05; Mon, 16 Sep 2013 06:39:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB3E209A; Mon, 16 Sep 2013 06:39:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA15256; Mon, 16 Sep 2013 09:38:55 +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 1VLSSV-000DZN-EW; Mon, 16 Sep 2013 09:38:55 +0300 Message-ID: <5236A747.5020303@FreeBSD.org> Date: Mon, 16 Sep 2013 09:37:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: kpneal@pobox.com Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) References: <523310E2.4050702@FreeBSD.org> <52331179.4030201@FreeBSD.org> <20130916044235.GA42673@neutralgood.org> In-Reply-To: <20130916044235.GA42673@neutralgood.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 06:39:11 -0000 on 16/09/2013 07:42 kpneal@pobox.com said the following: > What happens if mountpoint is inherited instead of being set to one of > those two values? Would you like to test this and tell us? I am 99.9% confident that mountpoint and canmount properties are never examined in kernel. They are honored only by zfs(8) utility. Thus, they can not possibly influence root mounting. Modulo very very very obscure bugs, of course. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Sep 16 11:06:44 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A0A3BAC for ; Mon, 16 Sep 2013 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC979214D for ; Mon, 16 Sep 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8GB6h9K089592 for ; Mon, 16 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8GB6hLk089590 for freebsd-fs@FreeBSD.org; Mon, 16 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Sep 2013 11:06:43 GMT Message-Id: <201309161106.r8GB6hLk089590@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS o kern/178713 fs [nfs] [patch] Correct WebNFS support in NFS server and s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/178103 fs [kernel] [nfs] [patch] Correct support of index files o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 337 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 16 13:10:06 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4B871F5; Mon, 16 Sep 2013 13:10:06 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBAD2C19; Mon, 16 Sep 2013 13:10:05 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 2B97A51FB; Mon, 16 Sep 2013 15:10:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id k0RJmfpPEk9s; Mon, 16 Sep 2013 15:09:58 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) by services.syscare.sk (Postfix) with ESMTP id A04A251E8; Mon, 16 Sep 2013 15:09:58 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 Sep 2013 15:09:58 +0200 From: Daniel Gerzo To: Andriy Gapon Subject: Re: Mounting from zfs failed with error 22 with gmirror Organization: The FreeBSD Project In-Reply-To: <52361ED3.9070408@FreeBSD.org> References: <5234BE9E.1030308@FreeBSD.org> <52361ED3.9070408@FreeBSD.org> Message-ID: <721cb12d0577b20515e70d0b92eea558@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.7.2 Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:10:06 -0000 Hello Andriy, I have applied your patch but unfortunately I cannot get much out of it. Interestingly, when I built a custom, stripped down kernel, I could boot that box even with gmirror setup, however GENERIC fails with the mentioned error. The stripped-down config looks like this: cpu HAMMER ident ALICE makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options KDTRACE_FRAME # Ensure frames are compiled in options INCLUDE_CONFIG_FILE # Include this file in kernel options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic options DDB_CTF # kernel ELF linker loads CTF data options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device fdc device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering # output. Adds ~128k to driver. # output. Adds ~215k to driver. device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support device sc options SC_PIXEL_MODE # add support for the raster text mode device agp # support several AGP chipsets device uart # Generic UART driver device bxe # Broadcom BCM57710/BCM57711/BCM57711E 10Gb Ethernet device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgbe # Intel PRO/10GbE PCIE Ethernet Family device le # AMD Am7900 LANCE and Am79C9xx PCnet device ti # Alteon Networks Tigon I/II gigabit Ethernet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') device miibus # MII bus support device re # RealTek 8139C+/8169/8169S/8110S device loop # Network loopback device random # Entropy device options PADLOCK_RNG # VIA Padlock RNG options RDRAND_RNG # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device bpf # Berkeley packet filter options USB_DEBUG # enable debug msgs device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP options ACCEPT_FILTER_DNS options GEOM_MIRROR options NULLFS device pf device pflog makeoptions MODULES_OVERRIDE="zfs opensolaris krpc" When I built GENERIC kernel with your patch, I couldn't extract much info because for some reason the keyboard of my remote console doesn't work on 9.2, due to some USB bug :-( and thus I couldn't paginate the screen output. Obviously, it didn't get logged, too. On 2013-09-15 22:55, Andriy Gapon wrote: > on 14/09/2013 22:53 Daniel Gerzo said the following: >> The problem is that while I do not load geom_mirror from loader.conf, >> the >> machine boots fine, however as soon as I enable gmirror in >> loader.conf the >> machine doesn't boot and errors with >> >> /Trying to mount root from zfs:sys/default/root [].../ >> >> /Mounting from zfs:sys/default/root failed with error 22. >> / >> >> >> and it hangs in the prompt asking me to enter device to mount root >> from. >> >> I found only this >> http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037910.html >> email where avg@ mentions that it might be a bug in his code, but no >> further >> followups. However that is almost a year ago and I got trapped by >> this on 9.2-RC4. > > At that time there was a specific new change committed and I already > had a > report about the kind of configurations that were broken by that > change. > > So far, I have no idea what could cause your problem. > > You may want to try the following diagnostic patch: > http://people.freebsd.org/~avg/zfs-root-pool-config-debug.patch > If your kernel configuration doesn't have INVARIANTS then you can > either add > that or remove DEBUG check around the added code. > Please enable verbose boot, set vfs.zfs.debug and > kern.geom.mirror.debug (in > loader.conf or at its prompt) and try to capture any interesting geom > and ZFS > related messages. -- Kind regards Daniel From owner-freebsd-fs@FreeBSD.ORG Mon Sep 16 19:26:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 15E15B3B; Mon, 16 Sep 2013 19:26:35 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7CA92719; Mon, 16 Sep 2013 19:26:34 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so8154688ieb.40 for ; Mon, 16 Sep 2013 12:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=stk4KotbGHQ+KXyddxRUmE0eaoTesF3lcw7bDqzbCNI=; b=KQI646rP7iBMSHs625iFQEX9vtLjL1TzJ2SofLOJad1UeT8O7VmRykajXXF7sJS0dN 3HrQAU3ceCfksJz1XDLmP3OpzGB2X9pw41yZGiQumK/qeI+YsYC9TFtigzwqDnbvgawS TAyKaoHrt0SFZ3Q1SSejvzY35PUWgB+kbS7ywT3iMBSNPK8r5+fbaVA35Is5eQ46ZzUS bUFkrzgVGTN0SFT5RHWOxWR81XWjcLhDb6w0FC/EZTWsO6ncYu4epXMLqrznA4evtUnO rohLQrKE6MqEs6GGTovbZjq6FqJXvnhSPU/mknB/eMOT6t5LNMln3KtGFh4fXOih+0XZ PAxA== MIME-Version: 1.0 X-Received: by 10.50.72.33 with SMTP id a1mr6736220igv.58.1379359594370; Mon, 16 Sep 2013 12:26:34 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.157.8 with HTTP; Mon, 16 Sep 2013 12:26:34 -0700 (PDT) In-Reply-To: <5235CE87.2090607@FreeBSD.org> References: <523310E2.4050702@FreeBSD.org> <52331179.4030201@FreeBSD.org> <5235CE87.2090607@FreeBSD.org> Date: Mon, 16 Sep 2013 15:26:34 -0400 X-Google-Sender-Auth: hFq42pStBcH8pO0lLNNlV5SHOnw Message-ID: Subject: Re: zfs_enable vs zfs_load in loader.conf (but neither works) From: J David To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-fs@freebsd.org" , freebsd-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:26:35 -0000 On Sun, Sep 15, 2013 at 11:13 AM, Andriy Gapon wrote: > Unfortunately, I am not sure if it is possible to obtain anu useful information > from ddb and saving a crash dump is not possible in pre-init environment. > I could write a patch that would print some useful debugging info. > Will you able to use it? Yes, if it applies cleanly to releng/9.2. Thanks! From owner-freebsd-fs@FreeBSD.ORG Tue Sep 17 18:08:54 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99CF92F5 for ; Tue, 17 Sep 2013 18:08:54 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 61C4727B2 for ; Tue, 17 Sep 2013 18:08:53 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4ADDB57C; Tue, 17 Sep 2013 20:03:10 +0200 (CEST) Date: Tue, 17 Sep 2013 20:09:04 +0200 From: Pawel Jakub Dawidek To: Oleg Ginzburg Subject: Re: linkat(2) Operation not permitted Message-ID: <20130917180904.GA1406@garage.freebsd.pl> References: <2628598.ea1ZiWMKQv@home.my.domain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <2628598.ea1ZiWMKQv@home.my.domain> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:08:54 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2013 at 04:21:04PM -0700, Oleg Ginzburg wrote: > Hi >=20 > For some reason, creating hardlink within one UFS is failed for /usr/bin/= chfn=20 > with "operation not permitted" messages (other file is ok) This is because this file has 'schg' flag set. See: # ls -lo /usr/bin/chfn So this is difference in handling the 'schg' flag by UFS and ZFS. I think I like UFS behaviour better. If regular user has write access to some directory, which is part of the same file system as the set-uid binary, then he can create hardlink to set-uid file and wait for a security to be found in this set-uid file. For example if /tmp/ and /usr/bin/ is on a single file system, I could create hardlink to chfn and other set-uid-root binaries and once security hole is found and even if system is updated, I still has access to the old set-uid-root binary to exploit. My suggestion would be to change ZFS behaviour to not allow hardlinks if the 'schg' flag is set. Something like this (not even compile-tested): http://people.freebsd.org/~pjd/patches/zfs_vnops.c.8.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlI4msAACgkQForvXbEpPzTJCACg0Zdh3xLJKurYIbEg/X/fpmjD aCMAn0TG0dez6QSQQ2I9lif/4vy5J7Pz =Kwfr -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 02:27:10 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B40CAB9B; Wed, 18 Sep 2013 02:27:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89DFB2532; Wed, 18 Sep 2013 02:27:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8I2RAf8055625; Wed, 18 Sep 2013 02:27:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8I2RAdd055624; Wed, 18 Sep 2013 02:27:10 GMT (envelope-from linimon) Date: Wed, 18 Sep 2013 02:27:10 GMT Message-Id: <201309180227.r8I2RAdd055624@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 02:27:10 -0000 Old Synopsis: UFS: Leakage of vnode references (race condition?) New Synopsis: [ufs] Leakage of vnode references (race condition?) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 18 02:26:00 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=182181 From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 09:50:03 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E4ECD54 for ; Wed, 18 Sep 2013 09:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D696C2D4B for ; Wed, 18 Sep 2013 09:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8I9o1VV058692 for ; Wed, 18 Sep 2013 09:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8I9o1rP058690; Wed, 18 Sep 2013 09:50:01 GMT (envelope-from gnats) Date: Wed, 18 Sep 2013 09:50:01 GMT Message-Id: <201309180950.r8I9o1rP058690@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: "Alexey Markov" Subject: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Alexey Markov List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:50:03 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: "Alexey Markov" To: Cc: Subject: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Wed, 18 Sep 2013 13:41:56 +0400 After applying fix from revision 253998 to the 8-RELEASE src test script works without errors and vnode leakage is gone. -- WBR, Alexey Markov. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 13:29:20 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 727F98B0 for ; Wed, 18 Sep 2013 13:29:20 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB2982A54 for ; Wed, 18 Sep 2013 13:29:19 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ev20so5582605lab.22 for ; Wed, 18 Sep 2013 06:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=O0I9ekqx9i3szzeYSxKQMwjTC63ce4Rk9M8j/T+SkR4=; b=cW7PDiRNnR3jkNpYaPrhLSAQ40KRfG56aFZgRNkIMCmC/zLaoOf1TQMlTM0QYxC1Fo +P9jBm2K7FnCWNwqN+EVKOuOA8d3LmIfGIO1EuaOJIwSYJ1EQCBRJD9sWHHIiS8MF9Mv JqM5NB1EPRW6qEKJg3pEjvNoqvnQCKvmANeBdUlN8+MTJwZb6dp2UL31qE5SB7q81irk QmrTHglEpewUJVYcto9/u1+b/7vXk7BoGhjz136t6voX2hvazRMWYCKdOO22f5lBmj1W eh8ll35QnjwrMffSilhcSNBHhEUsG7jRGZo1P5KIkpUKyLPeIdIHV76FPxm65A36Nwmi Z4NA== X-Received: by 10.112.155.39 with SMTP id vt7mr11114312lbb.29.1379510957863; Wed, 18 Sep 2013 06:29:17 -0700 (PDT) Received: from [192.168.1.130] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id vs11sm990601lac.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 06:29:17 -0700 (PDT) Message-ID: <5239AAAC.2@gmail.com> Date: Wed, 18 Sep 2013 16:29:16 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130909 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: possible hang in unionfs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 13:29:20 -0000 Hello. I'm supporting servers that share some projects, and I want those projects to be contamined and separated. I'm using this scheme: /bin /var/jail/project/bin nullfs ro,late 0 0 /tmp /var/jail/project/tmp unionfs ro,late,below 0 0 /var /var/jail/project/var unionfs ro,late,below 0 0 /usr /var/jail/project/usr nullfs ro,late 0 0 /usr/local /var/jail/project/usr/local nullfs ro,late 0 0 /lib /var/jail/project/lib nullfs ro,late 0 0 My base system is ZFS hence mounting /usr and /usr/local as they are different fs. And because I want to access postgres/mysql/redis through socket I need tmp from the main container. And the sites want write access to tmp too. Mostly everything works, but sometimes the machine gets locked. Everything stops and I can't even login. I can see login process is waiting in [zfs]. I rebuild everything with DEBUG and now I see this: Sep 14 11:19:36 slylandro kernel: lock order reversal: Sep 14 11:19:36 slylandro kernel: 1st 0xfffffe002e41b878 tmpfs (tmpfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1907 Sep 14 11:19:36 slylandro kernel: 2nd 0xfffffe019b06c680 zfs (zfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1938 Sep 14 11:19:36 slylandro kernel: KDB: stack backtrace: Sep 14 11:19:36 slylandro kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9f8492d2d0 Sep 14 11:19:36 slylandro kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9f8492d380 Sep 14 11:19:36 slylandro kernel: witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff9f8492d400 Sep 14 11:19:36 slylandro kernel: __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff9f8492d520 Sep 14 11:19:36 slylandro kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff9f8492d540 Sep 14 11:19:36 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f8492d570 Sep 14 11:19:36 slylandro kernel: unionfs_lock() at unionfs_lock+0x4c6/frame 0xffffff9f8492d600 Sep 14 11:19:36 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f8492d630 Sep 14 11:19:36 slylandro kernel: _vn_lock() at _vn_lock+0x54/frame 0xffffff9f8492d690 Sep 14 11:19:36 slylandro kernel: unionfs_root() at unionfs_root+0x43/frame 0xffffff9f8492d6c0 Sep 14 11:19:36 slylandro kernel: lookup() at lookup+0x99d/frame 0xffffff9f8492d750 Sep 14 11:19:36 slylandro kernel: namei() at namei+0x589/frame 0xffffff9f8492d800 Sep 14 11:19:36 slylandro kernel: unp_connect() at unp_connect+0x1b3/frame 0xffffff9f8492da60 Sep 14 11:19:36 slylandro kernel: uipc_connect() at uipc_connect+0x47/frame 0xffffff9f8492da90 Sep 14 11:19:36 slylandro kernel: kern_connect() at kern_connect+0xdb/frame 0xffffff9f8492dae0 Sep 14 11:19:36 slylandro kernel: sys_connect() at sys_connect+0x96/frame 0xffffff9f8492db20 Sep 14 11:19:36 slylandro kernel: amd64_syscall() at amd64_syscall+0x259/frame 0xffffff9f8492dc30 Sep 14 11:19:36 slylandro kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff9f8492dc30 Sep 14 11:19:36 slylandro kernel: --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x801f4d8ac, rsp = 0x7fffffff6c18, rbp = 0x7fffffff6c40 --- Sep 14 11:19:39 slylandro kernel: lock order reversal: Sep 14 11:19:39 slylandro kernel: 1st 0xfffffe0089d87878 zfs (zfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:312 Sep 14 11:19:39 slylandro kernel: 2nd 0xfffffe0280cc9680 unionfs (unionfs) @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:366 Sep 14 11:19:39 slylandro kernel: 3rd 0xfffffe002e3ec098 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2335 Sep 14 11:19:39 slylandro kernel: KDB: stack backtrace: Sep 14 11:19:39 slylandro kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff9f835fe120 Sep 14 11:19:39 slylandro kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff9f835fe1d0 Sep 14 11:19:39 slylandro kernel: witness_checkorder() at witness_checkorder+0xc0a/frame 0xffffff9f835fe250 Sep 14 11:19:39 slylandro kernel: __lockmgr_args() at __lockmgr_args+0x744/frame 0xffffff9f835fe370 Sep 14 11:19:39 slylandro kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff9f835fe390 Sep 14 11:19:39 slylandro kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbe/frame 0xffffff9f835fe3c0 Sep 14 11:19:39 slylandro kernel: _vn_lock() at _vn_lock+0x54/frame 0xffffff9f835fe420 Sep 14 11:19:39 slylandro kernel: vputx() at vputx+0x21b/frame 0xffffff9f835fe480 Sep 14 11:19:39 slylandro kernel: unionfs_noderem() at unionfs_noderem+0x1cf/frame 0xffffff9f835fe4f0 Sep 14 11:19:39 slylandro kernel: unionfs_reclaim() at unionfs_reclaim+0x14/frame 0xffffff9f835fe500 Sep 14 11:19:39 slylandro kernel: VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xb9/frame 0xffffff9f835fe530 Sep 14 11:19:39 slylandro kernel: vgonel() at vgonel+0x16e/frame 0xffffff9f835fe5a0 Sep 14 11:19:39 slylandro kernel: vrecycle() at vrecycle+0x3e/frame 0xffffff9f835fe5d0 Sep 14 11:19:39 slylandro kernel: unionfs_inactive() at unionfs_inactive+0x23/frame 0xffffff9f835fe5e0 Sep 14 11:19:39 slylandro kernel: VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xb9/frame 0xffffff9f835fe610 Sep 14 11:19:39 slylandro kernel: vinactive() at vinactive+0xc6/frame 0xffffff9f835fe660 Sep 14 11:19:39 slylandro kernel: vputx() at vputx+0x263/frame 0xffffff9f835fe6c0 Sep 14 11:19:39 slylandro kernel: lookup() at lookup+0xd2c/frame 0xffffff9f835fe750 Sep 14 11:19:39 slylandro kernel: namei() at namei+0x589/frame 0xffffff9f835fe800 Sep 14 11:19:39 slylandro kernel: unp_connect() at unp_connect+0x1b3/frame 0xffffff9f835fea60 Sep 14 11:19:39 slylandro kernel: uipc_connect() at uipc_connect+0x47/frame 0xffffff9f835fea90 Sep 14 11:19:39 slylandro kernel: kern_connect() at kern_connect+0xdb/frame 0xffffff9f835feae0 Sep 14 11:19:39 slylandro kernel: sys_connect() at sys_connect+0x96/frame 0xffffff9f835feb20 Sep 14 11:19:39 slylandro kernel: amd64_syscall() at amd64_syscall+0x259/frame 0xffffff9f835fec30 Sep 14 11:19:39 slylandro kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff9f835fec30 Sep 14 11:19:39 slylandro kernel: --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x801f4d8ac, rsp = 0x7fffffff7628, rbp = 0x7fffffff7650 --- The machine is on 9.2-RC4. Has everyone faced something like this? Is there any other way to share host and slave containers filesystems? -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 20:00:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 03F86A24 for ; Wed, 18 Sep 2013 20:00:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E530722C1 for ; Wed, 18 Sep 2013 20:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8IK012x080806 for ; Wed, 18 Sep 2013 20:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8IK01Vc080805; Wed, 18 Sep 2013 20:00:01 GMT (envelope-from gnats) Date: Wed, 18 Sep 2013 20:00:01 GMT Message-Id: <201309182000.r8IK01Vc080805@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: "Teske, Devin" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Teske, Devin" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 20:00:02 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: "Teske, Devin" To: "bug-followup@FreeBSD.org" , "redrat@mail.ru" Cc: "Teske, Devin" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Wed, 18 Sep 2013 19:57:52 +0000 When you say you applied r253998 to 8-RELEASE, which branch? I see that the equivalent one-line change introduced by r253998 has been in stable/8 for 2 years 4 months (meaning 8.3-R and later have the change you're talking about). Could you clarify please? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 22:07:50 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA2E9EDF; Wed, 18 Sep 2013 22:07:50 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3F36294F; Wed, 18 Sep 2013 22:07:50 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8IM7fAs063113; Wed, 18 Sep 2013 15:07:41 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309182207.r8IM7fAs063113@chez.mckusick.com> To: "Teske, Devin" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) In-reply-to: <201309182000.r8IK01Vc080805@freefall.freebsd.org> Date: Wed, 18 Sep 2013 15:07:41 -0700 From: Kirk McKusick Cc: freebsd-fs@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:07:50 -0000 > Date: Wed, 18 Sep 2013 20:00:01 GMT > To: freebsd-fs@freebsd.org > From: "Teske, Devin" > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > > The following reply was made to PR kern/182181; it has been noted by GNATS. > > From: "Teske, Devin" > To: "bug-followup@FreeBSD.org" , > "redrat@mail.ru" > > Cc: "Teske, Devin" > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > Date: Wed, 18 Sep 2013 19:57:52 +0000 > > When you say you applied r253998 to 8-RELEASE, which branch? > I see that the equivalent one-line change introduced by r253998 has > been in stable/8 for 2 years 4 months (meaning 8.3-R and later have > the change you're talking about). > > Could you clarify please? > -- > Devin My fat-fingered mistake. I should have said that it was MFC'ed to 9-RELEASE. Specifically -r255104 was the MFC from current to 9-stable and -r255231 was MFS to releng9.2 so that it will be in the 9.2 release. Sorry for the confusion. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 22:10:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80C2D180 for ; Wed, 18 Sep 2013 22:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C1C92965 for ; Wed, 18 Sep 2013 22:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8IMA1AA007347 for ; Wed, 18 Sep 2013 22:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8IMA1Vq007346; Wed, 18 Sep 2013 22:10:01 GMT (envelope-from gnats) Date: Wed, 18 Sep 2013 22:10:01 GMT Message-Id: <201309182210.r8IMA1Vq007346@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Kirk McKusick Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Kirk McKusick List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:10:01 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: Kirk McKusick To: "Teske, Devin" Cc: freebsd-fs@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Wed, 18 Sep 2013 15:07:41 -0700 > Date: Wed, 18 Sep 2013 20:00:01 GMT > To: freebsd-fs@freebsd.org > From: "Teske, Devin" > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > > The following reply was made to PR kern/182181; it has been noted by GNATS. > > From: "Teske, Devin" > To: "bug-followup@FreeBSD.org" , > "redrat@mail.ru" > > Cc: "Teske, Devin" > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > Date: Wed, 18 Sep 2013 19:57:52 +0000 > > When you say you applied r253998 to 8-RELEASE, which branch? > I see that the equivalent one-line change introduced by r253998 has > been in stable/8 for 2 years 4 months (meaning 8.3-R and later have > the change you're talking about). > > Could you clarify please? > -- > Devin My fat-fingered mistake. I should have said that it was MFC'ed to 9-RELEASE. Specifically -r255104 was the MFC from current to 9-stable and -r255231 was MFS to releng9.2 so that it will be in the 9.2 release. Sorry for the confusion. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 23:00:05 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43E17E38 for ; Wed, 18 Sep 2013 23:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3173D2B88 for ; Wed, 18 Sep 2013 23:00:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8IN01Kb017441 for ; Wed, 18 Sep 2013 23:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8IN01d6017440; Wed, 18 Sep 2013 23:00:01 GMT (envelope-from gnats) Date: Wed, 18 Sep 2013 23:00:01 GMT Message-Id: <201309182300.r8IN01d6017440@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: "Oleksandr V. Typlyns'kyi" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Oleksandr V. Typlyns'kyi" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:00:05 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: "Oleksandr V. Typlyns'kyi" To: bug-followup@FreeBSD.org, redrat@mail.ru Cc: Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Thu, 19 Sep 2013 01:49:34 +0300 (EEST) Devin, i think line 1266 in HEAD - it is line 1245 in 8-STABLE: http://svnweb.freebsd.org/base/head/sys/ufs/ufs/ufs_vnops.c?annotate=253998#l1266 http://svnweb.freebsd.org/base/stable/8/sys/ufs/ufs/ufs_vnops.c?annotate=248832#l1245 http://svnweb.freebsd.org/base/releng/8.4/sys/ufs/ufs/ufs_vnops.c?annotate=248833#l1245 And it was not MFC'ed -- WNGS-RIPE From owner-freebsd-fs@FreeBSD.ORG Wed Sep 18 23:27:57 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4936040B for ; Wed, 18 Sep 2013 23:27:57 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 154732CCC for ; Wed, 18 Sep 2013 23:27:56 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r8INRphu024568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Sep 2013 18:27:51 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Wed, 18 Sep 2013 18:27:50 -0500 From: "Teske, Devin" To: "Oleksandr V. Typlyns'kyi" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Topic: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Index: AQHOtMawgNcXNLXack24f2qWRmdm4w== Date: Wed, 18 Sep 2013 23:27:50 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBD7904@LTCFISWMSGMB21.FNFIS.com> References: <201309182300.r8IN01d6017440@freefall.freebsd.org> In-Reply-To: <201309182300.r8IN01d6017440@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <5C1B24DF7A32324B8E978BBF1AA48F4D@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_09:2013-09-18,2013-09-18,1970-01-01 signatures=0 Cc: "" , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:27:57 -0000 On Sep 18, 2013, at 4:00 PM, Oleksandr V. Typlyns'kyi wrote: > Devin, i think line 1266 in HEAD - it is line 1245 in 8-STABLE: > http://svnweb.freebsd.org/base/head/sys/ufs/ufs/ufs_vnops.c?annotate=3D25= 3998#l1266 > http://svnweb.freebsd.org/base/stable/8/sys/ufs/ufs/ufs_vnops.c?annotate= =3D248832#l1245 > http://svnweb.freebsd.org/base/releng/8.4/sys/ufs/ufs/ufs_vnops.c?annotat= e=3D248833#l1245 > And it was not MFC'ed Yes, my confusion was... 1. The PR headers say 8.4-RELEASE-p3 is affected 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" Yet... releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput (read: are patched). So I'm very curious, with respect to the PR, how the test program showed a leak when the claim is that r253998 which fixes this, was in the OP's bra= nch. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 00:05:41 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 108D0952 for ; Thu, 19 Sep 2013 00:05:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C9F922E65 for ; Thu, 19 Sep 2013 00:05:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAFM+OlKDaFve/2dsb2JhbABbgz9Sgyq9OUqBN3SCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHXAYMqA6SIIEpjQWBBTQHgmmBNQOVMIN6kEWDQCAygQM5 X-IronPort-AV: E=Sophos;i="4.90,933,1371096000"; d="scan'208";a="53545839" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Sep 2013 20:05:39 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 85A67B3F45; Wed, 18 Sep 2013 20:05:39 -0400 (EDT) Date: Wed, 18 Sep 2013 20:05:39 -0400 (EDT) From: Rick Macklem To: Devin Teske Message-ID: <1480665076.26305077.1379549139533.JavaMail.root@uoguelph.ca> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FBD7904@LTCFISWMSGMB21.FNFIS.com> Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:05:41 -0000 Devin Teske wrote: > > On Sep 18, 2013, at 4:00 PM, Oleksandr V. Typlyns'kyi wrote: > > > Devin, i think line 1266 in HEAD - it is line 1245 in 8-STABLE: > > http://svnweb.freebsd.org/base/head/sys/ufs/ufs/ufs_vnops.c?annotate=253998#l1266 > > http://svnweb.freebsd.org/base/stable/8/sys/ufs/ufs/ufs_vnops.c?annotate=248832#l1245 > > http://svnweb.freebsd.org/base/releng/8.4/sys/ufs/ufs/ufs_vnops.c?annotate=248833#l1245 > > And it was not MFC'ed > > Yes, my confusion was... > > 1. The PR headers say 8.4-RELEASE-p3 is affected > > 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" > > Yet... > > releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput > (read: are patched). > Did you mean "not patched"? The patched version in head has vput() and the unpatched versions have VOP_UNLOCK(), if I read the coed correctly. rick > So I'm very curious, with respect to the PR, how the test program > showed > a leak when the claim is that r253998 which fixes this, was in the > OP's branch. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) > delete the message and all copies; (ii) do not disclose, distribute > or use the message in any manner; and (iii) notify the sender > immediately. In addition, please be aware that any message addressed > to our domain is subject to archiving and review by persons other > than the intended recipient. Thank you. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 00:11:07 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 62BD9A2B for ; Thu, 19 Sep 2013 00:11:07 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E4332EAD for ; Thu, 19 Sep 2013 00:11:06 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r8J0B5Sl003109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Sep 2013 19:11:05 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Wed, 18 Sep 2013 19:11:04 -0500 From: "Teske, Devin" To: Rick Macklem Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Topic: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Index: AQHOtMy6gNcXNLXack24f2qWRmdm4w== Date: Thu, 19 Sep 2013 00:11:03 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBD7C18@LTCFISWMSGMB21.FNFIS.com> References: <1480665076.26305077.1379549139533.JavaMail.root@uoguelph.ca> In-Reply-To: <1480665076.26305077.1379549139533.JavaMail.root@uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_09:2013-09-18,2013-09-18,1970-01-01 signatures=0 Cc: freebsd-fs , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:11:07 -0000 On Sep 18, 2013, at 5:05 PM, Rick Macklem wrote: > Devin Teske wrote: >>=20 >>=20 >> Yes, my confusion was... >>=20 >> 1. The PR headers say 8.4-RELEASE-p3 is affected >>=20 >> 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" >>=20 >> Yet... >>=20 >> releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput >> (read: are patched). >>=20 > Did you mean "not patched"? The patched version in head has vput() > and the unpatched versions have VOP_UNLOCK(), if I read the coed correctl= y. >=20 Well, Kirk's fat-finger made me think that VOP_UNLOCK was the patched- state and vput was the unpatched state. (could also be that I'm fighting the flu currently). So everything is copacetic now, except the one outstanding question... Should we not MFC r253998 to stable/8? I'm looking to pull this into our own stable/8 kernel, but would like to do= it by way of svn merge from the stable/8 branch. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 00:24:34 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41423D1C; Thu, 19 Sep 2013 00:24:34 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B4CC2F1E; Thu, 19 Sep 2013 00:24:33 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8J0ORZD097969; Wed, 18 Sep 2013 17:24:28 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309190024.r8J0ORZD097969@chez.mckusick.com> To: "Teske, Devin" Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) In-reply-to: <13CA24D6AB415D428143D44749F57D720FBD7C18@LTCFISWMSGMB21.FNFIS.com> Date: Wed, 18 Sep 2013 17:24:27 -0700 From: Kirk McKusick Cc: freebsd-fs , bug-followup@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:24:34 -0000 > From: "Teske, Devin" > To: Rick Macklem > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > Date: Thu, 19 Sep 2013 00:11:03 +0000 > Cc: freebsd-fs , > "Teske, Devin" > > On Sep 18, 2013, at 5:05 PM, Rick Macklem wrote: > >> Devin Teske wrote: >>> >>> >>> Yes, my confusion was... >>> >>> 1. The PR headers say 8.4-RELEASE-p3 is affected >>> >>> 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" >>> >>> Yet... >>> >>> releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput >>> (read: are patched). >>> >> Did you mean "not patched"? The patched version in head has vput() >> and the unpatched versions have VOP_UNLOCK(), if I read the coed correctly. >> > > Well, Kirk's fat-finger made me think that VOP_UNLOCK was the patched- > state and vput was the unpatched state. (could also be that I'm fighting > the flu currently). > > So everything is copacetic now, except the one outstanding question... > > Should we not MFC r253998 to stable/8? > > I'm looking to pull this into our own stable/8 kernel, but would > like to do it by way of svn merge from the stable/8 branch. > -- > Devin Per your request, I have MFC'ed the patch to 8-stable as revision 255681. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 00:30:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48FF6F2A for ; Thu, 19 Sep 2013 00:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 360A82F69 for ; Thu, 19 Sep 2013 00:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8J0U0M0043179 for ; Thu, 19 Sep 2013 00:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8J0U0ew043177; Thu, 19 Sep 2013 00:30:00 GMT (envelope-from gnats) Date: Thu, 19 Sep 2013 00:30:00 GMT Message-Id: <201309190030.r8J0U0ew043177@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Kirk McKusick Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Kirk McKusick List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:30:01 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: Kirk McKusick To: "Teske, Devin" Cc: Rick Macklem , freebsd-fs , bug-followup@freebsd.org Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Wed, 18 Sep 2013 17:24:27 -0700 > From: "Teske, Devin" > To: Rick Macklem > Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) > Date: Thu, 19 Sep 2013 00:11:03 +0000 > Cc: freebsd-fs , > "Teske, Devin" > > On Sep 18, 2013, at 5:05 PM, Rick Macklem wrote: > >> Devin Teske wrote: >>> >>> >>> Yes, my confusion was... >>> >>> 1. The PR headers say 8.4-RELEASE-p3 is affected >>> >>> 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" >>> >>> Yet... >>> >>> releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput >>> (read: are patched). >>> >> Did you mean "not patched"? The patched version in head has vput() >> and the unpatched versions have VOP_UNLOCK(), if I read the coed correctly. >> > > Well, Kirk's fat-finger made me think that VOP_UNLOCK was the patched- > state and vput was the unpatched state. (could also be that I'm fighting > the flu currently). > > So everything is copacetic now, except the one outstanding question... > > Should we not MFC r253998 to stable/8? > > I'm looking to pull this into our own stable/8 kernel, but would > like to do it by way of svn merge from the stable/8 branch. > -- > Devin Per your request, I have MFC'ed the patch to 8-stable as revision 255681. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 01:59:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EB5EF15D for ; Thu, 19 Sep 2013 01:59:29 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B34792754 for ; Thu, 19 Sep 2013 01:59:29 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r8J1xSDm025462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Sep 2013 20:59:28 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Wed, 18 Sep 2013 20:59:27 -0500 From: "Teske, Devin" To: Kirk McKusick Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Topic: kern/182181: [ufs] Leakage of vnode references (race condition?) Thread-Index: AQHOtNvfLnUp3A7wAUGOowRuzp3VWQ== Date: Thu, 19 Sep 2013 01:59:27 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBD82DC@LTCFISWMSGMB21.FNFIS.com> References: <201309190024.r8J0ORZD097969@chez.mckusick.com> In-Reply-To: <201309190024.r8J0ORZD097969@chez.mckusick.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-19_01:2013-09-18,2013-09-19,1970-01-01 signatures=0 Cc: freebsd-fs , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 01:59:30 -0000 On Sep 18, 2013, at 5:24 PM, Kirk McKusick wrote: >> From: "Teske, Devin" >> To: Rick Macklem >> Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condit= ion?) >> Date: Thu, 19 Sep 2013 00:11:03 +0000 >> Cc: freebsd-fs , >> "Teske, Devin" >>=20 >> On Sep 18, 2013, at 5:05 PM, Rick Macklem wrote: >>=20 >>> Devin Teske wrote: >>>>=20 >>>>=20 >>>> Yes, my confusion was... >>>>=20 >>>> 1. The PR headers say 8.4-RELEASE-p3 is affected >>>>=20 >>>> 2. The PR's "How-To-Repeat" starts with "Install a releng/8.4 branch" >>>>=20 >>>> Yet... >>>>=20 >>>> releng/8.4 and even releng/8.3 both use VOP_UNLOCK instead of vput >>>> (read: are patched). >>>>=20 >>> Did you mean "not patched"? The patched version in head has vput() >>> and the unpatched versions have VOP_UNLOCK(), if I read the coed correc= tly. >>>=20 >>=20 >> Well, Kirk's fat-finger made me think that VOP_UNLOCK was the patched- >> state and vput was the unpatched state. (could also be that I'm fighting >> the flu currently). >>=20 >> So everything is copacetic now, except the one outstanding question... >>=20 >> Should we not MFC r253998 to stable/8? >>=20 >> I'm looking to pull this into our own stable/8 kernel, but would >> like to do it by way of svn merge from the stable/8 branch. >> --=20 >> Devin >=20 > Per your request, I have MFC'ed the patch to 8-stable as revision 255681. >=20 Thanks much! Slurping this into our base now. Again, thanks! --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 05:50:02 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 38F0ED8C for ; Thu, 19 Sep 2013 05:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1B523A2 for ; Thu, 19 Sep 2013 05:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8J5o1I1009402 for ; Thu, 19 Sep 2013 05:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8J5o1So009401; Thu, 19 Sep 2013 05:50:01 GMT (envelope-from gnats) Date: Thu, 19 Sep 2013 05:50:01 GMT Message-Id: <201309190550.r8J5o1So009401@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: "Alexey Markov" Subject: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Alexey Markov List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 05:50:02 -0000 The following reply was made to PR kern/182181; it has been noted by GNATS. From: "Alexey Markov" To: Cc: Subject: kern/182181: [ufs] Leakage of vnode references (race condition?) Date: Thu, 19 Sep 2013 09:44:22 +0400 I am sorry for my misprint, of course it was 8-RELEASE, not a 9-RELEASE! And I tested a fix on my 8-RELEASE-p4 server. Successfully. Now that fix was MFCed to 8-STABLE, I think this PR may be closed. -- WBR, Alexey Markov. From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 08:11:45 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 619AE40F; Thu, 19 Sep 2013 08:11:45 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 392E22C7F; Thu, 19 Sep 2013 08:11:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8J8Bj5W051467; Thu, 19 Sep 2013 08:11:45 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8J8Bi9C051466; Thu, 19 Sep 2013 08:11:44 GMT (envelope-from pluknet) Date: Thu, 19 Sep 2013 08:11:44 GMT Message-Id: <201309190811.r8J8Bi9C051466@freefall.freebsd.org> To: redrat@mail.ru, pluknet@FreeBSD.org, freebsd-fs@FreeBSD.org From: pluknet@FreeBSD.org Subject: Re: kern/182181: [ufs] Leakage of vnode references (race condition?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:11:45 -0000 Synopsis: [ufs] Leakage of vnode references (race condition?) State-Changed-From-To: open->closed State-Changed-By: pluknet State-Changed-When: Thu Sep 19 08:09:25 UTC 2013 State-Changed-Why: Close per submitter request. The fix was MFCed to 8-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=182181 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 19 18:14:37 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E79DC98B; Thu, 19 Sep 2013 18:14:37 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BB542EF4; Thu, 19 Sep 2013 18:14:37 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c1so4331673eek.38 for ; Thu, 19 Sep 2013 11:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mrOh413cjysJU/WtOW4SmLDfAH0AG7HhMNz6f6SN9Bc=; b=AO7Uv9qopHXIufteEQMJCa3aqueW+kjiB40F9l5hGG9Q7HQLyPtgj4bnQA9uUmXuu5 mBDYUeLhYhyf8ZKuiJZfsDRRzTxZWV2J999X3k29zvvz2kG589IHWuTdlEQkSt61AaXE otrvRpvNhqGaHrdNNosTwxLF7a8IX9C+3CBLj3UwQpY0rPJzutVgcNt7NGae60R4gzQL w2vqEtpjfOl4KiUlVOjUrxEQK18KutUSWod3F+hix/ApDE6aijjOzidoRED0VsjTD1Ny xu1n+jbMik7v9jujU16VhLVbI2+b3lQcM7V+u6pxnmrm0+AecGQyXs9S7vfkNbtOlr2v FbuQ== X-Received: by 10.15.75.73 with SMTP id k49mr3795549eey.36.1379614475036; Thu, 19 Sep 2013 11:14:35 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id a1sm13247821eem.1.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 11:14:34 -0700 (PDT) Sender: Mikolaj Golub Date: Thu, 19 Sep 2013 21:14:31 +0300 From: Mikolaj Golub To: Yamagi Burmeister Subject: Re: 9.2-RC1: LORs / Deadlock with SU+J on HAST in "memsync" mode Message-ID: <20130919181430.GA3477@gmail.com> References: <20130819115101.ae9c0cf788f881dc4de464c5@yamagi.org> <20130822121341.0f27cb5e372d12bab8725654@yamagi.org> <20130825175616.GA3472@gmail.com> <20130826160125.3b62df57515c45be3c9b2723@yamagi.org> <20130901174146.GA15654@gmail.com> <20130919095407.6b743158df27eb2f7461274f@yamagi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130919095407.6b743158df27eb2f7461274f@yamagi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 18:14:38 -0000 On Thu, Sep 19, 2013 at 09:54:07AM +0200, Yamagi Burmeister wrote: > And another status update, this time with all patches and tips tested: Thank you for testing and reporting back! I have plans to commit this soon and merge to STABLE later. Now I am discussing the changes with Pawel. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Fri Sep 20 10:32:10 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DE89E8D1; Fri, 20 Sep 2013 10:32:10 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 53D8C2D61; Fri, 20 Sep 2013 10:32:09 +0000 (UTC) Received: from cpsps-ews05.kpnxchange.com ([10.94.84.172]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:59 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:59 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 20 Sep 2013 12:30:58 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id B416FB2D3; Fri, 20 Sep 2013 12:30:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org Date: Fri, 20 Sep 2013 12:30:58 +0200 Subject: nandfs panic (bmap_truncate_mapping) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 20 Sep 2013 10:30:59.0097 (UTC) FILETIME=[7F2E4090:01CEB5EC] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:32:10 -0000 Hi, I am using FreeBSD 10-CURRENT of 15 september on a SHEEVAPLUG ARMv5 machine. I did these steps: newfs_nandfs /dev/gnand0s.root mount -t nandfs /dev/gnand0s.root /mnt cd /; tar cf - / | tar -C /mnt -x -f - I did ctrl-c because I found it was tar-ing /mnt into /mnt/mnt. rm -r /mnt/mnt/* tar --one-file-system -c -f - / | tar -C /mnt -x -f - That gave the panic below. What information can I provide to solve this? Ronald. root@sh10:/ # panic: bmap_truncate_mapping: error 28 when truncate at level 0 KDB: enter: panic [ thread pid 755 tid 100066 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 755 tid 100066 td 0xc4e6e640 db_trace_self() at db_trace_self pc = 0xc0bb8b48 lr = 0xc093260c (db_hex2dec+0x494) sp = 0xde03a6b0 fp = 0xde03a6c8 r10 = 0xc0c99330 db_hex2dec() at db_hex2dec+0x494 pc = 0xc093260c lr = 0xc0931fc0 (db_command_loop+0x2f4) sp = 0xde03a6d0 fp = 0xde03a770 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0c2d91e db_command_loop() at db_command_loop+0x2f4 pc = 0xc0931fc0 lr = 0xc0931d1c (db_command_loop+0x50) sp = 0xde03a778 fp = 0xde03a788 r4 = 0xc0c0143d r5 = 0xc0c1767f r6 = 0xc0ce74dc r7 = 0xde03a958 r8 = 0xc4e6e640 r9 = 0xc0cdca94 r10 = 0xc0c995a0 db_command_loop() at db_command_loop+0x50 pc = 0xc0931d1c lr = 0xc093466c (X_db_symbol_values+0x254) sp = 0xde03a790 fp = 0xde03a8b0 r4 = 0x00000000 r5 = 0xde03a798 r6 = 0xc0cdcac0 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc093466c lr = 0xc0a84b30 (kdb_trap+0xd4) sp = 0xde03a8b8 fp = 0xde03a8d8 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0cdcac0 r7 = 0xde03a958 kdb_trap() at kdb_trap+0xd4 pc = 0xc0a84b30 lr = 0xc0bc9458 (undefinedinstruction+0x1fc) sp = 0xde03a8e0 fp = 0xde03a950 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0bc91ac r7 = 0xe7ffffff r8 = 0xc4e6e640 r9 = 0xc0a8441c r10 = 0xde03a958 undefinedinstruction() at undefinedinstruction+0x1fc pc = 0xc0bc9458 lr = 0xc0bba3fc (exception_exit) sp = 0xde03a958 fp = 0xde03a9b0 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc0cedecc r7 = 0xc0ccf088 r8 = 0xc4e6e640 r9 = 0xc0ccf010 r10 = 0xde03a9e4 exception_exit() at exception_exit pc = 0xc0bba3fc lr = 0xc0a84410 (kdb_enter+0x40) sp = 0xde03a9ac fp = 0xde03a9b0 r0 = 0xc0cdcaa4 r1 = 0x00000000 r2 = 0x00000000 r3 = 0x00000000 r4 = 0xc0c176d9 r5 = 0xc0c0a63a r6 = 0xc0cedecc r7 = 0xc0ccf088 r8 = 0xc4e6e640 r9 = 0xc0ccf010 r10 = 0xde03a9e4 r12 = 0x00000000 kdb_enter() at kdb_enter+0x50 pc = 0xc0a84420 lr = 0xc0a544d4 (panic+0xcc) sp = 0xde03a9b8 fp = 0xde03a9d8 r4 = 0x00000100 panic() at panic+0xcc pc = 0xc0a544d4 lr = 0xc098cea0 (bmap_truncate_mapping+0x408) sp = 0xde03a9f0 fp = 0xde03aae8 r4 = 0xc414f430 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xc414f378 r9 = 0xde03aa88 r10 = 0x00000098 bmap_truncate_mapping() at bmap_truncate_mapping+0x408 pc = 0xc098cea0 lr = 0xc098e374 (nandfs_bmap_truncate_mapping+0x78) sp = 0xde03aaf0 fp = 0xde03ab20 r4 = 0x00000000 r5 = 0x00000097 r6 = 0x00000000 r7 = 0x00000098 r8 = 0xc414f378 r9 = 0x00000000 r10 = 0x00000098 nandfs_bmap_truncate_mapping() at nandfs_bmap_truncate_mapping+0x78 pc = 0xc098e374 lr = 0xc09a0fb4 (nandfs_vinit+0x2b8) sp = 0xde03ab28 fp = 0xde03ab80 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc4509360 r7 = 0x00000000 r8 = 0x00000000 nandfs_vinit() at nandfs_vinit+0x2b8 pc = 0xc09a0fb4 lr = 0xc09a03c0 (nandfs_itimes+0x3404) sp = 0xde03ab88 fp = 0xde03ab98 r4 = 0xc414f378 r5 = 0xc4509360 r6 = 0x00000000 r7 = 0xc4333d20 r8 = 0xc4e6e640 r9 = 0xc45093c4 r10 = 0xc4509360 nandfs_itimes() at nandfs_itimes+0x3404 pc = 0xc09a03c0 lr = 0xc0be21b8 (VOP_INACTIVE_APV+0x9c) sp = 0xde03aba0 fp = 0xde03abb0 r4 = 0x00000000 r5 = 0xde03abc8 r6 = 0xc0ca0560 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0x9c pc = 0xc0be21b8 lr = 0xc0adc2e4 (vinactive+0xb0) sp = 0xde03abb8 fp = 0xde03abf0 r4 = 0xc4509360 r5 = 0x00000002 r6 = 0xc45093c4 vinactive() at vinactive+0xb0 pc = 0xc0adc2e4 lr = 0xc0adc5e4 (vrele+0x210) sp = 0xde03abf8 fp = 0xde03ac20 r4 = 0xc4509360 r5 = 0x00000002 r6 = 0xc45093c4 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xde03ad74 vrele() at vrele+0x210 pc = 0xc0adc5e4 lr = 0xc0adc660 (vput+0x10) sp = 0xde03ac28 fp = 0xde03ac28 r4 = 0xde03acd8 r5 = 0xc4e6e640 r6 = 0x00000000 r7 = 0x00000000 vput() at vput+0x10 pc = 0xc0adc660 lr = 0xc0ae4bec (kern_unlinkat+0x1e4) sp = 0xde03ac30 fp = 0xde03ada8 kern_unlinkat() at kern_unlinkat+0x1e4 pc = 0xc0ae4bec lr = 0xc0ae47d8 (sys_unlink+0x24) sp = 0xde03adb0 fp = 0xde03adb8 r4 = 0xc4e6e640 r5 = 0xc498e000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0xde03ae10 r9 = 0x00000001 r10 = 0x00000000 sys_unlink() at sys_unlink+0x24 pc = 0xc0ae47d8 lr = 0xc0bc8b6c (swi_handler+0x224) sp = 0xde03adc0 fp = 0xde03ae58 swi_handler() at swi_handler+0x224 pc = 0xc0bc8b6c lr = 0xc0bba1c8 (swi_entry+0x40) sp = 0xde03ae60 fp = 0xbfffea58 r4 = 0x20c0a364 r5 = 0x20c0a2a0 r6 = 0x20c9f114 r7 = 0x0000000a r8 = 0x20c0a200 swi_entry() at swi_entry+0x40 pc = 0xc0bba1c8 lr = 0xc0bba1c8 (swi_entry+0x40) sp = 0xde03ae60 fp = 0xbfffea58 Unable to unwind further db> From owner-freebsd-fs@FreeBSD.ORG Fri Sep 20 18:45:42 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B4DD2FB for ; Fri, 20 Sep 2013 18:45:42 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm19-vm8.bullet.mail.gq1.yahoo.com (nm19-vm8.bullet.mail.gq1.yahoo.com [98.136.217.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E230D29FD for ; Fri, 20 Sep 2013 18:45:41 +0000 (UTC) Received: from [216.39.60.182] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 20 Sep 2013 18:43:57 -0000 Received: from [208.71.42.194] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 20 Sep 2013 18:43:57 -0000 Received: from [127.0.0.1] by smtp205.mail.gq1.yahoo.com with NNFMP; 20 Sep 2013 18:43:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379702637; bh=sE2hMAzanEtxXptuml9kt8dPyjmTUiswV3oEfvv32O4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=aYqEu0Ddxn4bza9tukk/c4Gtq4oP9F4P2e0wPinkDm8nQ9/xiHtlXRqVMxL7IhwKjRjiLGkG+nWz75XGX+X4j5u+tuRE0BB3Bs29Zz+pJ3uSLzs3wlhK3G8Fx2uT7aMElnjezPkBZdFOciS2M9lmquRTWvWkZ2LaFcvcX9NKKuA= X-Yahoo-Newman-Id: 803992.84319.bm@smtp205.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ui.Oh3wVM1lyopqwk_1bJxW7Lten6x47Wsja_mvEgX77l9f fhQUr8Kq2WNKlGaYBHCZIpIo4MHXB.TnpkgMFNrERU5LpSQNc4pQo7StiGUl NCEtOUvXMPQn79Jp51wrNwzktM8lkpJqT5VncB2nAzv9QL1rjX_WQ9UDGdKb qk5Sn7Is39m1bRxRyhXNEoUHuMeRk1c_seCt_htkXqVqGxFy9JgkiMkDq_um _OkG6eI_0wRaajiuh7w2ZfSsL3PFLnyJqEAdYBRujDvf5p1HLpPDBuO6kqji PLGyFCoutGIo283ucfwBedB_oFEzG9Jk2IuckLe9Juz9FUlFrr5vpPUj5nQK toLxbYdXdtAFi_V7CTLqdchC6bA6xX02yFOmB3CV0q345.MgF4Glgej5Pv2M l69_fnCRUOLI_hfYxt4eDgrKq47YWbJ4_VSsDfhLZrq_zJZ9LyaDVZQ57z4N _rv1mIOEGG7o18XsbwpN2N1OZcBxpB1ChloWhKlgXIzl2QRoe1Z20UY2328G 295Gc5ybKaWXL_sz7GhsV6GyRebsd0.M2qdMbnvvQ3RRurae0NXRoGsNWwfz SVfJtAzzBsY5njqB5Ddy8TNfPK66ST6O8ZVzAaUnXEbn__spLIEnAKVkyGKQ TYE6joox2k.IhpG1K46AKQnGgry.PzgoAhTmsrA-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp205.mail.gq1.yahoo.com with SMTP; 20 Sep 2013 11:43:57 -0700 PDT Subject: Re: zfs mount prior to rc.conf evaluations From: Sean Bruno To: freebsd-fs In-Reply-To: <1376953030.1483.4.camel@localhost> References: <1376953030.1483.4.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fT0vFczws7qtjPi1GZGN" Date: Fri, 20 Sep 2013 11:43:57 -0700 Message-ID: <1379702637.2402.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 18:45:42 -0000 --=-fT0vFczws7qtjPi1GZGN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-08-19 at 15:57 -0700, Sean Bruno wrote: > We have a few slightly goofy rc.conf variables that require /usr/bin/ to > be mounted before rc.conf is evaluated, e.g: >=20 > netwait_ip=3D"$(grep default /etc/start_if.* | awk '{print $4}')" >=20 > This worked in our UFS world, but in ZFS land with zroot/usr/bin being a > seperate mountpoint, its not mounted at the point that rc.conf is > evaluated causing a few things to fail. >=20 > This appears to be solved by applying > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153666 >=20 > But, is there a better way to do this? I *could* make zroot/usr and > zroot/usr/bin just be part of zroot and not seperate mountpoints to > solve the issue as well. >=20 > Thoughts or alternative solutions? >=20 > Sean anyone? If there's no real objection, I don't see the harm in committing this. Sean --=-fT0vFczws7qtjPi1GZGN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSPJdtAAoJEBkJRdwI6BaH+o0H/0vgSTyEqV+CubUd9t9YhEQs FmcYlTTVOO25KNOCjb+NOaXYwFO7pvOys90IfDARg+tmvUhTJgY7PfXpkOaNP7As rNG3syexSvlHAZdUdWi/6+AfhE33OuBQgFI11ylBS2gVefFuYiWF8t/p4z8XyZxE RkF0XfE9hqW0xFXlRYh1X6biRtN+3oT1cd9OU9qcACWJ3xJ51vcjHMK4skJdzPPk /8UAZGtXD30MtAnOABWKUgqmm4HZI2mJHmVxthfwvSd773+J7dKa7pv+QCWZ/583 ZPu23Q6ODuWR6g/m3gZPFhUq1czai78tDp0OPZwH53Tpzjn30wLCeB3p4vWswd8= =lu7q -----END PGP SIGNATURE----- --=-fT0vFczws7qtjPi1GZGN-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 20 23:45:03 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55E8F6CE; Fri, 20 Sep 2013 23:45:03 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2317129F4; Fri, 20 Sep 2013 23:45:02 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r8KNitTH020505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Sep 2013 18:44:55 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Fri, 20 Sep 2013 18:44:54 -0500 From: "Teske, Devin" To: freebsd-fs Subject: zpool upgrade issue? Thread-Topic: zpool upgrade issue? Thread-Index: AQHOtltn+EDNX2+qtUGA5DT+NrkuDw== Date: Fri, 20 Sep 2013 23:44:54 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBE0ED1@LTCFISWMSGMB21.FNFIS.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <22534D33181D3D47BC21788FB7188CED@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-20_11:2013-09-20,2013-09-20,1970-01-01 signatures=0 Cc: Devin Teske X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:45:03 -0000 Hi, I recently upgraded a ZFS pool on my system and the reported version changed from "14" to "-" and I'm wondering if this is a bug. dteske@hvm2a ~ $ zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT LSI-RAID1 1.39T 6.58G 1.39T 0% 1.00x ONLINE - NEC2_POOL_A 3.91T 126K 3.91T 0% 1.00x ONLINE - dteske@hvm2a ~ $ zpool status pool: LSI-RAID1 state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: none requested config: NAME STATE READ WRITE CKSUM LSI-RAID1 ONLINE 0 0 0 mfid0s1g ONLINE 0 0 0 mfid1 ONLINE 0 0 0 errors: No known data errors pool: NEC2_POOL_A state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: none requested config: NAME STATE READ WRITE CKSUM NEC2_POOL_A ONLINE 0 0 0 multipath/NEC2_LUN_A ONLINE 0 0 0 errors: No known data errors dteske@hvm2a ~ $ zpool get version NAME PROPERTY VALUE SOURCE LSI-RAID1 version 14 local NEC2_POOL_A version 14 local =3D=3D=3D Now for the upgrade =3D=3D=3D dteske@hvm2a ~ $ uname -a FreeBSD hvm2a 8.4-STABLE FreeBSD 8.4-STABLE #2 r255470M: Wed Sep 11 01:29:1= 5 UTC 2013 dteske@push840-64.vicor.com:/usr/src/sys/amd64/compile/FIS-a= md64 amd64 dteske@hvm2a ~ $ sr zpool upgrade -a [sudo] Password: This system supports ZFS pool feature flags. Successfully upgraded 'LSI-RAID1' from version 14 to feature flags. Enabled the following features on 'LSI-RAID1': async_destroy empty_bpobj lz4_compress Successfully upgraded 'NEC2_POOL_A' from version 14 to feature flags. Enabled the following features on 'NEC2_POOL_A': async_destroy empty_bpobj lz4_compress dteske@hvm2a ~ $ zpool get version NAME PROPERTY VALUE SOURCE LSI-RAID1 version - default NEC2_POOL_A version - default =3D=3D=3D Why doesn't it say 28?? =3D=3D=3D Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 20 23:51:44 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41C30C00; Fri, 20 Sep 2013 23:51:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1954B2A65; Fri, 20 Sep 2013 23:51:43 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id DF6D42644; Fri, 20 Sep 2013 23:51:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us DF6D42644 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 20 Sep 2013 19:51:39 -0400 From: Glen Barber To: Devin Teske Subject: Re: zpool upgrade issue? Message-ID: <20130920235139.GS2302@glenbarber.us> References: <13CA24D6AB415D428143D44749F57D720FBE0ED1@LTCFISWMSGMB21.FNFIS.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vru7fAags9pVPvn5" Content-Disposition: inline In-Reply-To: <13CA24D6AB415D428143D44749F57D720FBE0ED1@LTCFISWMSGMB21.FNFIS.com> X-Operating-System: FreeBSD 10.0-ALPHA2 amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:51:44 -0000 --vru7fAags9pVPvn5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 20, 2013 at 11:44:54PM +0000, Teske, Devin wrote: > Hi, >=20 > I recently upgraded a ZFS pool on my system and the reported version > changed from "14" to "-" and I'm wondering if this is a bug. >=20 > dteske@hvm2a ~ $ zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > LSI-RAID1 1.39T 6.58G 1.39T 0% 1.00x ONLINE - > NEC2_POOL_A 3.91T 126K 3.91T 0% 1.00x ONLINE - > dteske@hvm2a ~ $ zpool status > pool: LSI-RAID1 > state: ONLINE > status: The pool is formatted using a legacy on-disk format. The pool can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > pool will no longer be accessible on software that does not support feat= ure > flags. > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > LSI-RAID1 ONLINE 0 0 0 > mfid0s1g ONLINE 0 0 0 > mfid1 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > pool: NEC2_POOL_A > state: ONLINE > status: The pool is formatted using a legacy on-disk format. The pool can > still be used, but some features are unavailable. > action: Upgrade the pool using 'zpool upgrade'. Once this is done, the > pool will no longer be accessible on software that does not support feat= ure > flags. > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > NEC2_POOL_A ONLINE 0 0 0 > multipath/NEC2_LUN_A ONLINE 0 0 0 >=20 > errors: No known data errors > dteske@hvm2a ~ $ zpool get version > NAME PROPERTY VALUE SOURCE > LSI-RAID1 version 14 local > NEC2_POOL_A version 14 local >=20 >=20 > =3D=3D=3D Now for the upgrade =3D=3D=3D >=20 >=20 > dteske@hvm2a ~ $ uname -a > FreeBSD hvm2a 8.4-STABLE FreeBSD 8.4-STABLE #2 r255470M: Wed Sep 11 01:29= :15 UTC 2013 dteske@push840-64.vicor.com:/usr/src/sys/amd64/compile/FIS= -amd64 amd64 > dteske@hvm2a ~ $ sr zpool upgrade -a > [sudo] Password: > This system supports ZFS pool feature flags. >=20 > Successfully upgraded 'LSI-RAID1' from version 14 to feature flags. > Enabled the following features on 'LSI-RAID1': > async_destroy > empty_bpobj > lz4_compress >=20 > Successfully upgraded 'NEC2_POOL_A' from version 14 to feature flags. > Enabled the following features on 'NEC2_POOL_A': > async_destroy > empty_bpobj > lz4_compress >=20 > dteske@hvm2a ~ $ zpool get version > NAME PROPERTY VALUE SOURCE > LSI-RAID1 version - default > NEC2_POOL_A version - default >=20 > =3D=3D=3D Why doesn't it say 28?? =3D=3D=3D >=20 Because it isn't version 28. Since the feature flags (zpool-features(7)), the zpool spa version is 5000. Glen --vru7fAags9pVPvn5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSPN+LAAoJEFJPDDeguUajmowH/105hB+q8LnqGOzxMiI0nLl9 aKq0EcERLh8fjzL+3l4tFrtKq4ZW3Up3+5BVI8H2EQaPPLbSjFquVT5zS2TonF7a jV630KW/b54Z/1EVcc47Fwxk2hWKWq2UUQfZF0GBpD2D1dSPh1ZDEhkP85HCqw1J XawFBQiN4XfOf8UDQgCHuSpfKmnJkEGbNpG+HReHg0qPabBgGoNgrms2GFycL5R2 AFhBqiUFJ8lWEJC5wlBerX8EaoOgbjmf3edhQ3V4RWPxAA9g2qEAqAIKZ1/nV1NT sJP+fMTBRzcojVtwRo1MoPTaAWmfQIhDgWoSe9GKzr9YQPrkvXf88QmbqjgEJTg= =n8/8 -----END PGP SIGNATURE----- --vru7fAags9pVPvn5-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 20 23:55:59 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 871B2EA2; Fri, 20 Sep 2013 23:55:59 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EC7E2A95; Fri, 20 Sep 2013 23:55:58 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r8KNtwTP023048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Sep 2013 18:55:58 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Fri, 20 Sep 2013 18:55:57 -0500 From: "Teske, Devin" To: Glen Barber Subject: Re: zpool upgrade issue? Thread-Topic: zpool upgrade issue? Thread-Index: AQHOtltn+EDNX2+qtUGA5DT+NrkuDw== Date: Fri, 20 Sep 2013 23:55:55 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBE0F97@LTCFISWMSGMB21.FNFIS.com> References: <13CA24D6AB415D428143D44749F57D720FBE0ED1@LTCFISWMSGMB21.FNFIS.com> <20130920235139.GS2302@glenbarber.us> In-Reply-To: <20130920235139.GS2302@glenbarber.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <9144EA2EEBA7AA4594DADC1AB5C1BA8F@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-20_11:2013-09-20,2013-09-20,1970-01-01 signatures=0 Cc: freebsd-fs , Devin Teske , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 23:55:59 -0000 On Sep 20, 2013, at 4:51 PM, Glen Barber wrote: > On Fri, Sep 20, 2013 at 11:44:54PM +0000, Teske, Devin wrote: >> Hi, >>=20 >> I recently upgraded a ZFS pool on my system and the reported version >> changed from "14" to "-" and I'm wondering if this is a bug. >>=20 >> dteske@hvm2a ~ $ zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> LSI-RAID1 1.39T 6.58G 1.39T 0% 1.00x ONLINE - >> NEC2_POOL_A 3.91T 126K 3.91T 0% 1.00x ONLINE - >> dteske@hvm2a ~ $ zpool status >> pool: LSI-RAID1 >> state: ONLINE >> status: The pool is formatted using a legacy on-disk format. The pool c= an >> still be used, but some features are unavailable. >> action: Upgrade the pool using 'zpool upgrade'. Once this is done, the >> pool will no longer be accessible on software that does not support fea= ture >> flags. >> scan: none requested >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> LSI-RAID1 ONLINE 0 0 0 >> mfid0s1g ONLINE 0 0 0 >> mfid1 ONLINE 0 0 0 >>=20 >> errors: No known data errors >>=20 >> pool: NEC2_POOL_A >> state: ONLINE >> status: The pool is formatted using a legacy on-disk format. The pool c= an >> still be used, but some features are unavailable. >> action: Upgrade the pool using 'zpool upgrade'. Once this is done, the >> pool will no longer be accessible on software that does not support fea= ture >> flags. >> scan: none requested >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> NEC2_POOL_A ONLINE 0 0 0 >> multipath/NEC2_LUN_A ONLINE 0 0 0 >>=20 >> errors: No known data errors >> dteske@hvm2a ~ $ zpool get version >> NAME PROPERTY VALUE SOURCE >> LSI-RAID1 version 14 local >> NEC2_POOL_A version 14 local >>=20 >>=20 >> =3D=3D=3D Now for the upgrade =3D=3D=3D >>=20 >>=20 >> dteske@hvm2a ~ $ uname -a >> FreeBSD hvm2a 8.4-STABLE FreeBSD 8.4-STABLE #2 r255470M: Wed Sep 11 01:2= 9:15 UTC 2013 dteske@push840-64.vicor.com:/usr/src/sys/amd64/compile/FI= S-amd64 amd64 >> dteske@hvm2a ~ $ sr zpool upgrade -a >> [sudo] Password: >> This system supports ZFS pool feature flags. >>=20 >> Successfully upgraded 'LSI-RAID1' from version 14 to feature flags. >> Enabled the following features on 'LSI-RAID1': >> async_destroy >> empty_bpobj >> lz4_compress >>=20 >> Successfully upgraded 'NEC2_POOL_A' from version 14 to feature flags. >> Enabled the following features on 'NEC2_POOL_A': >> async_destroy >> empty_bpobj >> lz4_compress >>=20 >> dteske@hvm2a ~ $ zpool get version >> NAME PROPERTY VALUE SOURCE >> LSI-RAID1 version - default >> NEC2_POOL_A version - default >>=20 >> =3D=3D=3D Why doesn't it say 28?? =3D=3D=3D >>=20 >=20 > Because it isn't version 28. Since the feature flags > (zpool-features(7)), the zpool spa version is 5000. >=20 Thanks. I also happened across r236884 and am reading up on that now too. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Sat Sep 21 00:27:50 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB67E67D; Sat, 21 Sep 2013 00:27:50 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 883732BF2; Sat, 21 Sep 2013 00:27:50 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r8L0Rnb8027530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Sep 2013 19:27:49 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Fri, 20 Sep 2013 19:27:48 -0500 From: "Teske, Devin" To: freebsd-fs Subject: zfs upgrade hang Thread-Topic: zfs upgrade hang Thread-Index: AQHOtmFmwDDb9jiJXU6uozaRArj8/Q== Date: Sat, 21 Sep 2013 00:27:48 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBE11B0@LTCFISWMSGMB21.FNFIS.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <03BB7DA11991AD40B12378BB2452D473@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-20_11:2013-09-20,2013-09-20,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 00:27:50 -0000 Hi, Seem to be having an issue with "zfs upgrade" hanging. Please note that "zpool upgrade" seems to be fine... it's "zfs upgrade" tha= t hangs. The system is 8.4-STABLE @ r255470M amd64. The dataset versions prior to upgrade are 3 and after upgrade are 5. It doesn't always hang. But once it does, it's always in the following ^T s= tate: tx->tx_sync_done_cv You can let it sit there for minutes or hours, but it never completes or en= ters a different state. Also, you can't Ctrl-C it, you can't Ctrl-Z it, you can't = kill it, not even with `-9'. Further, anything like "zfs list" will hang. All the meanwhile, = the filesystem is readable and fine. The sure-fire way to hit this for us is to attempt a "-a" or "-r" or "-ra" = to do many datasets at once. However, doing one dataset at a time will work... until it too leads to the= same state. Once we hit this state (hung upgrade) we have to reboot. We've been able to get through all the datasets on a box by doing one-at-a-= time and rebooting when one hangs and ends up in this state but it's frustrating bec= ause we can usually only do a handful at a time before hitting the problem. Scripting it won't help. Also, we've tried unmounting the filesystems prior to upgrade too, that did= n't help. Updating libraries/binaries to r255747 didn't seem to help either. I guess = next step is to update the kernel to latest stable/8 (which is probably not far ahead of r2= 55470). Advice? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Sat Sep 21 00:40:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9C198C3; Sat, 21 Sep 2013 00:40:17 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 851692C6D; Sat, 21 Sep 2013 00:40:16 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r8L0eFIn016139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Sep 2013 19:40:15 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.202]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Fri, 20 Sep 2013 19:40:14 -0500 From: "Teske, Devin" To: freebsd-fs Subject: Re: zfs upgrade hang Thread-Topic: zfs upgrade hang Thread-Index: AQHOtmFmwDDb9jiJXU6uozaRArj8/ZnPrVOA Date: Sat, 21 Sep 2013 00:40:13 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FBE1299@LTCFISWMSGMB21.FNFIS.com> References: <13CA24D6AB415D428143D44749F57D720FBE11B0@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FBE11B0@LTCFISWMSGMB21.FNFIS.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DB63A132FD0FC49A19C4FCCB5F75403@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-20_11:2013-09-20,2013-09-20,1970-01-01 signatures=0 Cc: Devin Teske , "Teske, Devin" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 00:40:17 -0000 On Sep 20, 2013, at 5:27 PM, Teske, Devin wrote: > Hi, >=20 > Seem to be having an issue with "zfs upgrade" hanging. >=20 > Please note that "zpool upgrade" seems to be fine... it's "zfs upgrade" t= hat hangs. >=20 > The system is 8.4-STABLE @ r255470M amd64. >=20 > The dataset versions prior to upgrade are 3 and after upgrade are 5. >=20 > It doesn't always hang. But once it does, it's always in the following ^T= state: >=20 > tx->tx_sync_done_cv >=20 > You can let it sit there for minutes or hours, but it never completes or = enters a > different state. Also, you can't Ctrl-C it, you can't Ctrl-Z it, you can'= t kill it, not even > with `-9'. Further, anything like "zfs list" will hang. All the meanwhile= , the filesystem > is readable and fine. >=20 > The sure-fire way to hit this for us is to attempt a "-a" or "-r" or "-ra= " to do many datasets > at once. >=20 > However, doing one dataset at a time will work... until it too leads to t= he same state. >=20 > Once we hit this state (hung upgrade) we have to reboot. >=20 > We've been able to get through all the datasets on a box by doing one-at-= a-time and > rebooting when one hangs and ends up in this state but it's frustrating b= ecause we can > usually only do a handful at a time before hitting the problem. >=20 > Scripting it won't help. >=20 > Also, we've tried unmounting the filesystems prior to upgrade too, that d= idn't help. > Updating libraries/binaries to r255747 didn't seem to help either. I gues= s next step is to > update the kernel to latest stable/8 (which is probably not far ahead of = r255470). >=20 > Advice? Before you chime-in, I think I might have more to add to the puzzle. It would seem that the LSI-RAID1 pool is the problem. We always hang when trying to execute "zfs upgrade LSI-RAID1" despite the fact that we've done a "zfs upgrade" of everything underneath it. We've also done a "zfs upgrade" of other pools and their descendants on the same system without this hang. So I was thinking... what makes the "LSI-RAID1" pool different from, say, t= he "NEC1_POOL_A" pool. The answer is mount-point. LSI-RAID1 does not have a mountpoint, while everything else does. Here's the layout we have: hvm2b# zfs get version NAME PROPERTY VALUE SOURCE LSI-RAID1 version 3 - LSI-RAID1/vm version 5 - LSI-RAID1/vm/golden0 version 5 - LSI-RAID1/vm/golden0@pre-cfg0-snap1 version 3 - LSI-RAID1/vm/golden0@non-cfg0-snap1 version 3 - LSI-RAID1/vm/golden0@zxfer_4709_20130905025825 version 3 - LSI-RAID1/vm/ipu0c version 5 - LSI-RAID1/vm/ipu1c version 5 - LSI-RAID1/vm/ipu2c version 5 - LSI-RAID1/vm/oos0c version 5 - LSI-RAID1/vmbak version 5 - LSI-RAID1/vmbak/vm version 5 - NEC2_POOL_B version 5 - NEC2_POOL_B/oos0c version 5 - As you can see, while trying to work around this hang, we've been able to upgrade all the datasets with the exception of the one culprit (at the top). So... Did I discover a bug? Perhaps relating to "zfs upgrade" touching datasets t= hat don't have a mountpoint set? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Sat Sep 21 10:48:17 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7AFCB434 for ; Sat, 21 Sep 2013 10:48:17 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 406F327D6 for ; Sat, 21 Sep 2013 10:48:17 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 906854AC58; Sat, 21 Sep 2013 14:48:15 +0400 (MSK) Date: Sat, 21 Sep 2013 14:48:11 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <724152380.20130921144811@serebryakov.spb.ru> To: freebsd-fs Subject: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Kirk McKusick X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 10:48:17 -0000 Hello, freebsd-fs. My server paniced tonight with UFS problem: ufs/root[WRITE(offset=385499136, length=16384)]error = 22 g_vfs_done():ufs/root[WRITE(offset=385564672, length=16384)]error = 22 g_vfs_done():ufs/root[WRITE(offset=385712128, length=16384)]error = 22 g_vfs_done():ufs/root[WRITE(offset=385826816, length=16384)]error = 22 g_vfs_done():ufs/root[WRITE(offset=770703360, length=16384)]error = 22 g_vfs_done():ufs/root[WRITE(offset=770719744, length=16384)]error = 22 g_vfs_done():ufs/var[WRITE(offset=268539904, length=2048)]error = 22 /var: got error 22 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error cpuid = 0 KDB: stack backtrace: #0 0xffffffff8047a836 at kdb_backtrace+0x66 #1 0xffffffff8044382e at panic+0x1ce #2 0xffffffff8059c040 at clear_remove+0 #3 0xffffffff804bf835 at brelse+0x75 #4 0xffffffff804c2258 at bufdone+0x68 #5 0xffffffff804bcb0e at biodone+0xae #6 0xffffffff803e289c at g_io_schedule_up+0xac #7 0xffffffff803e2ffc at g_up_procbody+0x5c #8 0xffffffff804144ef at fork_exit+0x11f #9 0xffffffff805f53de at fork_trampoline+0xe and "fsck_ffs" refused to fix two OTHER (/usr and /tmp) SU+J-enabled FFSes with same messages: Journal file sequence mismatch XXX != YYY UNEXPECTED SU+J INCONSISTENCY INTERNAL ERROR: GOT TO reply() UNIXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY and exited with signal 11. So, here are two questions: (1) What does "error 22" mean? Disk doesn't show ANY errors in S.M.A.R.T. (and all internal tests are Ok). Also, here are NO ANY driver (AHCI) errors in post-mortem dump. It doesn't look like hardware problem. (2) How to avoid fsck refuses in such situations? Why OTHER (not ones with write errors) FSes get errors? It looks like one another problem with SU+J. Please note, these FSes reside directly on SATA drive, without any software or hardware RAIDs. I have dumped both FSes with "dumpfs" and "dumpfs -f" before manual check and have block-dumped /tmp (as it is small enough). You could find them at http://lev.serebryakov.spb.ru/FreeBSD/suj-crash/ -- // Black Lion AKA Lev Serebryakov