From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 08:11:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F1D106564A for ; Sun, 22 Jan 2012 08:11:17 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 67A9A8FC08 for ; Sun, 22 Jan 2012 08:11:16 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2QV8d370WKsPpmd/9Y= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-4d06fd87.pool.mediaWays.net [77.6.253.135]) by smtp.strato.de (cohen mo8) (RZmta 27.5 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f00d89o0M6AwAb for ; Sun, 22 Jan 2012 09:11:00 +0100 (MET) Message-ID: <4F1BC493.10304@brockmann-consult.de> Date: Sun, 22 Jan 2012 09:10:59 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F193D90.9020703@digiware.nl> <20120121162906.0000518c@unknown> <4F1B0177.8080909@digiware.nl> <20120121230616.00006267@unknown> In-Reply-To: <20120121230616.00006267@unknown> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Question about ZFS with log and cache on SSD with GPT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 08:11:17 -0000 Am 21.01.2012 23:06, schrieb Alexander Leidinger: >> Corsair reports: >> > Max Random 4k Write (using IOMeter 08): 50k IOPS (4k aligned) >> > So I guess that suggests 4k aligned is required. > Sounds like it is. > I'm not an SSD expert, but I read as much as I can, and found that many say that the sector size is not the only thing that matters on an SSD, but also the *erase boundary*. The size of the erase boundary varies, but 2MiB is a common factor (or 1MiB for 99% of them), so you can use that for all. The theory I read about is that when the SSD wants to write something, it must erase the whole erase block first. If it needs to erase a whole erase boundary space to write 512 bytes, that is just normal. But if you are misaligned, it often needs to erase 2 erase boundary spaces. Here is an example from our FreeBSD forum: http://forums.freebsd.org/showthread.php?t=19093 > I create the first partition at the usual 63 sectors offset from the > start of the disk (track 1) which is /unaligned/ with the SSD erase > block. The second partition is set to start at sector 21030912 > (10767826944 bytes) which is /aligned/ with the SSD erase block. > SSD erase block boundaries vary from manufacturer to manufacturer, but > a safe number to assume should be 1 MiB (1048576 bytes). In my testing, it made no difference. But as daniel mentioned: > With ZFS, the 'alignment' is on per-vdev -- therefore you will need to recreate the mirror vdevs again using gnop to make them 4k aligned. But I just resilvered to add my aligned disks and remove the old. If that applies to erase boundaries, then it might have hurt my test. Peter From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 12:26:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 999411065670 for ; Sun, 22 Jan 2012 12:26:09 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE438FC08 for ; Sun, 22 Jan 2012 12:26:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RowUp-00082D-VF for freebsd-fs@freebsd.org; Sun, 22 Jan 2012 13:26:07 +0100 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Jan 2012 13:26:07 +0100 Received: from johannes by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Jan 2012 13:26:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Sun, 22 Jan 2012 12:25:54 +0000 Lines: 46 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 In-Reply-To: Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 12:26:09 -0000 On 19/01/2012 16:26, Andreas Nilsson wrote: > Hello, > > I'm trying to wrap my head around the process of booting from a zfs > snapshot. I have hit a few roadblocks, which I hope this is the adequate > list to post to regarding those. > > A short note on what I'm trying to achieve might be in order. In short: a > nanobsd system on zfs only. I want to boot from a snapshot so that when I > push out an upgrade with zfs send, I want the root filesystem to remain > unchanged. > > The problems I've hit so far: > *1 Making the zpool.cache file available > *2 Having / mount via entry in fstab. FWIW, I dont use any fstab for my zfs-only machine. Works perfectly fine with mountpoint property. > *1: The zpool.cache is needed to autoimport a pool as I understand it. Is > there a way to force the kernel to import a pool during bootup even though > no zpool.cache is around? What does this file actually contain? > > I made an experiment and booted a disk with zfs root from machine a in > machine b and that worked. I did partition the disk with gpart using a gpt > scheme, and labeled the partition on which the pool resides as os, and upon > creation of the zpool used gpt/os as device. Does this mean that as long as > gpt/os is available, any machine boot this disk will have the zpool > autoimported? Not quite sure I understand you here. Just a note: booting kernel and mounting root fs are two different things. the *zfsloader will happily load the kernel off a pool and boot it but mounting root might fail later (I guess if no cachefile is present?). > > *2: Having a line like > tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 > in fstab causes mount to throw an error and leave me in single user mode, > when the system is booted however mount can mount a zfs snapshot just fine. > Setting vfs.root.mountfrom in loader.conf works just fine though. -- Sent from my From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 15:50:10 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C559B1065672 for ; Sun, 22 Jan 2012 15:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9998F8FC0A for ; Sun, 22 Jan 2012 15:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0MFoAp6080473 for ; Sun, 22 Jan 2012 15:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0MFoASt080472; Sun, 22 Jan 2012 15:50:10 GMT (envelope-from gnats) Date: Sun, 22 Jan 2012 15:50:10 GMT Message-Id: <201201221550.q0MFoASt080472@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Dmitry Afanasiev Cc: Subject: Re: kern/164256: [zfs] device entry for volume is not created after zfs receive X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitry Afanasiev List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 15:50:10 -0000 The following reply was made to PR kern/164256; it has been noted by GNATS. From: Dmitry Afanasiev To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/164256: [zfs] device entry for volume is not created after zfs receive Date: Sun, 22 Jan 2012 19:41:20 +0400 If pool can't be reimported, below workaround may be used: zfs clone tank/vol2@snap tank/clone zfs promote tank/clone zfs destroy tank/vol2 zfs rename tank/clone tank/vol2 From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 16:13:15 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1F4106566C for ; Sun, 22 Jan 2012 16:13:15 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9553E8FC12 for ; Sun, 22 Jan 2012 16:13:14 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id EFE79153434; Sun, 22 Jan 2012 17:13:12 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax6hxPI_D9ht; Sun, 22 Jan 2012 17:13:12 +0100 (CET) Received: from [192.168.10.10] (vaio [192.168.10.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 39668153433; Sun, 22 Jan 2012 17:13:12 +0100 (CET) Message-ID: <4F1C3597.4040009@digiware.nl> Date: Sun, 22 Jan 2012 17:13:11 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Maloney References: <4F193D90.9020703@digiware.nl> <20120121162906.0000518c@unknown> <4F1B0177.8080909@digiware.nl> <20120121230616.00006267@unknown> <4F1BC493.10304@brockmann-consult.de> In-Reply-To: <4F1BC493.10304@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Question about ZFS with log and cache on SSD with GPT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:13:15 -0000 On 22-1-2012 9:10, Peter Maloney wrote: > Am 21.01.2012 23:06, schrieb Alexander Leidinger: >>> Corsair reports: >>>> Max Random 4k Write (using IOMeter 08): 50k IOPS (4k aligned) >>>> So I guess that suggests 4k aligned is required. >> Sounds like it is. >> > I'm not an SSD expert, but I read as much as I can, and found that many > say that the sector size is not the only thing that matters on an SSD, > but also the *erase boundary*. The size of the erase boundary varies, > but 2MiB is a common factor (or 1MiB for 99% of them), so you can use > that for all. > > The theory I read about is that when the SSD wants to write something, > it must erase the whole erase block first. If it needs to erase a whole > erase boundary space to write 512 bytes, that is just normal. But if you > are misaligned, it often needs to erase 2 erase boundary spaces. > > Here is an example from our FreeBSD forum: > http://forums.freebsd.org/showthread.php?t=19093 Thanx for this thread, there is a lot of usefull info there. pithy thing is to blow 66Mb, but then again on 40 or 120 Gb SSDs it is only marginal. (Guess it stems from the time that HDs where 5Mb :) ) I'm still not really shure that that is needed it the bios has nothing to do with these disks, as in our case: SSDs are only used as caches under ZFS. Especially the testing methods are useful. They are of course valid for any type partinioning... So getting things right on this level is the first required. >> I create the first partition at the usual 63 sectors offset from the >> start of the disk (track 1) which is /unaligned/ with the SSD erase >> block. The second partition is set to start at sector 21030912 >> (10767826944 bytes) which is /aligned/ with the SSD erase block. > >> SSD erase block boundaries vary from manufacturer to manufacturer, but >> a safe number to assume should be 1 MiB (1048576 bytes). I'd consider using 1Mib as a boundary. And compare that to the ~66MB boundary as suggested by aragon. > In my testing, it made no difference. But as daniel mentioned: > >> With ZFS, the 'alignment' is on per-vdev -- therefore you will need to recreate the mirror vdevs again using gnop to make them 4k aligned. > But I just resilvered to add my aligned disks and remove the old. If > that applies to erase boundaries, then it might have hurt my test. I'm not treally fluent in ZFS lingo, but the vdev is what makes up my zfsdata pool? And the alignment in there carries over to the caches underneath? So what is the consequence if ashift = 9, and the partitions are nicely aligned even on the rease-boundary..... --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 18:35:24 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EC18106566C; Sun, 22 Jan 2012 18:35:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 00A3A8FC0C; Sun, 22 Jan 2012 18:35:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0MIZNP4036490; Sun, 22 Jan 2012 18:35:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0MIZN7N036486; Sun, 22 Jan 2012 18:35:23 GMT (envelope-from linimon) Date: Sun, 22 Jan 2012 18:35:23 GMT Message-Id: <201201221835.q0MIZN7N036486@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164370: [zfs] zfs destroy for snapshot fails on i386 and sparc64 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 18:35:24 -0000 Old Synopsis: zfs destroy for snapshot fails on i386 New Synopsis: [zfs] zfs destroy for snapshot fails on i386 and sparc64 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 22 18:34:49 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164370 From owner-freebsd-fs@FreeBSD.ORG Sun Jan 22 20:15:57 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC8EE106564A for ; Sun, 22 Jan 2012 20:15:57 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63FCA8FC13 for ; Sun, 22 Jan 2012 20:15:56 +0000 (UTC) Received: by bkbc12 with SMTP id c12so2454148bkb.13 for ; Sun, 22 Jan 2012 12:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EL/nX5KbVuFUJqrz3hAtusSWD4dztbXjZYhvV3LvKdc=; b=RFlkMiVHodDLIJeA2lFdpOikPu/nZc7HnQH1QxRDlvi0RObnn/XMWE1XMKDOvqyJ9E v/Gi5emrZv8QuNJ4Tl2UB+k2yYogemF6jFmafpL73dksHDKXEx5ScMX3820DbzuAdRql sMOlNaADPbXmjw+sBRF5aQ1CkvVsXdA9SaSkk= MIME-Version: 1.0 Received: by 10.205.121.145 with SMTP id gc17mr2176317bkc.23.1327263356172; Sun, 22 Jan 2012 12:15:56 -0800 (PST) Received: by 10.204.40.74 with HTTP; Sun, 22 Jan 2012 12:15:56 -0800 (PST) In-Reply-To: References: Date: Sun, 22 Jan 2012 21:15:56 +0100 Message-ID: From: Andreas Nilsson To: Johannes Totz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 20:15:57 -0000 On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz wrote: > On 19/01/2012 16:26, Andreas Nilsson wrote: > >> Hello, >> >> I'm trying to wrap my head around the process of booting from a zfs >> snapshot. I have hit a few roadblocks, which I hope this is the adequate >> list to post to regarding those. >> >> A short note on what I'm trying to achieve might be in order. In short: a >> nanobsd system on zfs only. I want to boot from a snapshot so that when I >> push out an upgrade with zfs send, I want the root filesystem to remain >> unchanged. >> >> The problems I've hit so far: >> *1 Making the zpool.cache file available >> *2 Having / mount via entry in fstab. >> > > FWIW, I dont use any fstab for my zfs-only machine. Works perfectly fine > with mountpoint property. It was just a small hope that the boot would continue with the filesystem pointed out by the bootfs property. I'm setting vfs.root.mountfrom in loader.conf now. > > > *1: The zpool.cache is needed to autoimport a pool as I understand it. Is >> there a way to force the kernel to import a pool during bootup even though >> no zpool.cache is around? What does this file actually contain? >> >> I made an experiment and booted a disk with zfs root from machine a in >> machine b and that worked. I did partition the disk with gpart using a gpt >> scheme, and labeled the partition on which the pool resides as os, and >> upon >> creation of the zpool used gpt/os as device. Does this mean that as long >> as >> gpt/os is available, any machine boot this disk will have the zpool >> autoimported? >> > > Not quite sure I understand you here. Just a note: booting kernel and > mounting root fs are two different things. the *zfsloader will happily load > the kernel off a pool and boot it but mounting root might fail later (I > guess if no cachefile is present?). > > Sorry for being unclear. What I experience is exactly what you're describing: gptzfsloader loads the kernel and runs it just fine, but mounting root fails due to missing zpool.cache. I'm looking for a way to have the pool imported without the zpool.cache > > >> *2: Having a line like >> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 >> in fstab causes mount to throw an error and leave me in single user mode, >> when the system is booted however mount can mount a zfs snapshot just >> fine. >> Setting vfs.root.mountfrom in loader.conf works just fine though. >> > > The above I still think is rather strange: setting vfs.root.mountfrom to a snapshot ( given that the snapshot has the zpool.cache file) works, but not having the corresponding line in fstab. > > > -- > Sent from my > What I'm seeking a solution to is this: Boot several machines from one zfs snapshot. Since the stream from zfs send is also used to do the initial install there is no easy way to get the correct zpool.cache file in the snapshot. I guess one possible way to tackle this problem is to modify zpool so that all pools get created with the same id. Regards Andreas From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 00:53:27 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84950106566C for ; Mon, 23 Jan 2012 00:53:27 +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 3F42F8FC08 for ; Mon, 23 Jan 2012 00:53:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAOquHE+DaFvO/2dsb2JhbABDhQmqIYIcgQsCDRkCoU+OC5B2gS+HW4IGgRYEiDuMXpJs X-IronPort-AV: E=Sophos;i="4.71,553,1320642000"; d="scan'208";a="156281201" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 22 Jan 2012 19:53:26 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 19C18B3FF1 for ; Sun, 22 Jan 2012 19:53:26 -0500 (EST) Date: Sun, 22 Jan 2012 19:53:26 -0500 (EST) From: Rick Macklem To: freebsd-fs@freebsd.org Message-ID: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 00:53:27 -0000 Hi, There is a bug in the NFS clients, where a "mount -u -o udp /mnt" will cause any threads that have an RPC in progress to hang, if the mount previously was using too large an rsize/wsize. This case can easily be detected in nfs_mount(). However, my question is... - Should the "mount -u" fail and return an error OR Silently ignore the "udp" option and return ok. I ask because the NFS clients currently silently clear flags like NFSMNT_NFSV3 and NFSMNT_NOLOCKD because they can't be changed and then nfs_mount() returns 0, assuming any other options work. I am also not sure if having a "mount -u" fail for a diskless root fs will result in serious problems. (I don't currently have a diskless root setup to try this on.) Any comments w.r.t. which is the preferred way to handle this? rick From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 01:07:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 332B2106566B; Mon, 23 Jan 2012 01:07:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C88168FC0C; Mon, 23 Jan 2012 01:07:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOexHE+DaFvO/2dsb2JhbABDFoRzqiGBcgEBBSNWGxgCAg0ZAlkGiBemY5B3gS+CT4cSgRYEiDuMXpJs X-IronPort-AV: E=Sophos;i="4.71,553,1320642000"; d="scan'208";a="153225399" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 22 Jan 2012 20:07:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A576BB3F77; Sun, 22 Jan 2012 20:07:07 -0500 (EST) Date: Sun, 22 Jan 2012 20:07:07 -0500 (EST) From: Rick Macklem To: Pawel Jakub Dawidek Message-ID: <302457513.709293.1327280827625.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111127105913.GH8794@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org Subject: Re: NFS corruption in recent HEAD. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 01:07:09 -0000 Pawel Jakub Dawidek wrote: > On Sat, Nov 26, 2011 at 09:03:46PM -0500, Rick Macklem wrote: > > Pawel Jakub Dawidek wrote: > > > Hi. > > > > > > I'm booting machine over the network using new NFS client and I'm > > > getting those warnings on boot: > > > > > > /etc/rc.subr: 666: Syntax error: "(" unexpected (expecting ";;") > [...] > > Oh, and maybe you could try reverting r227543 in the client > > (assuming > > the client is post-r227543). Maybe that file's vnode type isn't set > > to > > VREG early in the diskless booting and needs the ncl_flush() for > > some > > reason. > > > > I don't actually have a bug that needs r227543 to fix it. It just > > seemed > > incorrect to flush non-VREG files (particularily VDIR). As such, > > reverting > > it wouldn't be a big deal. > > I haven't tried reverting anything yet, but I think I was able to > reproduce this with old NFS client as well. The problem goes away when > I > comment out root mount point from /etc/fstab or remove mntudp from > mount > options. NFS root is mounted using TCP, AFAIK and it probably happens > when startup scripts (rc.d/mountcritremote) remounts root with mntudp > flag. The rc.subr warning starts to appear just after mountcritremote > is > called. > I finally got around to poking at this and found there are 2 bugs in the NFS clients (the new and old use essentially the same code). 1 - If the rsize/wsize is greater than NFS_MAXDGRAMDATA (which will be the case for a default TCP mount) and an I/O RPC is in progress when "mount -u -o udp" is done, the thread(s) will get stuck retrying the RPC forever, since it tries to do an I/O greater than NFS_MAXDGRAMDATA. - The only fix I can see for this is to not allow the switch to UDP for this case. I'm not sure if "udp" should be silently ignored or "mount -u" should fail with an error. I've asked this question in a separate email. patch for "fail" version at http://people.freebsd.org/~rmacklem/udpupdate.patch 2 - If the rsize/wsize is changed by a "mount -u", data in the buffer cache can be corrupted. I think this is what you saw, above. I think the problem that causes this one is that the code above the buffer cache uses mnt_stat.f_iosize (which changes when rsize/wsize changes) instead of v_bufobj.bo_bsize, which is set to the value of mnt_stat.f_iosize when the vnode is created. patch at http://people.freebsd.org/~rmacklem/bobsize.patch Pawel, I don't know if it's convenient, but maybe you could test the patch for #2? (If you apply the patch for #1, the mount update will just fail, so you'll never exercise #2.) Also, if someone reading this is conversant with the buffer cache code, maybe they could review patch for #2? Thanks, rick ps: The above patches are for the new NFS client, but essentially the same patches could be applied to the old one. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 11:07:02 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABDD1065679 for ; Mon, 23 Jan 2012 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D71948FC28 for ; Mon, 23 Jan 2012 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0NB72f4080919 for ; Mon, 23 Jan 2012 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0NB72t0080917 for freebsd-fs@FreeBSD.org; Mon, 23 Jan 2012 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jan 2012 11:07:02 GMT Message-Id: <201201231107.q0NB72t0080917@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 Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 11:07:03 -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/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/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work 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/161511 fs [unionfs] Filesystem deadlocks when using multiple uni 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 o 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/159971 fs [ffs] [panic] panic with soft updates journaling durin o kern/159930 fs [ufs] [panic] kernel core o kern/159663 fs [socket] [nullfs] sockets don't work though nullfs mou 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/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition 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 f 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/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable 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 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/151111 fs [zfs] vnodes leakage during zfs unmount 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/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take 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 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/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( 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/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo 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/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 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/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 f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW 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 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 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 f kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani 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 kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system 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 kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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/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/51583 fs [nullfs] [patch] allow to work with devices and socket 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 263 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 12:58:51 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5120B1065672 for ; Mon, 23 Jan 2012 12:58:51 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D5D558FC0A for ; Mon, 23 Jan 2012 12:58:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RpJU1-0003w5-RM for freebsd-fs@freebsd.org; Mon, 23 Jan 2012 13:58:49 +0100 Received: from dyn1203-144.wlan.ic.ac.uk ([129.31.203.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Jan 2012 13:58:49 +0100 Received: from johannes by dyn1203-144.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Jan 2012 13:58:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Mon, 23 Jan 2012 12:58:34 +0000 Lines: 90 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1203-144.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 In-Reply-To: Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 12:58:51 -0000 On 22/01/2012 20:15, Andreas Nilsson wrote: > On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz wrote: > >> On 19/01/2012 16:26, Andreas Nilsson wrote: >> >>> Hello, >>> >>> I'm trying to wrap my head around the process of booting from a zfs >>> snapshot. I have hit a few roadblocks, which I hope this is the adequate >>> list to post to regarding those. >>> >>> A short note on what I'm trying to achieve might be in order. In short: a >>> nanobsd system on zfs only. I want to boot from a snapshot so that when I >>> push out an upgrade with zfs send, I want the root filesystem to remain >>> unchanged. >>> >>> The problems I've hit so far: >>> *1 Making the zpool.cache file available >>> *2 Having / mount via entry in fstab. >>> >> >> FWIW, I dont use any fstab for my zfs-only machine. Works perfectly fine >> with mountpoint property. > > > It was just a small hope that the boot would continue with the filesystem > pointed out by the bootfs property. I'm setting vfs.root.mountfrom in > loader.conf now. > > >> >> >> *1: The zpool.cache is needed to autoimport a pool as I understand it. Is >>> there a way to force the kernel to import a pool during bootup even though >>> no zpool.cache is around? What does this file actually contain? >>> >>> I made an experiment and booted a disk with zfs root from machine a in >>> machine b and that worked. I did partition the disk with gpart using a gpt >>> scheme, and labeled the partition on which the pool resides as os, and >>> upon >>> creation of the zpool used gpt/os as device. Does this mean that as long >>> as >>> gpt/os is available, any machine boot this disk will have the zpool >>> autoimported? >>> >> >> Not quite sure I understand you here. Just a note: booting kernel and >> mounting root fs are two different things. the *zfsloader will happily load >> the kernel off a pool and boot it but mounting root might fail later (I >> guess if no cachefile is present?). >> > Sorry for being unclear. What I experience is exactly what you're > describing: gptzfsloader loads the kernel and runs it just fine, but > mounting root fails due to missing zpool.cache. > > I'm looking for a way to have the pool imported without the zpool.cache > > >> >> >>> *2: Having a line like >>> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 >>> in fstab causes mount to throw an error and leave me in single user mode, >>> when the system is booted however mount can mount a zfs snapshot just >>> fine. >>> Setting vfs.root.mountfrom in loader.conf works just fine though. >>> >> > The above I still think is rather strange: setting vfs.root.mountfrom to a > snapshot ( given that the snapshot has the zpool.cache file) works, but not > having the corresponding line in fstab. > >> >> >> -- >> Sent from my >> > > What I'm seeking a solution to is this: Boot several machines from one zfs > snapshot. Since the stream from zfs send is also used to do the initial > install there is no easy way to get the correct zpool.cache file in the > snapshot. I guess one possible way to tackle this problem is to modify > zpool so that all pools get created with the same id. There's a way to pre-load a zpool.cache via the loader (from an alternative location). Can't remember the correct variables to set right now... As for w/o any cache file... no idea. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 13:42:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB0E106566C for ; Mon, 23 Jan 2012 13:42:21 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91FB88FC0A for ; Mon, 23 Jan 2012 13:42:20 +0000 (UTC) Received: by bkbc12 with SMTP id c12so3167307bkb.13 for ; Mon, 23 Jan 2012 05:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=diVrYo8dYRAGz+1xMGAAzMGUIUHBYzBva6JFJ6I9lso=; b=f8mzXTsxCoE8SaZ4W7Ic/9gOGKt51Il3mogCw6nfaZJd83L/6K5G5DKBSApLBPcicB XWkfIJhSmreBuU8Vb5gSTDRf8Gp8RvnTfL+9/lAV8KfxL50LIPDFuRIHlFfjOJR1lMnT jFPhXe5HK0bciRxX+8xZjqciZTRgomKNcCFUg= MIME-Version: 1.0 Received: by 10.204.156.204 with SMTP id y12mr1655900bkw.113.1327326139401; Mon, 23 Jan 2012 05:42:19 -0800 (PST) Received: by 10.204.40.74 with HTTP; Mon, 23 Jan 2012 05:42:19 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Jan 2012 14:42:19 +0100 Message-ID: From: Andreas Nilsson To: Johannes Totz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:42:21 -0000 On Mon, Jan 23, 2012 at 1:58 PM, Johannes Totz wrote: > On 22/01/2012 20:15, Andreas Nilsson wrote: > >> On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz wrote: >> >> On 19/01/2012 16:26, Andreas Nilsson wrote: >>> >>> Hello, >>>> >>>> I'm trying to wrap my head around the process of booting from a zfs >>>> snapshot. I have hit a few roadblocks, which I hope this is the adequate >>>> list to post to regarding those. >>>> >>>> A short note on what I'm trying to achieve might be in order. In short: >>>> a >>>> nanobsd system on zfs only. I want to boot from a snapshot so that when >>>> I >>>> push out an upgrade with zfs send, I want the root filesystem to remain >>>> unchanged. >>>> >>>> The problems I've hit so far: >>>> *1 Making the zpool.cache file available >>>> *2 Having / mount via entry in fstab. >>>> >>>> >>> FWIW, I dont use any fstab for my zfs-only machine. Works perfectly fine >>> with mountpoint property. >>> >> >> >> It was just a small hope that the boot would continue with the filesystem >> pointed out by the bootfs property. I'm setting vfs.root.mountfrom in >> loader.conf now. >> >> >> >>> >>> *1: The zpool.cache is needed to autoimport a pool as I understand it. >>> Is >>> >>>> there a way to force the kernel to import a pool during bootup even >>>> though >>>> no zpool.cache is around? What does this file actually contain? >>>> >>>> I made an experiment and booted a disk with zfs root from machine a in >>>> machine b and that worked. I did partition the disk with gpart using a >>>> gpt >>>> scheme, and labeled the partition on which the pool resides as os, and >>>> upon >>>> creation of the zpool used gpt/os as device. Does this mean that as long >>>> as >>>> gpt/os is available, any machine boot this disk will have the zpool >>>> autoimported? >>>> >>>> >>> Not quite sure I understand you here. Just a note: booting kernel and >>> mounting root fs are two different things. the *zfsloader will happily >>> load >>> the kernel off a pool and boot it but mounting root might fail later (I >>> guess if no cachefile is present?). >>> >>> Sorry for being unclear. What I experience is exactly what you're >> describing: gptzfsloader loads the kernel and runs it just fine, but >> mounting root fails due to missing zpool.cache. >> >> I'm looking for a way to have the pool imported without the zpool.cache >> >> >> >>> >>> *2: Having a line like >>>> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 >>>> in fstab causes mount to throw an error and leave me in single user >>>> mode, >>>> when the system is booted however mount can mount a zfs snapshot just >>>> fine. >>>> Setting vfs.root.mountfrom in loader.conf works just fine though. >>>> >>>> >>> The above I still think is rather strange: setting vfs.root.mountfrom >> to a >> snapshot ( given that the snapshot has the zpool.cache file) works, but >> not >> having the corresponding line in fstab. >> >> >>> >>> -- >>> Sent from my >>> >>> >> What I'm seeking a solution to is this: Boot several machines from one zfs >> snapshot. Since the stream from zfs send is also used to do the initial >> install there is no easy way to get the correct zpool.cache file in the >> snapshot. I guess one possible way to tackle this problem is to modify >> zpool so that all pools get created with the same id. >> > > There's a way to pre-load a zpool.cache via the loader (from an > alternative location). Can't remember the correct variables to set right > now... > > As for w/o any cache file... no idea. > > Ok, I'll research that. If it could be loaded from another disk/partition I could really use it :) It is of course possible to edit the cachefile property of the zpool, but I think one can only set it to something relative the dataset from which one boots. Regards Andreas From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 13:58:51 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C589D106564A for ; Mon, 23 Jan 2012 13:58:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id A85D88FC12 for ; Mon, 23 Jan 2012 13:58:51 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id R1W11i0021bwxycAF1yrus; Mon, 23 Jan 2012 13:58:51 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id R1yp1i00N1t3BNj8e1yqy3; Mon, 23 Jan 2012 13:58:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 985A5102C19; Mon, 23 Jan 2012 05:58:49 -0800 (PST) Date: Mon, 23 Jan 2012 05:58:49 -0800 From: Jeremy Chadwick To: Andreas Nilsson Message-ID: <20120123135849.GA84966@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, Johannes Totz Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:58:51 -0000 On Mon, Jan 23, 2012 at 02:42:19PM +0100, Andreas Nilsson wrote: > On Mon, Jan 23, 2012 at 1:58 PM, Johannes Totz wrote: > > > On 22/01/2012 20:15, Andreas Nilsson wrote: > > > >> On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz wrote: > >> > >> On 19/01/2012 16:26, Andreas Nilsson wrote: > >>> > >>> Hello, > >>>> > >>>> I'm trying to wrap my head around the process of booting from a zfs > >>>> snapshot. I have hit a few roadblocks, which I hope this is the adequate > >>>> list to post to regarding those. > >>>> > >>>> A short note on what I'm trying to achieve might be in order. In short: > >>>> a > >>>> nanobsd system on zfs only. I want to boot from a snapshot so that when > >>>> I > >>>> push out an upgrade with zfs send, I want the root filesystem to remain > >>>> unchanged. > >>>> > >>>> The problems I've hit so far: > >>>> *1 Making the zpool.cache file available > >>>> *2 Having / mount via entry in fstab. > >>>> > >>>> > >>> FWIW, I dont use any fstab for my zfs-only machine. Works perfectly fine > >>> with mountpoint property. > >>> > >> > >> > >> It was just a small hope that the boot would continue with the filesystem > >> pointed out by the bootfs property. I'm setting vfs.root.mountfrom in > >> loader.conf now. > >> > >> > >> > >>> > >>> *1: The zpool.cache is needed to autoimport a pool as I understand it. > >>> Is > >>> > >>>> there a way to force the kernel to import a pool during bootup even > >>>> though > >>>> no zpool.cache is around? What does this file actually contain? > >>>> > >>>> I made an experiment and booted a disk with zfs root from machine a in > >>>> machine b and that worked. I did partition the disk with gpart using a > >>>> gpt > >>>> scheme, and labeled the partition on which the pool resides as os, and > >>>> upon > >>>> creation of the zpool used gpt/os as device. Does this mean that as long > >>>> as > >>>> gpt/os is available, any machine boot this disk will have the zpool > >>>> autoimported? > >>>> > >>>> > >>> Not quite sure I understand you here. Just a note: booting kernel and > >>> mounting root fs are two different things. the *zfsloader will happily > >>> load > >>> the kernel off a pool and boot it but mounting root might fail later (I > >>> guess if no cachefile is present?). > >>> > >>> Sorry for being unclear. What I experience is exactly what you're > >> describing: gptzfsloader loads the kernel and runs it just fine, but > >> mounting root fails due to missing zpool.cache. > >> > >> I'm looking for a way to have the pool imported without the zpool.cache > >> > >> > >> > >>> > >>> *2: Having a line like > >>>> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 > >>>> in fstab causes mount to throw an error and leave me in single user > >>>> mode, > >>>> when the system is booted however mount can mount a zfs snapshot just > >>>> fine. > >>>> Setting vfs.root.mountfrom in loader.conf works just fine though. > >>>> > >>>> > >>> The above I still think is rather strange: setting vfs.root.mountfrom > >> to a > >> snapshot ( given that the snapshot has the zpool.cache file) works, but > >> not > >> having the corresponding line in fstab. > >> > >> > >>> > >>> -- > >>> Sent from my > >>> > >>> > >> What I'm seeking a solution to is this: Boot several machines from one zfs > >> snapshot. Since the stream from zfs send is also used to do the initial > >> install there is no easy way to get the correct zpool.cache file in the > >> snapshot. I guess one possible way to tackle this problem is to modify > >> zpool so that all pools get created with the same id. > >> > > > > There's a way to pre-load a zpool.cache via the loader (from an > > alternative location). Can't remember the correct variables to set right > > now... > > > > As for w/o any cache file... no idea. > > > > Ok, I'll research that. If it could be loaded from another disk/partition > I could really use it :) > > It is of course possible to edit the cachefile property of the zpool, but > I think one can only set it to something relative the dataset from which > one boots. I believe this is what you're looking for: http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011556.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 14:38:32 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 974D3106564A; Mon, 23 Jan 2012 14:38:32 +0000 (UTC) (envelope-from martin.ranne@kockumsonics.com) Received: from webmail.kockumsonics.com (mail.kockumsonics.com [194.103.55.3]) by mx1.freebsd.org (Postfix) with ESMTP id E7E798FC15; Mon, 23 Jan 2012 14:38:31 +0000 (UTC) Received: from MAILGATE.sonet.local ([192.168.12.8]) by mailgate ([192.168.12.8]) with mapi id 14.01.0355.002; Mon, 23 Jan 2012 15:38:29 +0100 From: Martin Ranne To: Andriy Gapon Thread-Topic: zpool import reboots computer Thread-Index: AczWvHf/qf1tgj/cQ3aTdT164KORYwAAxbSAAARQzcD///SRAP//zVoQgABYagD//xWRYIADrTyA//zFgGA= Date: Mon, 23 Jan 2012 14:38:28 +0000 Message-ID: <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> In-Reply-To: <4F1AC995.7050506@FreeBSD.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" Subject: RE: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:38:32 -0000 >On 2012-01-21 15:20, Andriy Gapon wrote:=20 >>on 20/01/2012 11:09 Martin Ranne said the following: >>I tried again to get into the debugger. It will not always work as it fre= ezes before i get to the prompt most of the times but here it is. Any other= commands to run in the debugger to get better information to help solve th= is? >>I used the command zpool import -F -f -o readonly=3Don -R /mnt/serv06 zro= ot >>Result is the following >>Fatal trap 12: page fault while in kernel mode >>Fatal trap 12: page fault while in kernel mode >>cpuid =3D 0; cpuid =3D 5; apic id =3D 00 >>apic id =3D 05 >>fault virtual address =3D 0x38 >>fault virtual address =3D 0x88 >>fault code =3D supervisor read data, page not present >>fault code =3D supervisor read data, page not present >>instruction pointer =3D 0x20:0xffffffff814872a1 >>instruction pointer =3D 0x20:0xffffffff814a7ef5 >>stack pointer =3D 0x28:0xffffff8c0d564f00 >>stack pointer =3D 0x28:0xffffff8c0ffd7ad0 >>frame pointer =3D 0x28:0xffffff8c0d564f30 >>frame pointer =3D 0x28:0xffffff8c0ffd7b40 >>code segment =3D base 0x0, limit 0xfffff, type 0x1b >>code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>processor eflags =3D processor eflags =3D interrupt enabled, = >>interrupt enabled, resume, resume, IOPL =3D 0 >>IOPL =3D 0 >>current process =3D current process =3D 0 (system_t= ask1_3) >>26[ thread pid 0 tid 100099 ] >>Stopped at vdev_is_dead+0x1: cmpq $0x5,0x28(%rdi) >>db> bt >>Tracing pid 0 tid 100099 td 0xfffffe000e546460 >>vdev_is_dead() at vdev_is_dead+0x1 >>vdev_mirror_child_select() at vdev_mirror_child_select+0x67 >>vdev_mirror_io_start() at vdev_mirror_io_start+0x24c >>zio_vdev_io_start() at zio_vdev_io_start+0x232 >>zio_execute() at zio_execute+0xc3 >>zio_gang_assemble() at zio_gang_assemble+0x1b >>zio_execute() at zio_execute+0xc3 >>arc_read_nolock() at arc_read_nolock+0x6d1 >>arc_read() at arc_read+0x93 >>traverse_prefetcher() at traverse_prefetcher+0x103 >>traverse_visitbp() at traverse_visitbp+0x21c >>traverse_dnode() at traverse_dnode+0x7c >>traverse_visitbp() at traverse_visitbp+0x3ff >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_dnode() at traverse_dnode+0x7c >>traverse_visitbp() at traverse_visitbp+0x48c >>traverse_prefetch_thread() at traverse_prefetch_thread+0x78 >>taskq_run() at taskq_run+0x13 >>taskqueue_run_locked() at taskqueue_run_locked+0x85 >>taskqueue_thread_loop() at taskqueue_thread_loop+0x46 >>fork_exit() at fork_exit+0x11f >>fork_trampoline() at fork_trampoline+0xe >>--- trap 0, rip =3D 0, rsp =3D 0xffffff8c0d565d00, rbp =3D 0 --- >>db> >> > >To me it looks like in the vdev_mirror_child_select function mc->mc_vd cou= ld be >NULL although the code doesn't expect it. You can add some code to the fu= nction >to check if the hypothesis is correct and to skip a loop if mc->mc_vd is N= ULL. >Such a hack is probably not needed in general, but given that your pool co= uld be >corrupted, this could be your chance to get access to it. > >BTW, restoring from backups is what is usually recommended first in a situ= ation >like this. > I know it would be recommended first to restore from backup but there were = backup failures. Am back after the weekend. I have done the hack in vdev_mirror_child_select= function as per the code below. if (mc->mc_tried || mc->mc_skipped) continue; # hack start if (mc->mc_vd =3D=3D NULL) break; # hack end if (!vdev_readable(mc->mc_vd)) { I am not getting the fault virtual address at 0x38 and 0x88 but instead get= two at 0x88. The function it stops at is zio_vdev_child_io. Is there anoth= er hack i could do there? Crash and bt below. Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x88 cpuid =3D 5; fault code =3D supervisor read data, page not presen= t apic id =3D 05 instruction pointer =3D 0x20:0xffffffff814a7ee5 fault virtual address =3D 0x88 stack pointer =3D 0x28:0xffffff8c0d564f00 fault code =3D supervisor read data, page not present frame pointer =3D 0x28:0xffffff8c0d564f70 instruction pointer =3D 0x20:0xffffffff814a7ee5 code segment =3D base 0x0, limit 0xfffff, type 0x1b stack pointer =3D 0x28:0xffffff8c1009aad0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 frame pointer =3D 0x28:0xffffff8c1009ab40 processor eflags =3D code segment =3D base 0x0, limit 0xfff= ff, type 0x1b interrupt enabled, =3D DPL 0, pres 1, long 1, def32 0,= gran 1 resume, processor eflags =3D IOPL =3D 0 interrupt enabled, current process =3D resume, 0 (system_taskq= _3) I[ thread pid 0 tid 100099 ] Stopped at zio_vdev_child_io+0x25: cmpq $0, 0x88(%r10) db> bt Tracing pid 0 tid 100099 td 0xfffffe000ee4e460 zio_vdev_child_io() at zio_vdev_child_io+0x25 vdev_mirror_io_start() at vdev_mirror_io_start+0x16c zio_vdev_io_start() at zio_vdev_io_start+0x232 zio_execute() at zio_execute+0xc3 zio_gang_assemble() at zio_gang_assemble+0x1b zio_execute() at zio_execute+0xc3 arc_read_nolock() at arc_read_nolock+0x6d1 arc_read() at arc_read+0x93 traverse_prefetcher() at traverse_prefetcher+0x103 traverse_visitbp() at traverse_visitbp+0x21c traverse_dnode() at traverse_dnode+0x7c traverse_visitbp() at traverse_visitbp+0x3ff traverse_visitbp() at traverse_visitbp+0x316 traverse_visitbp() at traverse_visitbp+0x316 traverse_visitbp() at traverse_visitbp+0x316 traverse_visitbp() at traverse_visitbp+0x316 traverse_visitbp() at traverse_visitbp+0x316 traverse_visitbp() at traverse_visitbp+0x316 traverse_dnode() at traverse_dnode+0x7c traverse_visitbp() at traverse_visitbp+0x48c traverse_prefetch_thread() at traverse_prefetch_thread+0x78 taskq_run() at taskq_run+0x13 taskqueue_run_locked() at taskqueue_run_locked+0x85 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8c0d565d00, rbp =3D 0 --- db> //Martin Ranne ________________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4760 - Release Date: 01/22/12 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 14:59:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADB72106566B for ; Mon, 23 Jan 2012 14:59:29 +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 12FBD8FC17 for ; Mon, 23 Jan 2012 14:59:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05873; Mon, 23 Jan 2012 16:59:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D75CD.6050000@FreeBSD.org> Date: Mon, 23 Jan 2012 16:59:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Ranne References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> In-Reply-To: <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:59:29 -0000 on 23/01/2012 16:38 Martin Ranne said the following: >> On 2012-01-21 15:20, Andriy Gapon wrote: >> To me it looks like in the vdev_mirror_child_select function mc->mc_vd could be >> NULL although the code doesn't expect it. You can add some code to the function >> to check if the hypothesis is correct and to skip a loop if mc->mc_vd is NULL. >> Such a hack is probably not needed in general, but given that your pool could be >> corrupted, this could be your chance to get access to it. >> >> BTW, restoring from backups is what is usually recommended first in a situation >> like this. >> > > I know it would be recommended first to restore from backup but there were backup failures. > > Am back after the weekend. I have done the hack in vdev_mirror_child_select function as per the code below. > if (mc->mc_tried || mc->mc_skipped) > continue; > # hack start > if (mc->mc_vd == NULL) > break; > # hack end > if (!vdev_readable(mc->mc_vd)) { > I am not getting the fault virtual address at 0x38 and 0x88 but instead get two at 0x88. The function it stops at is zio_vdev_child_io. Is there another hack i could do there? You could try a similar hack in vdev_mirror_io_start(). Please note that there are two loops in there. BTW, if you run kgdb /path/to/kernel/that/paniced, you can do e.g. 'info line *zio_vdev_child_io+0x25" to see on what line the trap occurred. > Crash and bt below. > Fatal trap 12: page fault while in kernel mode > cpuid = 1; > apic id = 01 > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x88 > cpuid = 5; fault code = supervisor read data, page not present > apic id = 05 > instruction pointer = 0x20:0xffffffff814a7ee5 > fault virtual address = 0x88 > stack pointer = 0x28:0xffffff8c0d564f00 > fault code = supervisor read data, page not present > frame pointer = 0x28:0xffffff8c0d564f70 > instruction pointer = 0x20:0xffffffff814a7ee5 > code segment = base 0x0, limit 0xfffff, type 0x1b > stack pointer = 0x28:0xffffff8c1009aad0 > = DPL 0, pres 1, long 1, def32 0, gran 1 > frame pointer = 0x28:0xffffff8c1009ab40 > processor eflags = code segment = base 0x0, limit 0xfffff, type 0x1b > interrupt enabled, = DPL 0, pres 1, long 1, def32 0, gran 1 > resume, processor eflags = IOPL = 0 > interrupt enabled, current process = resume, 0 (system_taskq_3) > I[ thread pid 0 tid 100099 ] > Stopped at zio_vdev_child_io+0x25: cmpq $0, 0x88(%r10) > db> bt > Tracing pid 0 tid 100099 td 0xfffffe000ee4e460 > zio_vdev_child_io() at zio_vdev_child_io+0x25 > vdev_mirror_io_start() at vdev_mirror_io_start+0x16c > zio_vdev_io_start() at zio_vdev_io_start+0x232 > zio_execute() at zio_execute+0xc3 > zio_gang_assemble() at zio_gang_assemble+0x1b > zio_execute() at zio_execute+0xc3 > arc_read_nolock() at arc_read_nolock+0x6d1 > arc_read() at arc_read+0x93 > traverse_prefetcher() at traverse_prefetcher+0x103 > traverse_visitbp() at traverse_visitbp+0x21c > traverse_dnode() at traverse_dnode+0x7c > traverse_visitbp() at traverse_visitbp+0x3ff > traverse_visitbp() at traverse_visitbp+0x316 > traverse_visitbp() at traverse_visitbp+0x316 > traverse_visitbp() at traverse_visitbp+0x316 > traverse_visitbp() at traverse_visitbp+0x316 > traverse_visitbp() at traverse_visitbp+0x316 > traverse_visitbp() at traverse_visitbp+0x316 > traverse_dnode() at traverse_dnode+0x7c > traverse_visitbp() at traverse_visitbp+0x48c > traverse_prefetch_thread() at traverse_prefetch_thread+0x78 > taskq_run() at taskq_run+0x13 > taskqueue_run_locked() at taskqueue_run_locked+0x85 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8c0d565d00, rbp = 0 --- > db> > > > //Martin Ranne > ________________________________________ > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1901 / Virus Database: 2109/4760 - Release Date: 01/22/12 -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 15:11:06 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA7AE1065670; Mon, 23 Jan 2012 15:11:06 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8458C8FC0C; Mon, 23 Jan 2012 15:11:06 +0000 (UTC) Received: by vcbfl17 with SMTP id fl17so2935834vcb.13 for ; Mon, 23 Jan 2012 07:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IzCMxa+vxLz0wwQQp/0/c4PSx5YXSAApAtqweR+k0VI=; b=PGiehfEIVjwD4RhDhoj0iOOpgVJajmbwvtL8KaExbLPG6Q9JsSAVXlqWCtdZCOX5GT 1yjCGber2egSK3hC5DM161U2wbFtSPUUYZx4wm4oUIuxzzeOXigADvHo1cqZONfAHgeW pHspbQAa4IC7Di/Q5NVmshmHNp4PBqxzvhvdU= MIME-Version: 1.0 Received: by 10.220.115.135 with SMTP id i7mr4693537vcq.40.1327329977280; Mon, 23 Jan 2012 06:46:17 -0800 (PST) Received: by 10.220.187.130 with HTTP; Mon, 23 Jan 2012 06:46:17 -0800 (PST) Date: Mon, 23 Jan 2012 17:46:17 +0300 Message-ID: From: Andrey Fesenko To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Root on ZFS & GPT and boot to ufs partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:11:06 -0000 System install for manual http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot only + freebsd-ufs (ada0p2) > uname -a FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r229812: Mon Jan 9 19:08:10 MSK 2012 andrey@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 > gpart show => 34 625142381 ada0 GPT (298G) 34 128 1 freebsd-boot (64k) 162 26621952 2 freebsd-ufs (12G) 26622114 8388608 3 freebsd-swap (4.0G) 35010722 590131693 4 freebsd-zfs (281G) boot code MBR (pmbr) and gptzfsboot loader In the old loader was F1,F2,F3.... new no :( Is there a way to boot system freebsd-ufs (ada0p2) From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 15:18:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8929D1065673 for ; Mon, 23 Jan 2012 15:18:26 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4D48FC17 for ; Mon, 23 Jan 2012 15:18:25 +0000 (UTC) Received: by werg1 with SMTP id g1so3461108wer.13 for ; Mon, 23 Jan 2012 07:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EGUJJtK/8du6O4snP/ciQhPRyVu7M1AXHUJox6EzlpQ=; b=YoDgIzZXK2Xr/a1Onbhs2+/T6Sf/8tvfoHTKjucwXM6E/1xwWZDi1bRMBrK+5cGdc3 oDvv42oKAHPRsavfHX33kR3ildjm94f0Q+cvTL7yGKaZkLpCLgzEPkVV8ilKKc8weVDX sQ9Lxy7fBiyjUKc+DjeL0w1fGribl0ALyz5mU= Received: by 10.216.133.91 with SMTP id p69mr1815377wei.30.1327331905008; Mon, 23 Jan 2012 07:18:25 -0800 (PST) Received: from green.tandem.local (32-179-132-95.pool.ukrtel.net. [95.132.179.32]) by mx.google.com with ESMTPS id m8sm20971178wia.11.2012.01.23.07.18.23 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 07:18:24 -0800 (PST) Message-ID: <4F1D7A3E.9050806@gmail.com> Date: Mon, 23 Jan 2012 17:18:22 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0.1) Gecko/20120110 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: Andrey Fesenko References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Root on ZFS & GPT and boot to ufs partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:18:26 -0000 Andrey Fesenko wrote: > System install for manual http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > only + freebsd-ufs (ada0p2) >> uname -a > FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r229812: Mon Jan 9 19:08:10 MSK 2012 > andrey@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >> gpart show > => 34 625142381 ada0 GPT (298G) > 34 128 1 freebsd-boot (64k) > 162 26621952 2 freebsd-ufs (12G) > 26622114 8388608 3 freebsd-swap (4.0G) > 35010722 590131693 4 freebsd-zfs (281G) > boot code MBR (pmbr) and gptzfsboot loader > > In the old loader was F1,F2,F3.... new no :( > > Is there a way to boot system freebsd-ufs (ada0p2) `gpart set -a bootonce -i 2 ada0` should do. -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 15:55:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A1E91065678 for ; Mon, 23 Jan 2012 15:55:12 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8998FC19 for ; Mon, 23 Jan 2012 15:55:05 +0000 (UTC) Received: from a91-153-116-96.elisa-laajakaista.fi (a91-153-116-96.elisa-laajakaista.fi [91.153.116.96]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id CBF26176001; Mon, 23 Jan 2012 17:38:34 +0200 (EET) Date: Mon, 23 Jan 2012 17:38:33 +0200 From: Jaakko Heinonen To: Rick Macklem Message-ID: <20120123153833.GB2246@a91-153-116-96.elisa-laajakaista.fi> References: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:55:12 -0000 On 2012-01-22, Rick Macklem wrote: > There is a bug in the NFS clients, where a > "mount -u -o udp /mnt" will cause any threads > that have an RPC in progress to hang, if the > mount previously was using too large an rsize/wsize. Does the hang occur if the UDP transport was already used? > This case can easily be detected in nfs_mount(). > > However, my question is... > - Should the "mount -u" fail and return an error > OR > Silently ignore the "udp" option and return ok. Depending on the answer to the question above, IMHO the best solution would be to return an error if user tries to change TCP to UDP but accept the "udp" option if UDP transport is already active. I don't know about potential problems with root nfs. -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 15:56:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F447106564A; Mon, 23 Jan 2012 15:56:56 +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 A6BED8FC08; Mon, 23 Jan 2012 15:56:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABOCHU+DaFvO/2dsb2JhbABDhQmqI4FyAQEEASNWGw4KAgINGQJZBi6HYacVkRuBL4lhgRYEiDuMXpJs X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="156355770" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Jan 2012 10:56:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C435FB3F1E; Mon, 23 Jan 2012 10:56:54 -0500 (EST) Date: Mon, 23 Jan 2012 10:56:54 -0500 (EST) From: Rick Macklem To: Jaakko Heinonen Message-ID: <219911446.737753.1327334214785.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120123153833.GB2246@a91-153-116-96.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:56:56 -0000 Jaakko Heinonen wrote: > On 2012-01-22, Rick Macklem wrote: > > There is a bug in the NFS clients, where a > > "mount -u -o udp /mnt" will cause any threads > > that have an RPC in progress to hang, if the > > mount previously was using too large an rsize/wsize. > > Does the hang occur if the UDP transport was already used? > I don't think so. I did test the case where it switched from TCP to UDP, but the TCP mount had rsize=16384,wsize=16384 and that was fine. The problem occurs when the rsize/wsize for the mount is > 16K before the change to UDP (which "can't" be the case if the mount is already UDP). The patch only generates an error if the old rsize/wsize is greater than 16K. Or, it could be easily re-written to silently ignore the request to switch to UDP. > > This case can easily be detected in nfs_mount(). > > > > However, my question is... > > - Should the "mount -u" fail and return an error > > OR > > Silently ignore the "udp" option and return ok. > > Depending on the answer to the question above, IMHO the best solution > would be to return an error if user tries to change TCP to UDP but > accept the "udp" option if UDP transport is already active. I don't > know > about potential problems with root nfs. > Yea, I feel returning an error makes more sense than silently ignoring the request. The concerns I had were related to diskless roots. Thanks for the comments, rick > -- > Jaakko From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 16:13:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 024A61065672; Mon, 23 Jan 2012 16:13:40 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A0EB58FC0A; Mon, 23 Jan 2012 16:13:39 +0000 (UTC) Received: by vbbey12 with SMTP id ey12so3003267vbb.13 for ; Mon, 23 Jan 2012 08:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X7thbNFkl5wJpqpXeutcerbjoGvPVK+GnI66rcr5AGY=; b=eGdQqcEZ0b1XafmCJFJ8YA0HkWfhXqGlBPxY0rmJJEWVLp35O1Mb2sc/5cu5FaMhFN pCMTnRSi5ryEGjEVcauMFfkdo8yNAQ3ScQR+xeAjj+UhCFOlf8IYcXqXRN7IoPwydkF9 ESgVflbjiVTEVps69ToN97Q/LpqnuUughIKTU= MIME-Version: 1.0 Received: by 10.52.71.33 with SMTP id r1mr4202655vdu.113.1327335218962; Mon, 23 Jan 2012 08:13:38 -0800 (PST) Received: by 10.220.187.130 with HTTP; Mon, 23 Jan 2012 08:13:38 -0800 (PST) In-Reply-To: <4F1D7A3E.9050806@gmail.com> References: <4F1D7A3E.9050806@gmail.com> Date: Mon, 23 Jan 2012 19:13:38 +0300 Message-ID: From: Andrey Fesenko To: Volodymyr Kostyrko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Root on ZFS & GPT and boot to ufs partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:13:40 -0000 On Mon, Jan 23, 2012 at 7:18 PM, Volodymyr Kostyrko wro= te: > Andrey Fesenko wrote: >> >> System install for manual http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot >> only + freebsd-ufs (ada0p2) >>> >>> uname -a >> >> FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 >> r229812: Mon Jan =C2=A09 19:08:10 MSK 2012 >> andrey@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK =C2=A0amd64 >>> >>> gpart show >> >> =3D> =C2=A0 =C2=A0 =C2=A0 =C2=A034 =C2=A0625142381 =C2=A0ada0 =C2=A0GPT = =C2=A0(298G) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A034 =C2=A0 =C2=A0 =C2=A0 =C2=A0128 =C2= =A0 =C2=A0 1 =C2=A0freebsd-boot =C2=A0(64k) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 162 =C2=A0 26621952 =C2=A0 =C2=A0 2 =C2=A0fr= eebsd-ufs =C2=A0(12G) >> =C2=A0 =C2=A026622114 =C2=A0 =C2=A08388608 =C2=A0 =C2=A0 3 =C2=A0freebsd= -swap =C2=A0(4.0G) >> =C2=A0 =C2=A035010722 =C2=A0590131693 =C2=A0 =C2=A0 4 =C2=A0freebsd-zfs = =C2=A0(281G) >> boot code MBR (pmbr) and gptzfsboot loader >> >> In the old loader was F1,F2,F3.... new no :( >> >> Is there a way to boot system freebsd-ufs (ada0p2) > > > `gpart set -a bootonce -i 2 ada0` should do. > > -- > Sphinx of black quartz judge my vow. # gpart set -a bootonce -i 2 ada0 bootonce set on ada0p2 #shutdown -r now No, not work. After reboot freebsd-zfs (ada0p4) From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 16:22:21 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B8A1065673 for ; Mon, 23 Jan 2012 16:22:21 +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 549A48FC0A for ; Mon, 23 Jan 2012 16:22:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06791; Mon, 23 Jan 2012 18:22:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F1D8938.1070605@FreeBSD.org> Date: Mon, 23 Jan 2012 18:22:16 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Andrey Fesenko References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Root on ZFS & GPT and boot to ufs partition X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:22:21 -0000 on 23/01/2012 16:46 Andrey Fesenko said the following: > System install for manual http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > only + freebsd-ufs (ada0p2) >> uname -a > FreeBSD beastie.mydomain.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r229812: Mon Jan 9 19:08:10 MSK 2012 > andrey@beastie.mydomain.local:/usr/obj/usr/src/sys/W_BOOK amd64 >> gpart show > => 34 625142381 ada0 GPT (298G) > 34 128 1 freebsd-boot (64k) > 162 26621952 2 freebsd-ufs (12G) > 26622114 8388608 3 freebsd-swap (4.0G) > 35010722 590131693 4 freebsd-zfs (281G) > boot code MBR (pmbr) and gptzfsboot loader As far as I remember gpt*zfs*boot boots only ZFS. Also, gptzfsboot is not a loader in the FreeBSD terminology, it's a (boot2-like) boot block. loader and zfsloader are loaders. > In the old loader was F1,F2,F3.... new no :( > > Is there a way to boot system freebsd-ufs (ada0p2) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 18:33:07 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C7C71065677; Mon, 23 Jan 2012 18:33:07 +0000 (UTC) (envelope-from martin.ranne@kockumsonics.com) Received: from webmail.kockumsonics.com (mail.kockumsonics.com [194.103.55.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3528FC1A; Mon, 23 Jan 2012 18:33:05 +0000 (UTC) Received: from MAILGATE.sonet.local ([192.168.12.8]) by mailgate ([192.168.12.8]) with mapi id 14.01.0355.002; Mon, 23 Jan 2012 19:33:03 +0100 From: Martin Ranne To: Andriy Gapon Thread-Topic: zpool import reboots computer Thread-Index: AczWvHf/qf1tgj/cQ3aTdT164KORYwAAxbSAAARQzcD///SRAP//zVoQgABYagD//xWRYIADrTyA//zFgGAAzUT8gP//s7ww Date: Mon, 23 Jan 2012 18:33:03 +0000 Message-ID: <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> <4F1D75CD.6050000@FreeBSD.org> In-Reply-To: <4F1D75CD.6050000@FreeBSD.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-fs@freebsd.org" Subject: RE: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:33:07 -0000 >On 2012-01-23 15:59, Andriy Gapon wrote:=20 >>on 23/01/2012 16:38 Martin Ranne said the following: >>>To me it looks like in the vdev_mirror_child_select function mc->mc_vd c= ould be >>>NULL although the code doesn't expect it. You can add some code to the = function >>>to check if the hypothesis is correct and to skip a loop if mc->mc_vd is= NULL. >>>Such a hack is probably not needed in general, but given that your pool = could be >>>corrupted, this could be your chance to get access to it. >>>BTW, restoring from backups is what is usually recommended first in a si= tuation >>>like this. >>I know it would be recommended first to restore from backup but there wer= e backup failures. >>Am back after the weekend. I have done the hack in vdev_mirror_child_sele= ct function as per the code below. >>if (mc->mc_tried || mc->mc_skipped) >> continue; >># hack start >>if (mc->mc_vd =3D=3D NULL) >> break; >># hack end >>if (!vdev_readable(mc->mc_vd)) { >>I am not getting the fault virtual address at 0x38 and 0x88 but instead g= et two at 0x88. The function it stops at is zio_vdev_child_io. Is there ano= ther hack i could do there? >You could try a similar hack in vdev_mirror_io_start(). >Please note that there are two loops in there. >BTW, if you run kgdb /path/to/kernel/that/paniced, you can do e.g. 'info l= ine >*zio_vdev_child_io+0x25" to see on what line the trap occurred. >I have now tried with the hack in vdev_mirror_io_start() like below and th= e one i previously did in vdev_mirror_child_select(). Unfortunately I get t= he same crash as i sent earlier today. It takes time to get into DDB for a = crash as >the computer freezes 19/20 times when i do the zpool import and i= f i try to save a dump, the comptuer freezes so I can not use that. Have done some checking and found mc->mc_vd =3D=3D NULL in the function vde= v_mirror_io_start() where the while-loop is.=20 while (children--) {=20 mc =3D &mm->mm_child[c]; zio_nowait(zio_vdev_child_io(zio, zio->io_bp, mc->mc_vd, mc->mc_offset, zio->io_data, zio->io_size, zio->io_type, zio->io_priority, 0, vdev_mirror_child_done, mc)); c++; } if i set a break before it runs zio_nowait() it will still crash the kernel= .=20 What can i check next for it to be able to continue? Is it possible to have= it ignore the child where mc_vd is NULL? I am also looking into what more = I can do to debug it (adding code to print to console as i can not use kern= el dumps). >>Crash and bt below. >>Fatal trap 12: page fault while in kernel mode >>cpuid =3D 1; >>apic id =3D 01 >>Fatal trap 12: page fault while in kernel mode >>fault virtual address =3D 0x88 >>cpuid =3D 5; fault code =3D supervisor read data, page not pres= ent >>apic id =3D 05 >>instruction pointer =3D 0x20:0xffffffff814a7ee5 >>fault virtual address =3D 0x88 >>stack pointer =3D 0x28:0xffffff8c0d564f00 >>fault code =3D supervisor read data, page not present >>frame pointer =3D 0x28:0xffffff8c0d564f70 >>instruction pointer =3D 0x20:0xffffffff814a7ee5 >>code segment =3D base 0x0, limit 0xfffff, type 0x1b >>stack pointer =3D 0x28:0xffffff8c1009aad0 >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>frame pointer =3D 0x28:0xffffff8c1009ab40 >>processor eflags =3D code segment =3D base 0x0, limit 0xf= ffff, type 0x1b >>interrupt enabled, =3D DPL 0, pres 1, long 1, def32 = 0, gran 1 >>resume, processor eflags =3D IOPL =3D 0 >>interrupt enabled, current process =3D resume, 0 (system_tas= kq_3) >>I[ thread pid 0 tid 100099 ] >>Stopped at zio_vdev_child_io+0x25: cmpq $0, 0x88(%r10) >>db> bt >>Tracing pid 0 tid 100099 td 0xfffffe000ee4e460 >>zio_vdev_child_io() at zio_vdev_child_io+0x25 >>vdev_mirror_io_start() at vdev_mirror_io_start+0x16c >>zio_vdev_io_start() at zio_vdev_io_start+0x232 >>zio_execute() at zio_execute+0xc3 >>zio_gang_assemble() at zio_gang_assemble+0x1b >>zio_execute() at zio_execute+0xc3 >>arc_read_nolock() at arc_read_nolock+0x6d1 >>arc_read() at arc_read+0x93 >>traverse_prefetcher() at traverse_prefetcher+0x103 >>traverse_visitbp() at traverse_visitbp+0x21c >>traverse_dnode() at traverse_dnode+0x7c >>traverse_visitbp() at traverse_visitbp+0x3ff >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_visitbp() at traverse_visitbp+0x316 >>traverse_dnode() at traverse_dnode+0x7c >>traverse_visitbp() at traverse_visitbp+0x48c >>traverse_prefetch_thread() at traverse_prefetch_thread+0x78 >>taskq_run() at taskq_run+0x13 >>taskqueue_run_locked() at taskqueue_run_locked+0x85 >>taskqueue_thread_loop() at taskqueue_thread_loop+0x46 >>fork_exit() at fork_exit+0x11f >>fork_trampoline() at fork_trampoline+0xe >>--- trap 0, rip =3D 0, rsp =3D 0xffffff8c0d565d00, rbp =3D 0 --- >>db> >> >> >>//Martin Ranne ________________________________________ ________________________________________ No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4761 - Release Date: 01/23/12 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 20:31:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38B1D1065672 for ; Mon, 23 Jan 2012 20:31:29 +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 8135C8FC14 for ; Mon, 23 Jan 2012 20:31:28 +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 WAA09110; Mon, 23 Jan 2012 22:31:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RpQXz-00002b-PJ; Mon, 23 Jan 2012 22:31:23 +0200 Message-ID: <4F1DC398.3050502@FreeBSD.org> Date: Mon, 23 Jan 2012 22:31:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Ranne References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> <4F1D75CD.6050000@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> In-Reply-To: <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" Subject: Re: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:31:29 -0000 on 23/01/2012 20:33 Martin Ranne said the following: > Have done some checking and found mc->mc_vd == NULL in the function vdev_mirror_io_start() where the while-loop is. > > while (children--) { > mc = &mm->mm_child[c]; > zio_nowait(zio_vdev_child_io(zio, zio->io_bp, > mc->mc_vd, mc->mc_offset, zio->io_data, zio->io_size, > zio->io_type, zio->io_priority, 0, > vdev_mirror_child_done, mc)); > c++; > } > > if i set a break before it runs zio_nowait() it will still crash the kernel. > What can i check next for it to be able to continue? Is it possible to have it ignore the child where mc_vd is NULL? I am also looking into what more I can do to debug it (adding code to print to console as i can not use kernel dumps). Not sure. If by "set a break" you mean inserting a break statement, try continue instead. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 20:46:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C278A106564A for ; Mon, 23 Jan 2012 20:46:41 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 304378FC08 for ; Mon, 23 Jan 2012 20:46:41 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23mpM9pG4rgh X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-5f7641af.pool.mediaWays.net [95.118.65.175]) by post.strato.de (mrclete mo5) (RZmta 27.5 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id Y01c6do0NKZSSi for ; Mon, 23 Jan 2012 21:46:15 +0100 (MET) Message-ID: <4F1DC716.6050202@brockmann-consult.de> Date: Mon, 23 Jan 2012 21:46:14 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F1A1564.4080003@ambtec.de> In-Reply-To: <4F1A1564.4080003@ambtec.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: zfs arc eating up all memory X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:46:41 -0000 Am 21.01.2012 02:31, schrieb Claudius Herder: > Hi all, > > I kind of accidently did 'du -sh' on my homedir and forgot that I had > set snapdir=visible. > After some minutes wired memory grew from 2g to 7.5g, active memory > dropped from 700m to 20m and heavy swapping occured. > > I was not able to reproduce this behavior in my test vm (i386 vbox) and > testing on the server is difficult because I have only ssh access, and > if I do not kill 'du' in time, I can only hard reset the system. > > If I set snapdir=hidden there is no problem, even if i run 'du -sh /' > > Reducing vfs.zfs.arc_max to 2048m did not solve the issue. > > Any ideas/hints to solve or workaround this problem? Dunno, but I make it a policy to always hide it. You can still type in the .zfs directory and it uses it even if hidden. Try it. zfs set snapdir=hidden mypool/home/claudius cd ~claudius/.zfs/snapshot ls The reason I decided to do that, is because I found that when an NFS client does an ls inside the .zfs/snapshot directory, it hangs the server ;) But the client can still do the same, just manually typing the directory... so I also mounted /var/empty on top of it to hide it on the client. (and my users use the client system through samba, not the zfs system with NFS) > > -- > Claudius > From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 22:05:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 100201065674 for ; Mon, 23 Jan 2012 22:05:07 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 619298FC15 for ; Mon, 23 Jan 2012 22:05:06 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id BCADC4CE5 for ; Mon, 23 Jan 2012 21:47:22 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id 99D854CE4; Mon, 23 Jan 2012 21:47:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 Received: from dijkstra (p5B37AC29.dip.t-dialin.net [91.55.172.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id C5A104CE2 for ; Mon, 23 Jan 2012 21:47:19 +0000 (UTC) Date: Mon, 23 Jan 2012 22:47:17 +0100 From: "Christopher J. Ruwe" To: freebsd-fs@freebsd.org Message-ID: <20120123224717.55de7481@dijkstra> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:05:07 -0000 On Mon, 23 Jan 2012 14:42:19 +0100 Andreas Nilsson wrote: > On Mon, Jan 23, 2012 at 1:58 PM, Johannes Totz > wrote: > > > On 22/01/2012 20:15, Andreas Nilsson wrote: > > > >> On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz > >> wrote: > >> > >> On 19/01/2012 16:26, Andreas Nilsson wrote: > >>> > >>> Hello, > >>>> > >>>> I'm trying to wrap my head around the process of booting from a > >>>> zfs snapshot. I have hit a few roadblocks, which I hope this is > >>>> the adequate list to post to regarding those. > >>>> > >>>> A short note on what I'm trying to achieve might be in order. In > >>>> short: a > >>>> nanobsd system on zfs only. I want to boot from a snapshot so > >>>> that when I > >>>> push out an upgrade with zfs send, I want the root filesystem to > >>>> remain unchanged. > >>>> > >>>> The problems I've hit so far: > >>>> *1 Making the zpool.cache file available > >>>> *2 Having / mount via entry in fstab. > >>>> > >>>> > >>> FWIW, I dont use any fstab for my zfs-only machine. Works > >>> perfectly fine with mountpoint property. > >>> > >> > >> > >> It was just a small hope that the boot would continue with the > >> filesystem pointed out by the bootfs property. I'm setting > >> vfs.root.mountfrom in loader.conf now. > >> > >> > >> > >>> > >>> *1: The zpool.cache is needed to autoimport a pool as I > >>> understand it. Is > >>> > >>>> there a way to force the kernel to import a pool during bootup > >>>> even though > >>>> no zpool.cache is around? What does this file actually contain? > >>>> > >>>> I made an experiment and booted a disk with zfs root from > >>>> machine a in machine b and that worked. I did partition the disk > >>>> with gpart using a gpt > >>>> scheme, and labeled the partition on which the pool resides as > >>>> os, and upon > >>>> creation of the zpool used gpt/os as device. Does this mean that > >>>> as long as > >>>> gpt/os is available, any machine boot this disk will have the > >>>> zpool autoimported? > >>>> > >>>> > >>> Not quite sure I understand you here. Just a note: booting kernel > >>> and mounting root fs are two different things. the *zfsloader > >>> will happily load > >>> the kernel off a pool and boot it but mounting root might fail > >>> later (I guess if no cachefile is present?). > >>> > >>> Sorry for being unclear. What I experience is exactly what you're > >> describing: gptzfsloader loads the kernel and runs it just fine, > >> but mounting root fails due to missing zpool.cache. > >> > >> I'm looking for a way to have the pool imported without the > >> zpool.cache > >> > >> > >> > >>> > >>> *2: Having a line like > >>>> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 > >>>> in fstab causes mount to throw an error and leave me in single > >>>> user mode, > >>>> when the system is booted however mount can mount a zfs snapshot > >>>> just fine. > >>>> Setting vfs.root.mountfrom in loader.conf works just fine though. > >>>> > >>>> > >>> The above I still think is rather strange: setting > >>> vfs.root.mountfrom > >> to a > >> snapshot ( given that the snapshot has the zpool.cache file) > >> works, but not > >> having the corresponding line in fstab. > >> > >> > >>> > >>> -- > >>> Sent from my > >>> > >>> > >> What I'm seeking a solution to is this: Boot several machines from > >> one zfs snapshot. Since the stream from zfs send is also used to > >> do the initial install there is no easy way to get the correct > >> zpool.cache file in the snapshot. I guess one possible way to > >> tackle this problem is to modify zpool so that all pools get > >> created with the same id. > >> > > > > There's a way to pre-load a zpool.cache via the loader (from an > > alternative location). Can't remember the correct variables to set > > right now... > > > > As for w/o any cache file... no idea. > > > > Ok, I'll research that. If it could be loaded from another > > disk/partition > I could really use it :) > > It is of course possible to edit the cachefile property of the > zpool, but I think one can only set it to something relative the > dataset from which one boots. > > Regards > Andreas > _______________________________________________ > 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" Just a curious question: Will what you are trying to implement be similar to Solaris boot environments/beadm? In short, Solaris boot environments are similar to what you described (booting of snapshots) and are used to facilitate maintainance, cf. http://www.c0t0d0s0.org/archives/4372-New-features-of-Solaris-Alternate-boot-environments-based-on-snapshots.html. If so, maybe you can salvage code from there (or Illumos)? Cheers, -- Christopher J. Ruwe TZ GMT + 1 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 22:37:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A8987106564A for ; Mon, 23 Jan 2012 22:37:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A834914DF79; Mon, 23 Jan 2012 22:37:13 +0000 (UTC) Message-ID: <4F1DE118.80201@FreeBSD.org> Date: Mon, 23 Jan 2012 14:37:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Rick Macklem References: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:37:14 -0000 On 01/22/2012 16:53, Rick Macklem wrote: > However, my question is... > - Should the "mount -u" fail and return an error > OR > Silently ignore the "udp" option and return ok. > > I ask because the NFS clients currently silently > clear flags like NFSMNT_NFSV3 and NFSMNT_NOLOCKD > because they can't be changed and then nfs_mount() > returns 0, assuming any other options work. My preference would be that no command silently do something other than what was asked for. Otherwise the operator may be relying on certain behavior that was requested, but not fulfilled. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 22:39:12 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BD8C106564A for ; Mon, 23 Jan 2012 22:39:12 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AC84D8FC13 for ; Mon, 23 Jan 2012 22:39:11 +0000 (UTC) Received: by bkbc12 with SMTP id c12so3803321bkb.13 for ; Mon, 23 Jan 2012 14:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SOZ/Ocxge01/cqnFa+AJoA9FrnI2KvyJ4WUoiJITkQE=; b=f+0yEg4cdmkeHH8m4o/n14LPKxGgKa8jgc4wDY//FUhDzm9yFYDItJXQUZVsLIGrLb bkLyszFUk1mhbVSfrAQ75gvsL98XpluEAv6ud/ugD2ekOMP4EFxNJ2n7Qm//BSY3XF6C P30PaEwTEO5Bm1ECJcnNfgoQW44qegIjnXW5Q= MIME-Version: 1.0 Received: by 10.204.129.208 with SMTP id p16mr3993973bks.131.1327358350475; Mon, 23 Jan 2012 14:39:10 -0800 (PST) Received: by 10.204.40.74 with HTTP; Mon, 23 Jan 2012 14:39:10 -0800 (PST) In-Reply-To: <20120123224717.55de7481@dijkstra> References: <20120123224717.55de7481@dijkstra> Date: Mon, 23 Jan 2012 23:39:10 +0100 Message-ID: From: Andreas Nilsson To: "Christopher J. Ruwe" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: Booting from zfs snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:39:12 -0000 On Mon, Jan 23, 2012 at 10:47 PM, Christopher J. Ruwe wrote: > On Mon, 23 Jan 2012 14:42:19 +0100 > Andreas Nilsson wrote: > > > On Mon, Jan 23, 2012 at 1:58 PM, Johannes Totz > > wrote: > > > > > On 22/01/2012 20:15, Andreas Nilsson wrote: > > > > > >> On Sun, Jan 22, 2012 at 1:25 PM, Johannes Totz > > >> wrote: > > >> > > >> On 19/01/2012 16:26, Andreas Nilsson wrote: > > >>> > > >>> Hello, > > >>>> > > >>>> I'm trying to wrap my head around the process of booting from a > > >>>> zfs snapshot. I have hit a few roadblocks, which I hope this is > > >>>> the adequate list to post to regarding those. > > >>>> > > >>>> A short note on what I'm trying to achieve might be in order. In > > >>>> short: a > > >>>> nanobsd system on zfs only. I want to boot from a snapshot so > > >>>> that when I > > >>>> push out an upgrade with zfs send, I want the root filesystem to > > >>>> remain unchanged. > > >>>> > > >>>> The problems I've hit so far: > > >>>> *1 Making the zpool.cache file available > > >>>> *2 Having / mount via entry in fstab. > > >>>> > > >>>> > > >>> FWIW, I dont use any fstab for my zfs-only machine. Works > > >>> perfectly fine with mountpoint property. > > >>> > > >> > > >> > > >> It was just a small hope that the boot would continue with the > > >> filesystem pointed out by the bootfs property. I'm setting > > >> vfs.root.mountfrom in loader.conf now. > > >> > > >> > > >> > > >>> > > >>> *1: The zpool.cache is needed to autoimport a pool as I > > >>> understand it. Is > > >>> > > >>>> there a way to force the kernel to import a pool during bootup > > >>>> even though > > >>>> no zpool.cache is around? What does this file actually contain? > > >>>> > > >>>> I made an experiment and booted a disk with zfs root from > > >>>> machine a in machine b and that worked. I did partition the disk > > >>>> with gpart using a gpt > > >>>> scheme, and labeled the partition on which the pool resides as > > >>>> os, and upon > > >>>> creation of the zpool used gpt/os as device. Does this mean that > > >>>> as long as > > >>>> gpt/os is available, any machine boot this disk will have the > > >>>> zpool autoimported? > > >>>> > > >>>> > > >>> Not quite sure I understand you here. Just a note: booting kernel > > >>> and mounting root fs are two different things. the *zfsloader > > >>> will happily load > > >>> the kernel off a pool and boot it but mounting root might fail > > >>> later (I guess if no cachefile is present?). > > >>> > > >>> Sorry for being unclear. What I experience is exactly what you're > > >> describing: gptzfsloader loads the kernel and runs it just fine, > > >> but mounting root fails due to missing zpool.cache. > > >> > > >> I'm looking for a way to have the pool imported without the > > >> zpool.cache > > >> > > >> > > >> > > >>> > > >>> *2: Having a line like > > >>>> tank/root/8.2-RELEASE-p5@ro / zfs ro 0 0 > > >>>> in fstab causes mount to throw an error and leave me in single > > >>>> user mode, > > >>>> when the system is booted however mount can mount a zfs snapshot > > >>>> just fine. > > >>>> Setting vfs.root.mountfrom in loader.conf works just fine though. > > >>>> > > >>>> > > >>> The above I still think is rather strange: setting > > >>> vfs.root.mountfrom > > >> to a > > >> snapshot ( given that the snapshot has the zpool.cache file) > > >> works, but not > > >> having the corresponding line in fstab. > > >> > > >> > > >>> > > >>> -- > > >>> Sent from my > > >>> > > >>> > > >> What I'm seeking a solution to is this: Boot several machines from > > >> one zfs snapshot. Since the stream from zfs send is also used to > > >> do the initial install there is no easy way to get the correct > > >> zpool.cache file in the snapshot. I guess one possible way to > > >> tackle this problem is to modify zpool so that all pools get > > >> created with the same id. > > >> > > > > > > There's a way to pre-load a zpool.cache via the loader (from an > > > alternative location). Can't remember the correct variables to set > > > right now... > > > > > > As for w/o any cache file... no idea. > > > > > > Ok, I'll research that. If it could be loaded from another > > > disk/partition > > I could really use it :) > > > > It is of course possible to edit the cachefile property of the > > zpool, but I think one can only set it to something relative the > > dataset from which one boots. > > > > Regards > > Andreas > > _______________________________________________ > > 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" > > > Just a curious question: Will what you are trying to implement be > similar to Solaris boot environments/beadm? > Yes and no. I want my systems read-only, whereas solaris has root rw. And the bootenv is not really a snapshot, but a zfs clone of a snapshot ( ie writable ), which is not what I'm after. > > In short, Solaris boot environments are similar to what you described > (booting of snapshots) and are used to facilitate maintainance, > cf. > http://www.c0t0d0s0.org/archives/4372-New-features-of-Solaris-Alternate-boot-environments-based-on-snapshots.html > . > If so, maybe you can salvage code from there (or Illumos)? > > For general purpose fbsd setup, that is how I try to run the system. I actually did when I had fbsd on my laptop. I did start trying to port/implement it, which I thought would be easy since it is python-based, but I had more pressing issues so "doing it by hand" had to do. > Cheers, > -- > Christopher J. Ruwe > TZ GMT + 1 > > Cheers Andreas From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 22:47:16 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FF91065672 for ; Mon, 23 Jan 2012 22:47:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id F065B8FC14 for ; Mon, 23 Jan 2012 22:47:15 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id RABN1i0041wpRvQ54AnG4t; Mon, 23 Jan 2012 22:47:16 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.westchester.pa.mail.comcast.net with comcast id RAnF1i0091t3BNj3eAnFwF; Mon, 23 Jan 2012 22:47:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C09B4102C19; Mon, 23 Jan 2012 14:47:13 -0800 (PST) Date: Mon, 23 Jan 2012 14:47:13 -0800 From: Jeremy Chadwick To: Doug Barton Message-ID: <20120123224713.GA93292@icarus.home.lan> References: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> <4F1DE118.80201@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F1DE118.80201@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:47:16 -0000 On Mon, Jan 23, 2012 at 02:37:12PM -0800, Doug Barton wrote: > On 01/22/2012 16:53, Rick Macklem wrote: > > However, my question is... > > - Should the "mount -u" fail and return an error > > OR > > Silently ignore the "udp" option and return ok. > > > > I ask because the NFS clients currently silently > > clear flags like NFSMNT_NFSV3 and NFSMNT_NOLOCKD > > because they can't be changed and then nfs_mount() > > returns 0, assuming any other options work. > > My preference would be that no command silently do something other than > what was asked for. Otherwise the operator may be relying on certain > behavior that was requested, but not fulfilled. +1 Doug's recommendation. (I've been trying to write up an explanation of my preference but was too verbose; Doug's fits what I was trying to say perfectly) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Jan 23 22:50:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 14DDE10656B4 for ; Mon, 23 Jan 2012 22:50:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 996AC1A7FF9; Mon, 23 Jan 2012 22:49:37 +0000 (UTC) Message-ID: <4F1DE400.7050503@FreeBSD.org> Date: Mon, 23 Jan 2012 14:49:36 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <700804423.708964.1327280006066.JavaMail.root@erie.cs.uoguelph.ca> <4F1DE118.80201@FreeBSD.org> <20120123224713.GA93292@icarus.home.lan> In-Reply-To: <20120123224713.GA93292@icarus.home.lan> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: should mount -u fail or silently ignore options? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:50:17 -0000 On 01/23/2012 14:47, Jeremy Chadwick wrote: > (I've been trying to write up an explanation > of my preference but was too verbose; Doug's fits what I was trying to > say perfectly) That may be the first time someone has accused me of being the "less verbose" option on a FreeBSD list. :) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Tue Jan 24 08:58:49 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3DCC1065673 for ; Tue, 24 Jan 2012 08:58:49 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 544A08FC1A for ; Tue, 24 Jan 2012 08:58:49 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C495.dip.t-dialin.net [87.150.196.149]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 2E1C68440C3; Tue, 24 Jan 2012 09:58:34 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6B7711750; Tue, 24 Jan 2012 09:58:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1327395511; bh=etePRf0EYfZkfnmQfiSMcDjMWigaJecnU8RVkusZab4=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=Z0gdk0/5vTg3OHB3I3jqxQt6bY1KOL1HxKU333p5aOsk4NgiY9K9KfAVdhmMO7Eso onFghI1gkG2J2ePs6kESVpUz1aNmSCpWbWyM436nsOAb6In7qxJYhOIs2BfIG/mNQu tsVPwiH3ozVrTlphUOOJrDuLAoBGww6cjpLGLQcucZ7792tl3Gt74jGm4i/zDSKAKc FgpFNOpbk+GuVMXMlbyWXd2UYrQhgVVbSmL1r4MVT6DU9h7TmA+uuM6UQ9dFf1OOxM 6HzjBzTa3EOSQHWQ8NvGSxG0XCpsw3twhpL8CLcMutYT2XjBgkVmHs3htp8x/ODF5q AqHJ4JHsd4E+Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q0O8wT1x057246; Tue, 24 Jan 2012 09:58:29 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 24 Jan 2012 09:58:29 +0100 Date: Tue, 24 Jan 2012 09:58:29 +0100 Message-ID: <20120124095829.Horde.cxpNZ5jmRSRPHnK1Ecp9wtA@webmail.leidinger.net> From: Alexander Leidinger To: Willem Jan Withagen References: <4F193D90.9020703@digiware.nl> <20120121162906.0000518c@unknown> <4F1B0177.8080909@digiware.nl> <20120121230616.00006267@unknown> <4F1BC493.10304@brockmann-consult.de> <4F1C3597.4040009@digiware.nl> In-Reply-To: <4F1C3597.4040009@digiware.nl> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 2E1C68440C3.A0DB0 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.1, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1328000315.18527@SOqCj1Ip6D68H2qshv4Upw X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: Question about ZFS with log and cache on SSD with GPT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 08:58:49 -0000 Quoting Willem Jan Withagen (from Sun, 22 Jan 2012 17:13:11 +0100): > On 22-1-2012 9:10, Peter Maloney wrote: >> Am 21.01.2012 23:06, schrieb Alexander Leidinger: >>>> Corsair reports: >>>>> Max Random 4k Write (using IOMeter 08): 50k IOPS (4k aligned) >>>>> So I guess that suggests 4k aligned is required. >>> Sounds like it is. >>> >> I'm not an SSD expert, but I read as much as I can, and found that many >> say that the sector size is not the only thing that matters on an SSD, >> but also the *erase boundary*. The size of the erase boundary varies, >> but 2MiB is a common factor (or 1MiB for 99% of them), so you can use >> that for all. >> >> The theory I read about is that when the SSD wants to write something, >> it must erase the whole erase block first. If it needs to erase a whole >> erase boundary space to write 512 bytes, that is just normal. But if you >> are misaligned, it often needs to erase 2 erase boundary spaces. >> >> Here is an example from our FreeBSD forum: >> http://forums.freebsd.org/showthread.php?t=19093 > > Thanx for this thread, there is a lot of usefull info there. > pithy thing is to blow 66Mb, but then again on 40 or 120 Gb SSDs it is > only marginal. (Guess it stems from the time that HDs where 5Mb :) ) > > I'm still not really shure that that is needed it the bios has nothing > to do with these disks, as in our case: SSDs are only used as caches > under ZFS. I think the erase boundary only matters for speed, if the FS in question really deletes blocks in disk, instead of just "not using it anymore". I was told a while ago that ZFS is not doing BIO_DELETE, specially not on cache devices. So I do not expect that you will see an improvement by taking the erease boundary into account (except your SSD has not a decent wear-leveling implementation). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Tue Jan 24 10:18:51 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FDB7106566C for ; Tue, 24 Jan 2012 10:18:51 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 71D798FC12 for ; Tue, 24 Jan 2012 10:18:49 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q0OAIZop006799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 12:18:42 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Daniel Kalchev In-Reply-To: <4F1C3597.4040009@digiware.nl> Date: Tue, 24 Jan 2012 12:18:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F193D90.9020703@digiware.nl> <20120121162906.0000518c@unknown> <4F1B0177.8080909@digiware.nl> <20120121230616.00006267@unknown> <4F1BC493.10304@brockmann-consult.de> <4F1C3597.4040009@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-fs@freebsd.org Subject: Re: Question about ZFS with log and cache on SSD with GPT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 10:18:51 -0000 On Jan 22, 2012, at 6:13 PM, Willem Jan Withagen wrote: > On 22-1-2012 9:10, Peter Maloney wrote: >>=20 >=20 >> In my testing, it made no difference. But as daniel mentioned: >>=20 >>> With ZFS, the 'alignment' is on per-vdev -- therefore you will need = to recreate the mirror vdevs again using gnop to make them 4k aligned.=20= >> But I just resilvered to add my aligned disks and remove the old. If >> that applies to erase boundaries, then it might have hurt my test. >=20 > I'm not treally fluent in ZFS lingo, but the vdev is what makes up my > zfsdata pool? And the alignment in there carries over to the caches > underneath? >=20 > So what is the consequence if ashift =3D 9, and the partitions are = nicely > aligned even on the rease-boundary=85. ZFS zpool can have a number of "vdevs". These are pieces of storage, = that ZFS uses to store your bits of data. ZFS will spread writing to all = available vdevs at the time of writing. Each vdev may have different = properties, the 'sector size' (the smallest unit for writing/reading the = vdev) being one. In ZFS this is stored in the 'shift' property. It's a = bit shift value really, so ashift=3D9 means 2^9 (512) bytes and = ashift=3D12 means 2^12 (4096) bytes. When you create a vdev in ZFS, by either "zpool create" or "zpool add" = ZFS will check the sector sizes reported by each "drive" (which may be = file, disk drive, SAN storage, any block device in fact) and use the = largest one as the vdev's shift. This is done in order to not penalize = large-sector participants in a vdev. If you add/replace device within an existing vdev, the shift property = does not change. I am not aware of any way to change ashift on the fly, = short of recreating the vdev. Since in current ZFS you cannot remove a = vdev, that means you will have to recreate the zpool. Today, it is probably good idea to create all new zpools with at least = an ashift value of 12 (4096 bytes), or perhaps even larger. Current = drives are so huge, that wasted space will not be significant. But = performance will be better. This should be even more important for SSD drives used as ZFS storage = (perhaps also for SLOG/ZIL and cache) because that will both make the = drive live longer and improve significantly write performance. I have not experimented with gnop-ing ZIL or cache, then removing the = gnop and re-importing pool, but there is no reason why it should not = work. Daniel From owner-freebsd-fs@FreeBSD.ORG Tue Jan 24 14:59:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CFC106566B for ; Tue, 24 Jan 2012 14:59:10 +0000 (UTC) (envelope-from claudius@ambtec.de) Received: from server.ambtec.de (server.ambtec.de [IPv6:2a01:4f8:131:1381::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDD18FC18 for ; Tue, 24 Jan 2012 14:59:09 +0000 (UTC) Received: from server.ambtec.de (localhost [127.0.0.1]) by server.ambtec.de (Postfix) with ESMTP id 0BC92E313 for ; Tue, 24 Jan 2012 15:59:08 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at ambtec.de Received: from server.ambtec.de ([127.0.0.1]) by server.ambtec.de (server.ambtec.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5bSc2RbqJIbZ for ; Tue, 24 Jan 2012 15:58:51 +0100 (CET) Received: from [192.168.0.101] (e176013248.adsl.alicedsl.de [85.176.13.248]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.ambtec.de (Postfix) with ESMTPSA id 2F467E309 for ; Tue, 24 Jan 2012 15:58:51 +0100 (CET) Message-ID: <4F1EC72B.7000405@ambtec.de> Date: Tue, 24 Jan 2012 15:58:51 +0100 From: Claudius Herder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120114 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F1A1564.4080003@ambtec.de> <4F1DC716.6050202@brockmann-consult.de> In-Reply-To: <4F1DC716.6050202@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: zfs arc eating up all memory X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:59:10 -0000 On 23/01/12 21:46, Peter Maloney wrote: > Dunno, but I make it a policy to always hide it. You can still type in > the .zfs directory and it uses it even if hidden. > > Try it. > > zfs set snapdir=hidden mypool/home/claudius > cd ~claudius/.zfs/snapshot > ls > yes I know and I think it is a really nice feature for users to be able to restore files by themselves. > The reason I decided to do that, is because I found that when an NFS > client does an ls inside the .zfs/snapshot directory, it hangs the server ;) at my server `ls .zfs/snapshot/` works, but `ls -R .zfs/snapshot/` kills the server. Same for `find .zfs/snapshot -name foo`. > But the client can still do the same, just manually typing the > directory... so I also mounted /var/empty on top of it to hide it on the > client. (and my users use the client system through samba, not the zfs > system with NFS) I'm not very fond of this idea, but for the moment it will prevent server crashes, which is fine. Thanks for the hint. I did some further testing: My i368 vm is able to search 100 snapshots with 8601040 files without problems with 1gb ram und 1 gb swap. My amd64 server is not able to search 4280597 files with 8gb ram and 4gb swap. At the last halt arc consumed only 5,5gb memory and as I understand arc would not steal memory from other processes, is this assumption correct? Maybe this problem is totally unrelated to arc and there is something else claiming all memory? How can I investigate this issue further? -- Claudius From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 06:53:06 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00BFF1065670; Wed, 25 Jan 2012 06:53:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C690E8FC08; Wed, 25 Jan 2012 06:53:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0P6r5II091017; Wed, 25 Jan 2012 06:53:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0P6r5BF091013; Wed, 25 Jan 2012 06:53:05 GMT (envelope-from linimon) Date: Wed, 25 Jan 2012 06:53:05 GMT Message-Id: <201201250653.q0P6r5BF091013@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164462: [nfs] NFSv4 mounting fails to mount; asks for stronger authentication X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:53:06 -0000 Old Synopsis: NFSv4 mounting fails to mount; asks for stronger authentication New Synopsis: [nfs] NFSv4 mounting fails to mount; asks for stronger authentication Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 25 06:52:27 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=164462 From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 07:51:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F881065673 for ; Wed, 25 Jan 2012 07:51:08 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88C818FC12 for ; Wed, 25 Jan 2012 07:51:07 +0000 (UTC) Received: by eekb47 with SMTP id b47so2041584eek.13 for ; Tue, 24 Jan 2012 23:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=IdtJ2z2hJxLavgaaEEEoR7SAMaUtCMpjIzLpJGTzDT4=; b=cRzkXKoCgXu8KdFA4xatv84HLwG/0Y3YNTtu/btTCfEQc81XE4QNXBFe2y948y+zM3 Lk7+9iSNTQ2ROah82tvRqXgowuQ1xIxqQEmMz5fs6CcqZpXJIO3l0ZzewcdP9L+yVri7 SDaiFAlhrY+xmhj6s8z7bOzb/Y1jjkIAf2BSM= Received: by 10.14.16.100 with SMTP id g76mr3456960eeg.102.1327477866106; Tue, 24 Jan 2012 23:51:06 -0800 (PST) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id x4sm78235078eeb.4.2012.01.24.23.51.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 23:51:05 -0800 (PST) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 09:51:04 +0200 To: freebsd-fs@FreeBSD.ORG Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: Subject: BIO_DELETE support for ZVOLs? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 07:51:08 -0000 I'm don't know if anyone thought about this but it seems like a nice feature to support TRIM like functionality for ZVOLs. For example : if there is a sparse ZFS volume, formatted with UFS, and you fill it up once, then the disk space used will be with the size = of the ZVOL. Then even if there is freed space on the UFS filesystem, the ZVOL disk space allocated from the ZVOL will remain the same. This also will be very nice if can be supported for FC exported ZVOLs = via the new CAM Target Layer. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 09:11:48 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E997106564A for ; Wed, 25 Jan 2012 09:11:48 +0000 (UTC) (envelope-from miconof80.list@gmail.com) Received: from mailhost.math.cnrs.fr (margauxlyon.mathrice.fr [194.167.215.28]) by mx1.freebsd.org (Postfix) with ESMTP id 081AB8FC12 for ; Wed, 25 Jan 2012 09:11:47 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.math.cnrs.fr (Postfix) with ESMTP id 83BA14408D; Wed, 25 Jan 2012 09:41:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.cnrs.fr Received: from mailhost.math.cnrs.fr ([127.0.0.1]) by localhost (margaux.math.cnrs.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeEq1iKDigET; Wed, 25 Jan 2012 09:40:58 +0100 (CET) Received: from e4310 (e4310.lsv.ens-cachan.fr [138.231.81.249]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.math.cnrs.fr (Postfix) with ESMTP id F15714408B; Wed, 25 Jan 2012 09:40:57 +0100 (CET) Date: Wed, 25 Jan 2012 09:40:50 +0100 From: Michel Le Cocq To: Garrett Cooper Message-ID: <20120125084040.GA2831@e4310> References: <201110091940.p99JeJIc095036@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: <201110091940.p99JeJIc095036@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 09:11:48 -0000 --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. Intel(R) Atom(TM) CPU D510 @ 1.66GHz real memory =3D 4294967296 (4096 MB) avail memory =3D 3127390208 (2982 MB) I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for data.=20 # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT data 931G 254G 677G 27% 1.00x ONLINE - stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - tank 696G 574G 122G 82% 1.00x ONLINE - zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - Before upgrade, I must use some mana things in my /boot/loader.conf vm.kmem_size=3D"330M" vm.kmem_size_max=3D"330M" vfs.zfs.arc_max=3D"40M" vfs.zfs.vdev.cache.size=3D"5M" =09 With this config my server was not so stable. Some days it work perfectly, some others it freeze with kmem_malloc kmem_map too small.=20 Without this mana it freeze really often. The thing which make me upgrade is that after one of this crash after reboot it won't mount my data pool which was at 99% of his CAP. The only way I find to boot is to disconnect the pools drive and export it. Now I'm on exactly the same host after upgrade to 9.0 and it seems to work really really better (3 days up with out any trouble). -- M Garrett Cooper a =E9crit: > The following reply was made to PR kern/146528; it has been noted by GNAT= S. >=20 > From: Garrett Cooper > To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com > Cc: =20 > Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 > Date: Sun, 9 Oct 2011 12:34:00 -0700 >=20 > Could you please try upgrading to 8.2-STABLE or 9.0 and see if the > issue persists with ZFS v28? > -Garrett > _______________________________________________ > 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" --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPH8ASAAoJENZipdjc3yzpXpsP/0iE9c4OyaBvJTM9fPQLuvVm JFWNfXUkhqHtTDcBpLCr0bK3PjTvleX/GsiQagRwyT7EMPD/UUcaLggydJHlEFXZ 3IFOn6VNoznupghzl5gmXYDAZJJsZSbwgKB5CX7ApJGBP7J3BfXT//9qFCUR2Yir Te+6vpR4EFekCG0WbjP77C5BX3nU/+nVqpskmU4JV8r+eQMMZsyERV9At/mUKMr7 5iAfw6B7pjOIg4RJRRAT/Zo/Xm0pTlCE7c9mzjF+ZPhPfu8IBB4oHAeB2Qo6U2tb 4l1d0bGwXsXFHP+acNJrEc5F29MtMsS93PRj0mWKWS8JxUZewPPOJlEGdVfAtSvE czuK5AN3DhC1weYo87d6MEzEKeFm0pU50k3EZYoBnxwezBrEZwjTbCEhdQtzx4mR ftogEdqFVYskgoBQODCSejsmt6HeQGaHOcE3zQbO4zulFU5No1cDdiwTispLDXj3 /k84CsYy/hDaRj7dUARHO6VARcBEwzIZVwn1mxjZBTrpLmYEpanjI/8YvT6t4y17 FZKw8clHWxeyT353XA5QKzalV9xpTmul7iwUZGlRDoT84FW+kF+C71IW9TtnO223 JIIWJcCWnIVXKTRrVhJJITJeS+ICxUM+3du+nijnATOONvDqaiJI7g/sxEtGnfnz V74W/b4H5en+3D9btvx5 =VZJl -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 09:58:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54DAA106566C for ; Wed, 25 Jan 2012 09:58:45 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id BF9EA8FC08 for ; Wed, 25 Jan 2012 09:58:44 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MMYXO-1Rhjkz2FjC-007kNw; Wed, 25 Jan 2012 10:58:43 +0100 Message-ID: <4F1FD252.4090403@brockmann-consult.de> Date: Wed, 25 Jan 2012 10:58:42 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> In-Reply-To: <20120125084040.GA2831@e4310> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:bAw3P/kkA0+3uOhP+aGH4hdRd7TbbuVKBMT1oRel9c6 Skg1Lk+yrdYJ1/jpoqCPiyyPqmGI26dHfEoH4q6U52BQwVuYIB qtI6h/SQ4f0n+0iRbO84bGeIj2Z/FbQ+b8GIkrzVDQO0wGBYZY 6k01i5ga1Xh0aEErjCf+cRL3ceVmZtJIJLCeKyksI/zDIn23JE IAeFI9+6bC3tPh2Bfet1aH7yS4JU8p20YDN4sk3HypwzLWjWrb QRe7ltXpJcM1YfaH6oMFjJrwZfUNdt7ORiCZYojCXmDSWk2jbr TX0TgpQhyrpEg6WgW+3/UUvih3KrmwCHEbmw/UEbE6Fp/uwgZz WWlaV6WuPaoDVpHauZdk+Ch6XOq9aqRa3hpX/YqCT Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 09:58:45 -0000 When was your 8.2-STABLE built / csup'd? Peter On 01/25/2012 09:40 AM, Michel Le Cocq wrote: > Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. > Intel(R) Atom(TM) CPU D510 @ 1.66GHz > real memory = 4294967296 (4096 MB) > avail memory = 3127390208 (2982 MB) > > I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for > data. > > # zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > data 931G 254G 677G 27% 1.00x ONLINE - > stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - > tank 696G 574G 122G 82% 1.00x ONLINE - > zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - > > Before upgrade, I must use some mana things in my /boot/loader.conf > > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="40M" > vfs.zfs.vdev.cache.size="5M" > > With this config my server was not so stable. > > Some days it work perfectly, some others it freeze with kmem_malloc > kmem_map too small. > Without this mana it freeze really often. > > The thing which make me upgrade is that after one of this crash after > reboot it won't mount my data pool which was at 99% of his CAP. The > only way I find to boot is to disconnect the pools drive and export > it. > > Now I'm on exactly the same host after upgrade to 9.0 and it seems to > work really really better (3 days up with out any trouble). > > -- > M > > Garrett Cooper a écrit: >> The following reply was made to PR kern/146528; it has been noted by GNATS. >> >> From: Garrett Cooper >> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >> Cc: >> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >> Date: Sun, 9 Oct 2011 12:34:00 -0700 >> >> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >> issue persists with ZFS v28? >> -Garrett >> _______________________________________________ >> 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:00:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57501065670 for ; Wed, 25 Jan 2012 11:00:19 +0000 (UTC) (envelope-from miconof80.list@gmail.com) Received: from mailhost.math.cnrs.fr (margauxlyon.mathrice.fr [194.167.215.28]) by mx1.freebsd.org (Postfix) with ESMTP id 23D998FC0A for ; Wed, 25 Jan 2012 11:00:18 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.math.cnrs.fr (Postfix) with ESMTP id BF2784408D; Wed, 25 Jan 2012 12:00:16 +0100 (CET) X-Virus-Scanned: amavisd-new at math.cnrs.fr Received: from mailhost.math.cnrs.fr ([127.0.0.1]) by localhost (margaux.math.cnrs.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxXkZ1yf3wMm; Wed, 25 Jan 2012 12:00:11 +0100 (CET) Received: from e4310 (e4310.lsv.ens-cachan.fr [138.231.81.249]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.math.cnrs.fr (Postfix) with ESMTP id 1E9164408C; Wed, 25 Jan 2012 12:00:11 +0100 (CET) Date: Wed, 25 Jan 2012 12:00:05 +0100 From: Michel Le Cocq To: Peter Maloney Message-ID: <20120125110005.GA7000@e4310> References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <4F1FD252.4090403@brockmann-consult.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:00:19 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I recently update 1 week maybe ! Peter Maloney a =E9crit: > When was your 8.2-STABLE built / csup'd? >=20 > Peter >=20 >=20 > On 01/25/2012 09:40 AM, Michel Le Cocq wrote: > > Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. > > Intel(R) Atom(TM) CPU D510 @ 1.66GHz > > real memory =3D 4294967296 (4096 MB) > > avail memory =3D 3127390208 (2982 MB) > > > > I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for > > data.=20 > > > > # zpool list > > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > > data 931G 254G 677G 27% 1.00x ONLINE - > > stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - > > tank 696G 574G 122G 82% 1.00x ONLINE - > > zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - > > > > Before upgrade, I must use some mana things in my /boot/loader.conf > > > > vm.kmem_size=3D"330M" > > vm.kmem_size_max=3D"330M" > > vfs.zfs.arc_max=3D"40M" > > vfs.zfs.vdev.cache.size=3D"5M" > > =09 > > With this config my server was not so stable. > > > > Some days it work perfectly, some others it freeze with kmem_malloc > > kmem_map too small.=20 > > Without this mana it freeze really often. > > > > The thing which make me upgrade is that after one of this crash after > > reboot it won't mount my data pool which was at 99% of his CAP. The > > only way I find to boot is to disconnect the pools drive and export > > it. > > > > Now I'm on exactly the same host after upgrade to 9.0 and it seems to > > work really really better (3 days up with out any trouble). > > > > -- > > M > > > > Garrett Cooper a =E9crit: > >> The following reply was made to PR kern/146528; it has been noted by G= NATS. > >> > >> From: Garrett Cooper > >> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com > >> Cc: =20 > >> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 > >> Date: Sun, 9 Oct 2011 12:34:00 -0700 > >> > >> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the > >> issue persists with ZFS v28? > >> -Garrett > >> _______________________________________________ > >> 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" --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPH+C1AAoJENZipdjc3yzph0wP/0FUE3Fx4V6ul4eTtv57ZRBK 1YEGttiFnCIsDUEpvVXF152feWcwdP2h7CXbYW8/bGuQ8P615jRYozSK04s1232L 1aq/XHhoe0v29Prr8kEFOAMxM3VgGdsdj0nJa6aNN0qBbbdHrKEXJLqpBzeqE/FF M9KaNgttyCHsasETEkWZImSGat5H5vQrSFWLd7e7qCMPaPVtNOVPPz071vBXGk9i f8O2LF55rRL/CVOamjm6XjrzovRRkqnUURyY7j4JVEBglVHNlZOsmsOJuB0x9LF2 /OmuBmRgTVlRiqnfi6z7V0Iw+1Se/FavbWzsi7EaMpveSgIqkgD7Znd93jZjVYYN qZpihOpPFV+duqRp7mMoEjoJPSYeb6dTi7evPOeLDYWHNjnN2XHs8i3Arz7pQS/j af56dw1ZoM3x6//hp11dCtNsIKSXoKZHvSoHFvHRDgvpC5LCEbnKsZDN3EVLybSR 5pAgYs8yBV3tHJfleBlqVzyZuztbp5IIo7MuM/MmKbIeaUqihgMkQWQ0FOVEJg0p fLr4v59jpM4oOeqhBt6xfaRwHFeunEbNzvEtobCB9+rO1auP5UFnjCVyu9/p4+99 AJTKe+yaPflnVZyxEMXFKM5jpaDsrNynS9r4ihuoimkv2uNTvMDoJhy16S/sSHmv /julU4p3uCDlklMm5PQ2 =DYKo -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:13:55 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7583F106566B for ; Wed, 25 Jan 2012 11:13:55 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC478FC1A for ; Wed, 25 Jan 2012 11:13:54 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MTact-1SENni3mNj-00SRov; Wed, 25 Jan 2012 12:13:54 +0100 Message-ID: <4F1FE3F1.2010301@brockmann-consult.de> Date: Wed, 25 Jan 2012 12:13:53 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Michel Le Cocq References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <20120125110005.GA7000@e4310> In-Reply-To: <20120125110005.GA7000@e4310> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:TXWZQ6MCCP/v2PC7Whirkt39PkRoSwNvoMC/0ZUmmiE ydsEjBU6hfLV84GVavp8AlB0/Ij1a+/td0rgDx5VsEtVEXvtBx J/eYDBe3wKzbIDAMzRqLoWOkLEn9rr9TO/lzdeI2HVh3odthaL topKkdj8s/5k+YZJKRA2XOIGulACfwEXIXMzD486sLz4eOIj+x b8RWsXtO7hz2xIkbRh+Gl4lcExoHtQ1OE3T7XmrqusoH9FvRcu h6a+0+cjn+R7F4qft1cQOI0HKYPjLToMo7uLEuLOlYZGPioS1F LH394nIv2rbyEuN07t1a1l5RwHPVg9lkxhP4bPWTqHy3aldRjd ktvl2+6/ru58NH93E0/XpK+4XpsOvPOWvm7hz1mb3 Cc: freebsd-fs@freebsd.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:13:55 -0000 I expected you would say it was much older, somewhere between April and September last year. My amd64 systems (dual cpu quad core Xeon) with 48 GB of ram have no issues like this. And my amd64 test VMs with 512M-2GB of RAM don't have this problem either, but of course they aren't tested the same. On 01/25/2012 12:00 PM, Michel Le Cocq wrote: > I recently update 1 week maybe ! > > Peter Maloney a écrit: >> When was your 8.2-STABLE built / csup'd? >> >> Peter >> >> >> On 01/25/2012 09:40 AM, Michel Le Cocq wrote: >>> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. >>> Intel(R) Atom(TM) CPU D510 @ 1.66GHz >>> real memory = 4294967296 (4096 MB) >>> avail memory = 3127390208 (2982 MB) >>> >>> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for >>> data. >>> >>> # zpool list >>> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >>> data 931G 254G 677G 27% 1.00x ONLINE - >>> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - >>> tank 696G 574G 122G 82% 1.00x ONLINE - >>> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - >>> >>> Before upgrade, I must use some mana things in my /boot/loader.conf >>> >>> vm.kmem_size="330M" >>> vm.kmem_size_max="330M" >>> vfs.zfs.arc_max="40M" >>> vfs.zfs.vdev.cache.size="5M" >>> >>> With this config my server was not so stable. >>> >>> Some days it work perfectly, some others it freeze with kmem_malloc >>> kmem_map too small. >>> Without this mana it freeze really often. >>> >>> The thing which make me upgrade is that after one of this crash after >>> reboot it won't mount my data pool which was at 99% of his CAP. The >>> only way I find to boot is to disconnect the pools drive and export >>> it. >>> >>> Now I'm on exactly the same host after upgrade to 9.0 and it seems to >>> work really really better (3 days up with out any trouble). >>> >>> -- >>> M >>> >>> Garrett Cooper a écrit: >>>> The following reply was made to PR kern/146528; it has been noted by GNATS. >>>> >>>> From: Garrett Cooper >>>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >>>> Cc: >>>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >>>> Date: Sun, 9 Oct 2011 12:34:00 -0700 >>>> >>>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >>>> issue persists with ZFS v28? >>>> -Garrett >>>> _______________________________________________ >>>> 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:19:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34504106564A for ; Wed, 25 Jan 2012 11:19:57 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B86A28FC12 for ; Wed, 25 Jan 2012 11:19:56 +0000 (UTC) Received: by bkbc12 with SMTP id c12so5727217bkb.13 for ; Wed, 25 Jan 2012 03:19:55 -0800 (PST) Received: by 10.205.141.76 with SMTP id jd12mr6852922bkc.42.1327488507181; Wed, 25 Jan 2012 02:48:27 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id sp6sm19439bkb.2.2012.01.25.02.48.25 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 02:48:26 -0800 (PST) Message-ID: <4F1FDDF8.6020300@my.gd> Date: Wed, 25 Jan 2012 11:48:24 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> In-Reply-To: <4F1FD252.4090403@brockmann-consult.de> X-Gm-Message-State: ALoCoQkUlToANPxwpjp/LVfoEl/+VSENPYpGTTKmApHuJtVRbhDX5F7pLhYgdw8q4P/9oycbH5IO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:19:58 -0000 Hijacking thread quickly. How do you guys usually check your build/csup date on -stable and such ? I guess I'd go with the latest kernel build date, but there may be better ways. On 1/25/12 10:58 AM, Peter Maloney wrote: > When was your 8.2-STABLE built / csup'd? > > Peter > > > On 01/25/2012 09:40 AM, Michel Le Cocq wrote: >> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. >> Intel(R) Atom(TM) CPU D510 @ 1.66GHz >> real memory = 4294967296 (4096 MB) >> avail memory = 3127390208 (2982 MB) >> >> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for >> data. >> >> # zpool list >> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >> data 931G 254G 677G 27% 1.00x ONLINE - >> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - >> tank 696G 574G 122G 82% 1.00x ONLINE - >> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - >> >> Before upgrade, I must use some mana things in my /boot/loader.conf >> >> vm.kmem_size="330M" >> vm.kmem_size_max="330M" >> vfs.zfs.arc_max="40M" >> vfs.zfs.vdev.cache.size="5M" >> >> With this config my server was not so stable. >> >> Some days it work perfectly, some others it freeze with kmem_malloc >> kmem_map too small. >> Without this mana it freeze really often. >> >> The thing which make me upgrade is that after one of this crash after >> reboot it won't mount my data pool which was at 99% of his CAP. The >> only way I find to boot is to disconnect the pools drive and export >> it. >> >> Now I'm on exactly the same host after upgrade to 9.0 and it seems to >> work really really better (3 days up with out any trouble). >> >> -- >> M >> >> Garrett Cooper a écrit: >>> The following reply was made to PR kern/146528; it has been noted by GNATS. >>> >>> From: Garrett Cooper >>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >>> Cc: >>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >>> Date: Sun, 9 Oct 2011 12:34:00 -0700 >>> >>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >>> issue persists with ZFS v28? >>> -Garrett >>> _______________________________________________ >>> 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 Wed Jan 25 11:31:54 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2084B106564A for ; Wed, 25 Jan 2012 11:31:54 +0000 (UTC) (envelope-from miconof80.list@gmail.com) Received: from mailhost.math.cnrs.fr (margauxlyon.mathrice.fr [194.167.215.28]) by mx1.freebsd.org (Postfix) with ESMTP id 917E58FC19 for ; Wed, 25 Jan 2012 11:31:53 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.math.cnrs.fr (Postfix) with ESMTP id 3EE0844094; Wed, 25 Jan 2012 12:31:52 +0100 (CET) X-Virus-Scanned: amavisd-new at math.cnrs.fr Received: from mailhost.math.cnrs.fr ([127.0.0.1]) by localhost (margaux.math.cnrs.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMuZJS2DOnOV; Wed, 25 Jan 2012 12:31:50 +0100 (CET) Received: from e4310 (e4310.lsv.ens-cachan.fr [138.231.81.249]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailhost.math.cnrs.fr (Postfix) with ESMTP id E34EB4408C; Wed, 25 Jan 2012 12:31:50 +0100 (CET) Date: Wed, 25 Jan 2012 12:31:49 +0100 From: Michel Le Cocq To: Peter Maloney Message-ID: <20120125113149.GB7000@e4310> References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <20120125110005.GA7000@e4310> <4F1FE3F1.2010301@brockmann-consult.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <4F1FE3F1.2010301@brockmann-consult.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:31:54 -0000 --kORqDWCi7qDJ0mEj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ok in fact I didn't understand your first question ! I see this trouble only on my personnal i386 machine. I have also several amd64 with a lot of mem 24G or some virtual with 4G all on amd64 and they work perfectly on 8.2 since more than 1 year. -- M Peter Maloney a =E9crit: > I expected you would say it was much older, somewhere between April and > September last year. My amd64 systems (dual cpu quad core Xeon) with 48 > GB of ram have no issues like this. And my amd64 test VMs with 512M-2GB > of RAM don't have this problem either, but of course they aren't tested > the same. >=20 >=20 >=20 > On 01/25/2012 12:00 PM, Michel Le Cocq wrote: > > I recently update 1 week maybe ! > > > > Peter Maloney a =E9crit: > >> When was your 8.2-STABLE built / csup'd? > >> > >> Peter > >> > >> > >> On 01/25/2012 09:40 AM, Michel Le Cocq wrote: > >>> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. > >>> Intel(R) Atom(TM) CPU D510 @ 1.66GHz > >>> real memory =3D 4294967296 (4096 MB) > >>> avail memory =3D 3127390208 (2982 MB) > >>> > >>> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for > >>> data.=20 > >>> > >>> # zpool list > >>> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > >>> data 931G 254G 677G 27% 1.00x ONLINE - > >>> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - > >>> tank 696G 574G 122G 82% 1.00x ONLINE - > >>> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - > >>> > >>> Before upgrade, I must use some mana things in my /boot/loader.conf > >>> > >>> vm.kmem_size=3D"330M" > >>> vm.kmem_size_max=3D"330M" > >>> vfs.zfs.arc_max=3D"40M" > >>> vfs.zfs.vdev.cache.size=3D"5M" > >>> =09 > >>> With this config my server was not so stable. > >>> > >>> Some days it work perfectly, some others it freeze with kmem_malloc > >>> kmem_map too small.=20 > >>> Without this mana it freeze really often. > >>> > >>> The thing which make me upgrade is that after one of this crash after > >>> reboot it won't mount my data pool which was at 99% of his CAP. The > >>> only way I find to boot is to disconnect the pools drive and export > >>> it. > >>> > >>> Now I'm on exactly the same host after upgrade to 9.0 and it seems to > >>> work really really better (3 days up with out any trouble). > >>> > >>> -- > >>> M > >>> > >>> Garrett Cooper a =E9crit: > >>>> The following reply was made to PR kern/146528; it has been noted by= GNATS. > >>>> > >>>> From: Garrett Cooper > >>>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com > >>>> Cc: =20 > >>>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 > >>>> Date: Sun, 9 Oct 2011 12:34:00 -0700 > >>>> > >>>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the > >>>> issue persists with ZFS v28? > >>>> -Garrett > >>>> _______________________________________________ > >>>> 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" --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPH+gkAAoJENZipdjc3yzpaPkP/j6vSSmRYCQphAPaNXW4ukBx CmxfodLacYOub61orHEIvuOu08/EUzXDYtG96pIJYI8MCsg6urNowgYjbHxl1A7P cXpg0SCaYvoX0rTbtYPQGKeHxxo9SK1aArYI5HrWP3UKNpuPxC8FsqYKYq+3cSsr DCcY7k2LnbuJVsLDZanqsRPCa71W6LsUgfARIY+L+3GVfxgai5J9PaEWq/EkvJds +/UX0C44wiig3f60eMzb6E/TUPlPnJuPxKEWCJP2q2hu746BKKS/bDV3ThMd2sKG CFgq7WbGuvvwvLXFQDBkjoU8Zbxo6Dm8xQm89jqh0zTx9fy8p6Zha3Mafr4sIfeR 25vdxwmCbPv38c5S/uOdBStocaG54KhbvR4JUONnKs8wZRMEkjjgkIT49Yp76BkA osqhFsl5HY4KIR3sHvH/NxqzFBzvoFWXhHGL4y5QefNLLxiGsTwRxZGqW2mv72wu 4jChE1/KOoTAgREcEr8jdxjSUpxFqkpoowy2Y1TEnwB5No9D4rQVcqgLH9bKQ861 qBKxVBs6QoaIywZw7fGX7neoZdUnyh8huTdFOec2vLbq0yJyUZ8Lv79omqNQT2HU Q3yDPOn6j9UUi3XRcKdtjP0Xt5rO7D/ke8+NCN8XignQNyKQiza8PmOcoQDmnF/2 326BSzFbAVBKhS7sl2B1 =WUht -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:33:51 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A2D91065679; Wed, 25 Jan 2012 11:33:51 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id A795A8FC0C; Wed, 25 Jan 2012 11:33:50 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 3ABAD9DC639; Wed, 25 Jan 2012 12:13:54 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 12:13:53 +0100 Message-Id: <88146602-824A-47DD-B1EC-1F62BCF54389@sarenet.es> To: freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Subject: To JBOD or just to pass, that is the question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:33:51 -0000 =09 Hi Sorry for the cross-posting, but this pertains both filesystems and host = adapters. Since ZFS was added to FreeBSD it has collided with the standard = practice of server manufacturers: including "RAID" cards. ZFS is designed to control the disks directly, and RAID cards tend to = get in the middle, complicating things. Some cards do provide access to = disks, working as plain host adapters without more added features, as = they should be. But so far I have found two problematic cases: mfi and = aac cards.=20 Of course, the standard suggestion is to create a logical volume for = each disk, so that you have the rough equivalent of a hard disk attached = to a host adapter. However, it has its drawbacks: - Added layer of complexity. At least with mfi cards, replacing a broken = disk involves a bit of device dependant voodoo incantations. It should = be a matter of physically replacing the disk and maybe do a camcontrol = rescan, nothing else.=20 - Are such volume-per-disk transportable from one controller to another? = What happens if I need to install them on a different machine with a = different host adapter? ZFS provides that interoperability, but the RAID = cards can be a problem. - More complexity: What's, for instance, the caching behavior of the = RAID card? ZFS decides when to flush, not to flush, etc. Battery backed = RAID cards show (as far as I know) a configuration dependent caching, = maybe ignoring commands received from the OS storage subsystem? At least = there's no detailed documentation as far as I know. So I tend to dislike = that "firmware in the middle". Long ago I asked for help on freebsd-scsi and Scott Long sent a simple = patch to make hard disks shown as pass-through devices available to the = "da" driver, hence becoming real hard disks. It's just a matter of = deleting all the logical volumes before using the disks. I've been = running this on a machine with MFI since 2007 and so far so good. The = machine is now on 8.1 and I hope to update to 9 soon. The freebsd-scsi thread: = http://lists.freebsd.org/pipermail/freebsd-scsi/2007-October/003224.html The behavior with my torture tests was good. One of the things I use to = do when testing a configuration is to remove a disk suddenly with the = system working. That was a pain in the ass with the mfi thingy, really = straightforward with the disks accessed in pass through mode. Now I am installing a Sun X4240 server, and, surprisingly, I've stumbled = upon a similar problem. Now it's an "aac" card: aac0: mem 0xdfe00000-0xdfffffff irq 17 at device 0.0 = on pci4 aac0: Enabling 64-bit address support aac0: Enable Raw I/O aac0: Enable 64-bit array aac0: New comm. interface enabled aac0: Sun STK RAID INT, aac driver 2.1.9-1 aacp0: on aac0 aacp1: on aac0 aacp2: on aac0 This is a disk on /var/run/dmesg.boot, da0: Fixed Direct Access SCSI-5 device=20= da0: 0KB/s transfers da0: 140009MB (286739329 512 byte sectors: 255H 63S/T 17848C) and this is what I see from camcontrol: # camcontrol devlist at scbus6 target 8 lun 0 (da0,pass0) at scbus6 target 9 lun 0 (da1,pass1) at scbus6 target 10 lun 0 (da2,pass2) at scbus6 target 11 lun 0 (da3,pass3) at scbus6 target 12 lun 0 (da4,pass4) at scbus6 target 13 lun 0 (da5,pass5) at scbus6 target 14 lun 0 (da6,pass6) at scbus6 target 15 lun 0 (da7,pass7) at scbus6 target 16 lun 0 (da8,pass8) at scbus6 target 17 lun 0 (da9,pass9) at scbus6 target 18 lun 0 = (da10,pass10) at scbus6 target 19 lun 0 = (da11,pass11) at scbus6 target 20 lun 0 = (da12,pass12) at scbus6 target 21 lun 0 = (da13,pass13) at scbus6 target 22 lun 0 = (da14,pass14) at scbus6 target 23 lun 0 = (da15,pass15) at scbus8 target 0 lun 0 = (ses0,pass16) at scbus8 target 1 lun 0 = (ses1,pass17) at scbus8 target 2 lun 0 = (ses2,pass18) at scbus15 target 0 lun 0 = (cd0,pass19) at scbus16 target 0 lun 0 = (da16,pass20) camcontrol inq 6:8:0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number 000946821D70 3SD21D70 pass0: 3.300MB/s transfers=20 The transfer speed seems to be silly, but Bonnie++ on a 16 disk raidz2 = gave 200+MBps block writing, 700+MBps block reading, so it seems to be = working. So far there's just one side effect of accessing the disks in pass = through mode: I cannot reboot the machine, seems to hang after flushing = the buffers. It happens both with the mfi and the aac drivers. Just wondering, should we have, maybe, a tunable allowing aac and mfi to = bypass the RAID firmware thingy? Is there any kind of exhaustive test we = could perform to make sure that the card isn't doing weird things. I've noticed, in the case of the aac machine I'm testing, that = camcontrol tags shows just one "device opening". I'm wondering if it = would be safe to increase them? Right now the machine isn't in = production, so I can perform some tests. Best regards, Borja. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:44:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456F91065672 for ; Wed, 25 Jan 2012 11:44:05 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id E11BD8FC08 for ; Wed, 25 Jan 2012 11:44:04 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MHrNV-1RmRIs17Wv-003eHr; Wed, 25 Jan 2012 12:44:03 +0100 Message-ID: <4F1FEB02.2080202@brockmann-consult.de> Date: Wed, 25 Jan 2012 12:44:02 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <4F1FDDF8.6020300@my.gd> In-Reply-To: <4F1FDDF8.6020300@my.gd> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:/MYWRueUK41lDlmFlIfQMWmns2oedtYgb1adplQprjb mrsGXZKHDkQVkYgc6p6CevK8a31pApTDktc1ADIy4Lf//iv14b 82raD1Ggdk+qX/5zM4dy+9rWpC72/ds/lGvnlAI1q72zZ+d3/H Rp7ZiocfQUsIBz+Ptvx+xuG2AxzO4iQ6YHJlHN1VpG1lPE6/Qw 2/stspSijbcgPK9DPuWHpUHAMyTB9tG/hmHuF1HIuVuDNPde1J OoVMM/RkuvNFEhjOTJbotfEwXjSEOqgvLpMM+ZQIGk9hm7yM67 2hx4Fx//qQOaV6fOIL5s6Nian5hm8/t8TjTUike0DwHjnHiRK2 AR2z3pD7vrQmj+64OTwgaFvTZH4sTCXjaOER+YBGg Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:44:05 -0000 When I built mine, my goal was to be able to rebuild the same thing I tested later on a different machine, so I used a specific date in my supfile: *default date=2011.09.27.00.00.00 But you can also do: # uname -a FreeBSD bcnas1.bc.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Sep 29 15:06:03 CEST 2011 root@bcnas1.bc.local:/usr/obj/usr/src/sys/GENERIC amd64 Which as you can see, tells you a time somewhere around the csup'd version (Sept 27), but it is actually the build time (probably 'make buildkernel'). I am not sure what it would say for something you get from an iso (would it be a week after the release tag the day it was built, or the tag date, etc.). But if you install a snapshot, such as the 8.2-STABLE-201105 iso you can find on ftp, it says 8.2-STABLE-201105 instead of 8.2-STABLE. Peter On 01/25/2012 11:48 AM, Damien Fleuriot wrote: > Hijacking thread quickly. > > How do you guys usually check your build/csup date on -stable and such ? > > I guess I'd go with the latest kernel build date, but there may be > better ways. > > > On 1/25/12 10:58 AM, Peter Maloney wrote: >> When was your 8.2-STABLE built / csup'd? >> >> Peter >> >> >> On 01/25/2012 09:40 AM, Michel Le Cocq wrote: >>> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. >>> Intel(R) Atom(TM) CPU D510 @ 1.66GHz >>> real memory = 4294967296 (4096 MB) >>> avail memory = 3127390208 (2982 MB) >>> >>> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for >>> data. >>> >>> # zpool list >>> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >>> data 931G 254G 677G 27% 1.00x ONLINE - >>> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - >>> tank 696G 574G 122G 82% 1.00x ONLINE - >>> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - >>> >>> Before upgrade, I must use some mana things in my /boot/loader.conf >>> >>> vm.kmem_size="330M" >>> vm.kmem_size_max="330M" >>> vfs.zfs.arc_max="40M" >>> vfs.zfs.vdev.cache.size="5M" >>> >>> With this config my server was not so stable. >>> >>> Some days it work perfectly, some others it freeze with kmem_malloc >>> kmem_map too small. >>> Without this mana it freeze really often. >>> >>> The thing which make me upgrade is that after one of this crash after >>> reboot it won't mount my data pool which was at 99% of his CAP. The >>> only way I find to boot is to disconnect the pools drive and export >>> it. >>> >>> Now I'm on exactly the same host after upgrade to 9.0 and it seems to >>> work really really better (3 days up with out any trouble). >>> >>> -- >>> M >>> >>> Garrett Cooper a écrit: >>>> The following reply was made to PR kern/146528; it has been noted by GNATS. >>>> >>>> From: Garrett Cooper >>>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >>>> Cc: >>>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >>>> Date: Sun, 9 Oct 2011 12:34:00 -0700 >>>> >>>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >>>> issue persists with ZFS v28? >>>> -Garrett >>>> _______________________________________________ >>>> 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" >> > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:54:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C239C106566B for ; Wed, 25 Jan 2012 11:54:58 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 6620E8FC0A for ; Wed, 25 Jan 2012 11:54:58 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MAkmJ-1Rvksc0SJX-00Bjh3; Wed, 25 Jan 2012 12:54:57 +0100 Message-ID: <4F1FED90.50408@brockmann-consult.de> Date: Wed, 25 Jan 2012 12:54:56 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Michel Le Cocq References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <20120125110005.GA7000@e4310> <4F1FE3F1.2010301@brockmann-consult.de> <20120125113149.GB7000@e4310> In-Reply-To: <20120125113149.GB7000@e4310> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:A63qPErMAGC+hdy3jH0DJWwJxb9c8uPNbLurIBTH99g /gSR/B8HxKd20+Ww7QtkrXWx+n8sGrudmeah8NRD50/TLL4Feo Rf34EpYawU//vZ2ybFy7xH01FIvG1I4Y4lARnzWBKuq4kEwz5k Cn65tBf+iSCT4TdZnfL7wEkvQ+bPV+ujrLZso6dx2xeghX/FpV G6KucMd9T1gmbU4N+z0s2pt+pOmzGxIFdOBGZRx0laSIQ0S4Bh mQpqyQs+ayszoX3EBxpJo4P3XhdLcpHQKPnZLUQXRoG0EtYSIT k3aXVaJtwuVpiGfPh3giShlkF5PX78TIHPnNH4LK3pJm2Py6nC VQrBZFtySWiuojSdMV+PKPTlViKYT5iW2+s6lsUbC Cc: freebsd-fs@freebsd.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:54:58 -0000 So then I guess the simple answer is that you should consider a hardware upgrade. With ZFS, you should be using a 64 bit system. And ZFS wants lots of memory, so since memory is cheap, get at least 8 GB. I have 16 GB on my workstation; and it is great. Memory caches everything, so the file system is very fast. And I can run my Virtual machines with as much memory as I want, and still have a comfortable amount left over for the base system. On 01/25/2012 12:31 PM, Michel Le Cocq wrote: > ok in fact I didn't understand your first question ! > > I see this trouble only on my personnal i386 machine. > I have also several amd64 with a lot of mem 24G or some virtual with > 4G all on amd64 and they work perfectly on 8.2 since more than 1 year. > > -- > M > > Peter Maloney a écrit: >> I expected you would say it was much older, somewhere between April and >> September last year. My amd64 systems (dual cpu quad core Xeon) with 48 >> GB of ram have no issues like this. And my amd64 test VMs with 512M-2GB >> of RAM don't have this problem either, but of course they aren't tested >> the same. >> >> >> >> On 01/25/2012 12:00 PM, Michel Le Cocq wrote: >>> I recently update 1 week maybe ! >>> >>> Peter Maloney a écrit: >>>> When was your 8.2-STABLE built / csup'd? >>>> >>>> Peter >>>> >>>> >>>> On 01/25/2012 09:40 AM, Michel Le Cocq wrote: >>>>> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. >>>>> Intel(R) Atom(TM) CPU D510 @ 1.66GHz >>>>> real memory = 4294967296 (4096 MB) >>>>> avail memory = 3127390208 (2982 MB) >>>>> >>>>> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for >>>>> data. >>>>> >>>>> # zpool list >>>>> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >>>>> data 931G 254G 677G 27% 1.00x ONLINE - >>>>> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - >>>>> tank 696G 574G 122G 82% 1.00x ONLINE - >>>>> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - >>>>> >>>>> Before upgrade, I must use some mana things in my /boot/loader.conf >>>>> >>>>> vm.kmem_size="330M" >>>>> vm.kmem_size_max="330M" >>>>> vfs.zfs.arc_max="40M" >>>>> vfs.zfs.vdev.cache.size="5M" >>>>> >>>>> With this config my server was not so stable. >>>>> >>>>> Some days it work perfectly, some others it freeze with kmem_malloc >>>>> kmem_map too small. >>>>> Without this mana it freeze really often. >>>>> >>>>> The thing which make me upgrade is that after one of this crash after >>>>> reboot it won't mount my data pool which was at 99% of his CAP. The >>>>> only way I find to boot is to disconnect the pools drive and export >>>>> it. >>>>> >>>>> Now I'm on exactly the same host after upgrade to 9.0 and it seems to >>>>> work really really better (3 days up with out any trouble). >>>>> >>>>> -- >>>>> M >>>>> >>>>> Garrett Cooper a écrit: >>>>>> The following reply was made to PR kern/146528; it has been noted by GNATS. >>>>>> >>>>>> From: Garrett Cooper >>>>>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >>>>>> Cc: >>>>>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >>>>>> Date: Sun, 9 Oct 2011 12:34:00 -0700 >>>>>> >>>>>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >>>>>> issue persists with ZFS v28? >>>>>> -Garrett >>>>>> _______________________________________________ >>>>>> 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:59:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E69071065672 for ; Wed, 25 Jan 2012 11:59:14 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id C7A928FC0A for ; Wed, 25 Jan 2012 11:59:14 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta06.emeryville.ca.mail.comcast.net with comcast id RnxR1i00216AWCUA6nzEnh; Wed, 25 Jan 2012 11:59:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id RnzD1i00C1t3BNj8SnzD0D; Wed, 25 Jan 2012 11:59:13 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4B0D4102C19; Wed, 25 Jan 2012 03:59:13 -0800 (PST) Date: Wed, 25 Jan 2012 03:59:13 -0800 From: Jeremy Chadwick To: Michel Le Cocq Message-ID: <20120125115913.GA30376@icarus.home.lan> References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120125084040.GA2831@e4310> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , freebsd-fs@FreeBSD.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:59:15 -0000 On Wed, Jan 25, 2012 at 09:40:50AM +0100, Michel Le Cocq wrote: > Before upgrade, I must use some mana things in my /boot/loader.conf > > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="40M" > vfs.zfs.vdev.cache.size="5M" > > With this config my server was not so stable. > > Some days it work perfectly, some others it freeze with kmem_malloc > kmem_map too small. > Without this mana it freeze really often. You should remove the vm.kmem_size and vm.kmem_size_max settings from loader.conf. (This is at least the case for amd64, and I'm pretty sure the same advice applies to i386. The lack-of need for adjusting either of these variables has existed for, I think, a year now.) The other options you have specific to ZFS can stay. Also, your ARC maximum is extremely low; can you please increase this to something more reasonable, say, 256MBytes or 384MBytes? This may explain the "freeze really often" clause, assuming you mean "the system suddenly pauses, takes a while, then recovers". If by "freeze really often" you mean "locks up hard", that's a different problem. If the freezing is intermittent (and recovers), are you using dedup or compression? If so, please cease. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 13:19:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25284106564A for ; Wed, 25 Jan 2012 13:19:47 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD738FC13 for ; Wed, 25 Jan 2012 13:19:46 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5937173wib.13 for ; Wed, 25 Jan 2012 05:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TFuAkgYBd8Q5cOi5GJfdZ3SaBvoSCNXuMtwd2DDtJow=; b=mgic06flKmvDkGeLvUimRdvoadjcONjplxscKT4bxWeS1RAD1fOJJnwM5OCwUnQ8+B 5m1b40139of9smRxsg7iLGs/dedVTnKYYWp7k/O8qJXzFPbtSjcb5Gq4pAAZYHvx2qGJ Vzju0sZeI8nE65cyfye/OiZLrib+JCMH+YiMw= Received: by 10.180.108.232 with SMTP id hn8mr28287113wib.16.1327497585586; Wed, 25 Jan 2012 05:19:45 -0800 (PST) Received: from green.tandem.local (155-194-200-46.pool.ukrtel.net. [46.200.194.155]) by mx.google.com with ESMTPS id ho4sm24358535wib.3.2012.01.25.05.19.43 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 05:19:44 -0800 (PST) Message-ID: <4F20016E.8020003@gmail.com> Date: Wed, 25 Jan 2012 15:19:42 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0.1) Gecko/20120110 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: Damien Fleuriot References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <4F1FDDF8.6020300@my.gd> In-Reply-To: <4F1FDDF8.6020300@my.gd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:19:47 -0000 Damien Fleuriot wrote: > Hijacking thread quickly. > > How do you guys usually check your build/csup date on -stable and such ? > > I guess I'd go with the latest kernel build date, but there may be > better ways. ls -la /var/db/sup/src-all/ -- Sphinx of black quartz judge my vow. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 16:10:23 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC8FD106566B; Wed, 25 Jan 2012 16:10:23 +0000 (UTC) (envelope-from martin.ranne@kockumsonics.com) Received: from webmail.kockumsonics.com (mail.kockumsonics.com [194.103.55.3]) by mx1.freebsd.org (Postfix) with ESMTP id EE4FF8FC08; Wed, 25 Jan 2012 16:10:22 +0000 (UTC) Received: from MAILGATE.sonet.local ([192.168.12.8]) by mailgate ([192.168.12.8]) with mapi id 14.01.0355.002; Wed, 25 Jan 2012 17:10:20 +0100 From: Martin Ranne To: 'Andriy Gapon' Thread-Topic: zpool import reboots computer Thread-Index: AczWvHf/qf1tgj/cQ3aTdT164KORYwAAxbSAAARQzcD///SRAP//zVoQgABYagD//xWRYIADrTyA//zFgGAAzUT8gP//s7ww//9W/wD/+8I8EA== Date: Wed, 25 Jan 2012 16:10:19 +0000 Message-ID: <39C592E81AEC0B418EAD826FC1BBB09B25CF08@mailgate> References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> <4F1D75CD.6050000@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> <4F1DC398.3050502@FreeBSD.org> In-Reply-To: <4F1DC398.3050502@FreeBSD.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.15.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-fs@freebsd.org'" Subject: RE: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:10:23 -0000 Thank you everyone who have helped me with hacking zfs. We have now been ab= le to do an import of the pool and transfered all the data to another compu= ter. Next step is to see if we can quickly repair the pool or just delete i= t and make it new again. We hacked the functions vdev_mirror_child_select() and vdev_mirror_io_start= (). In vdev_mirror_io_start() we added the code below just after the mc poi= nter was set in both loops. if (mc->mc_vd =3D=3D NULL) { (void) printf("mc->mc_vd is NULL. Child %i\n", c); continue; } In vdev_mirror_child_select(), we added the code below just after the mc po= inter was set. if (mc->mc_vd =3D=3D NULL) { (void) printf("mc->mc_vd is NULL. Child %i\n", c); mc->mc_tried =3D 1; mc->mc_skipped =3D 1; continue; } Best regards, Martin Ranne >On 2012-01-23 21:31, Andriy Gapon wrote:=20 >>on 23/01/2012 20:33 Martin Ranne said the following: >>Have done some checking and found mc->mc_vd =3D=3D NULL in the function v= dev_mirror_io_start() where the while-loop is.=20 >> >>while (children--) {=20 >> mc =3D &mm->mm_child[c]; >> zio_nowait(zio_vdev_child_io(zio, zio->io_bp, >> mc->mc_vd, mc->mc_offset, zio->io_data, zio->io_size, >> zio->io_type, zio->io_priority, 0, >> vdev_mirror_child_done, mc)); >> c++; >>} >> >>if i set a break before it runs zio_nowait() it will still crash the kern= el.=20 >>What can i check next for it to be able to continue? Is it possible to ha= ve it ignore the child where mc_vd is NULL? I am also looking into what mor= e I can do to debug it (adding code to print to console as i can not use ke= rnel dumps). >> >Not sure. If by "set a break" you mean inserting a break statement, try >continue instead. > From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 16:24:39 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30C61065672 for ; Wed, 25 Jan 2012 16:24:38 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 67A678FC16 for ; Wed, 25 Jan 2012 16:24:37 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 7C0949DC4D9 for ; Wed, 25 Jan 2012 17:24:36 +0100 (CET) From: Borja Marcos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 17:24:35 +0100 Message-Id: <8E5FB8BA-DB11-459A-8DD8-6A5FA5275177@sarenet.es> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Is swap over ZFS safe on FreeBSD 9? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:24:39 -0000 Hi I decided to give another try to swap over ZFS. I've created a volume, = added it as swap, and I've tried something crazy: make -j 128 buildworld The system is hung, it still responds to ping and establishes TCP = connections, but nothing else.=20 last pid: 70437; load averages: 16.19, 12.86, 8.27 up 0+04:57:12 = 16:54:32 203 processes: 1 running, 202 sleeping CPU: 0.0% user, 0.0% nice, 0.1% system, 0.1% interrupt, 99.9% idle Mem: 6409M Active, 83M Inact, 1421M Wired Swap: 32G Total, 45M Used, 32G Free Timeout, server not responding. HR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1790 borjam 1 47 0 16700K 1448K CPU2 2 1:44 9.81% top 1729 borjam 1 48 0 35604K 1064K pfault 10 1:25 8.59% zpool 70436 root 1 63 0 178M 168M pfault 1 0:06 4.78% = cc1plus 70316 root 1 63 0 195M 186M pfault 0 0:06 4.45% = cc1plus 70370 root 1 63 0 173M 162M pfault 7 0:05 4.28% = cc1plus 70300 root 1 63 0 207M 196M pfault 7 0:05 4.17% = cc1plus 70389 root 1 63 0 179M 168M pfault 2 0:05 4.12% = cc1plus 70390 root 1 63 0 185M 174M pfault 11 0:05 4.01% = cc1plus 70297 root 1 62 0 194M 184M pfault 2 0:05 4.01% = cc1plus 70421 root 1 62 0 168M 159M pfault 9 0:05 3.84% = cc1plus 70379 root 1 62 0 195M 184M pfault 9 0:04 3.84% = cc1plus 70372 root 1 62 0 189M 175M pfault 4 0:04 3.79% = cc1plus 70384 root 1 62 0 155M 146M pfault 2 0:04 3.62% = cc1plus 70288 root 1 62 0 179M 162M pfault 3 0:04 3.51% = cc1plus 70382 root 1 62 0 160M 149M pfault 11 0:04 3.40% = cc1plus 70430 root 1 62 0 158M 148M pfault 8 0:04 3.35% = cc1plus 70313 root 1 62 0 193M 183M pfault 10 0:04 3.29% = cc1plus Lots of processes are in "pfault" state. I tried to disable "sync", = primarycache and secondarycache for the swap volume, but without = success. Testing again, last pid: 88772; load averages: 0.00, 0.79, 2.73 up 0+00:28:14 = 17:34:15 186 processes: 1 running, 184 sleeping, 1 waiting CPU: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle Mem: 6711M Active, 683M Inact, 519M Wired Swap: 32G Total, 116M Used, 32G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 3839 root 1 40 0 16700K 1412K CPU0 0 0:10 0.00% top 88692 root 1 53 0 259M 247M pfault 2 0:07 0.00% = cc1plus 88729 root 1 -20 0 199M 182M swread 2 0:07 0.00% = cc1plus 88750 root 1 52 0 166M 154M pfault 2 0:06 0.00% = cc1plus 88763 root 1 52 0 226M 211M pfault 8 0:06 0.00% = cc1plus 88768 root 1 -20 0 206M 191M swread 6 0:06 0.00% = cc1plus 88637 root 1 -20 0 218M 202M swread 11 0:06 0.00% = cc1plus 88643 root 1 52 0 219M 204M pfault 7 0:06 0.00% = cc1plus 88657 root 1 -20 0 225M 210M swread 4 0:06 0.00% = cc1plus 88748 root 1 -20 0 232M 217M swread 3 0:06 0.00% = cc1plus 88771 root 1 -20 0 235M 220M swread 6 0:06 0.00% = cc1plus 88701 root 1 52 0 218M 203M pfault 3 0:06 0.00% = cc1plus 88749 root 1 52 0 219M 205M pfault 1 0:05 0.00% = cc1plus 88682 root 1 -20 0 201M 189M swread 0 0:05 0.00% = cc1plus 88711 root 1 -20 0 240M 227M swread 2 0:05 0.00% = cc1plus 88696 root 1 52 0 232M 218M pfault 5 0:05 0.00% = cc1plus 88664 root 1 -20 0 222M 207M swread 5 0:05 0.00% = cc1plus Any ideas? I guess I better stay away from swap on ZFS for now. Borja.= From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 16:37:16 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764CA106566C for ; Wed, 25 Jan 2012 16:37:16 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 35B248FC14 for ; Wed, 25 Jan 2012 16:37:15 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 6AB2B9DC4D3; Wed, 25 Jan 2012 17:37:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <8E5FB8BA-DB11-459A-8DD8-6A5FA5275177@sarenet.es> Date: Wed, 25 Jan 2012 17:37:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50934135-5737-466D-B60E-83C47E679530@sarenet.es> References: <8E5FB8BA-DB11-459A-8DD8-6A5FA5275177@sarenet.es> To: Borja Marcos X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org Subject: Re: Is swap over ZFS safe on FreeBSD 9? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:37:16 -0000 On Jan 25, 2012, at 5:24 PM, Borja Marcos wrote: >=20 > Hi >=20 > I decided to give another try to swap over ZFS. I've created a volume, = added it as swap, and I've tried something crazy: >=20 > make -j 128 buildworld >=20 > The system is hung, it still responds to ping and establishes TCP = connections, but nothing else.=20 Second time I've tried (I hadn't access to the console) it was = displaying: "swap_pager: indefinite wait buffer: bufobj:..." Borja. From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 20:50:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58042106566B for ; Wed, 25 Jan 2012 20:50:29 +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 9CB958FC1E for ; Wed, 25 Jan 2012 20:50:28 +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 WAA14087; Wed, 25 Jan 2012 22:50:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rq9nT-0006tZ-Le; Wed, 25 Jan 2012 22:50:23 +0200 Message-ID: <4F206B0E.90102@FreeBSD.org> Date: Wed, 25 Jan 2012 22:50:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Martin Ranne References: <39C592E81AEC0B418EAD826FC1BBB09B25031D@mailgate> <4F18459F.7040309@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B252444@mailgate> <4F1858FE.7020509@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25253F@mailgate> <4F1878AC.6060704@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25284B@mailgate> <4F1AC995.7050506@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B255E15@mailgate> <4F1D75CD.6050000@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25607F@mailgate> <4F1DC398.3050502@FreeBSD.org> <39C592E81AEC0B418EAD826FC1BBB09B25CF08@mailgate> In-Reply-To: <39C592E81AEC0B418EAD826FC1BBB09B25CF08@mailgate> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'freebsd-fs@freebsd.org'" Subject: Re: zpool import reboots computer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:50:29 -0000 on 25/01/2012 18:10 Martin Ranne said the following: > Thank you everyone who have helped me with hacking zfs. We have now been able to do an import of the pool and transfered all the data to another computer. Next step is to see if we can quickly repair the pool or just delete it and make it new again. > > We hacked the functions vdev_mirror_child_select() and vdev_mirror_io_start(). In vdev_mirror_io_start() we added the code below just after the mc pointer was set in both loops. Great! I think that it might be useful for you to track down where and why the NULL value sneaks into mc_vd. Perhaps the problem is only with vdev label. > if (mc->mc_vd == NULL) { > (void) printf("mc->mc_vd is NULL. Child %i\n", c); > continue; > } > > In vdev_mirror_child_select(), we added the code below just after the mc pointer was set. > > if (mc->mc_vd == NULL) { > (void) printf("mc->mc_vd is NULL. Child %i\n", c); > mc->mc_tried = 1; > mc->mc_skipped = 1; > continue; > } -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 04:01:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A0A1065673 for ; Thu, 26 Jan 2012 04:01:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF058FC15 for ; Thu, 26 Jan 2012 04:01:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFAGHPIE+DaFvO/2dsb2JhbABDhQmncgGCT4IcgQsCDRkCoTCOC5FTgS+HaQEFAxwEAQsBCAEGBAMDBBAPAQIBAoJmBQMDAQIHAxUBBQsHAgGBCQwnggaBFgSIP4xekm8 X-IronPort-AV: E=Sophos;i="4.71,572,1320642000"; d="scan'208";a="153757422" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Jan 2012 23:01:41 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B54CAB3EFF for ; Wed, 25 Jan 2012 23:01:41 -0500 (EST) Date: Wed, 25 Jan 2012 23:01:41 -0500 (EST) From: Rick Macklem To: freebsd-fs@freebsd.org Message-ID: <1280581135.166316.1327550501697.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Subject: Is doing mount -u -o udp useful for you on an NFS mount? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:01:42 -0000 Hi, Using a "mount -u" to change from TCP to UDP for an NFS mount is somewhat broken for both NFS clients. To make it work correctly is not trivial. As such, I'd like to find out if anyone needs this capability? (Note, I am not talking about UDP mounts in general, just the case of switching a TCP mount to a UDP mount without doing an unmount/mount.) Thanks in advance for your feedback, rick From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 08:01:54 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0A7B0106566B for ; Thu, 26 Jan 2012 08:01:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 92413150EBB; Thu, 26 Jan 2012 08:01:53 +0000 (UTC) Message-ID: <4F210870.5050908@FreeBSD.org> Date: Thu, 26 Jan 2012 00:01:52 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: Rick Macklem References: <1280581135.166316.1327550501697.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1280581135.166316.1327550501697.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Is doing mount -u -o udp useful for you on an NFS mount? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:01:54 -0000 On 01/25/2012 20:01, Rick Macklem wrote: > Hi, > > Using a "mount -u" to change from TCP to UDP for an > NFS mount is somewhat broken for both NFS clients. > To make it work correctly is not trivial. > > As such, I'd like to find out if anyone needs this > capability? (Note, I am not talking about UDP mounts > in general, just the case of switching a TCP mount to > a UDP mount without doing an unmount/mount.) Personally I couldn't imagine a scenario where I would do this even if someone told me it was supposed to work. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 08:22:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4317106564A for ; Thu, 26 Jan 2012 08:22:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id B60088FC0A for ; Thu, 26 Jan 2012 08:22:09 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta04.emeryville.ca.mail.comcast.net with comcast id S8MY1i0010EPchoA48N97l; Thu, 26 Jan 2012 08:22:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.emeryville.ca.mail.comcast.net with comcast id S8N81i00o1t3BNj8M8N8Em; Thu, 26 Jan 2012 08:22:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2D19B102C19; Thu, 26 Jan 2012 00:22:08 -0800 (PST) Date: Thu, 26 Jan 2012 00:22:08 -0800 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20120126082208.GA49394@icarus.home.lan> References: <1280581135.166316.1327550501697.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280581135.166316.1327550501697.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Is doing mount -u -o udp useful for you on an NFS mount? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:22:09 -0000 On Wed, Jan 25, 2012 at 11:01:41PM -0500, Rick Macklem wrote: > Using a "mount -u" to change from TCP to UDP for an > NFS mount is somewhat broken for both NFS clients. > To make it work correctly is not trivial. > > As such, I'd like to find out if anyone needs this > capability? (Note, I am not talking about UDP mounts > in general, just the case of switching a TCP mount to > a UDP mount without doing an unmount/mount.) I've never seen any SAN admin do this, even on our production server at work (Solaris with a NetApp SAN). When it comes to NFS, the moral of the story is always "reboot the machine" (which is good anyway, make sure everything comes up on boot, else months from now you'll find out the hard way). However, to squelch people from doing it, could mount_nfs(8) actually be modified to spit out a nastygram when someone attempts to do this, so at least the admin would know that such isn't supported due to the extreme complexities involved? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 09:41:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71A21065673 for ; Thu, 26 Jan 2012 09:41:47 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id CEAD98FC14 for ; Thu, 26 Jan 2012 09:41:46 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MAkmJ-1Rk3753TS7-00BjdS; Thu, 26 Jan 2012 10:41:29 +0100 Message-ID: <4F211FC7.3080709@brockmann-consult.de> Date: Thu, 26 Jan 2012 10:41:27 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F192ADA.5020903@brockmann-consult.de> <1327069331.29444.4.camel@btw.pki2.com> <4F197F8D.7010404@brockmann-consult.de> In-Reply-To: <4F197F8D.7010404@brockmann-consult.de> X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:M6HYNNZnlP19MTtnPkS/qYFb6pAEf5xne7MsCx5GlZa 9fwT939CkIVtxVaKk2rSvREkYXrpUulIVZiARJ0+FcjXfDxSGA NFpfq0+7fqA0EgSLBWZuSFyqDVe3bZaf2WF/9sug59c7kE6J1l 6IsnZTOg1ETUusbfl8vyfZ001QbnVj2RAfUchuo+cTjW0lajjx DLoAfjtCJ/jZ226NrfZu7/3Y2OF0u7CvzfYjxCuTyJgnzYt16N 7C8oRYpniEoANc9n1yuRgwTEHfTgEN1iK11VBL6KcKYqevM4EQ H9MM8dQT3tpNYSlR9Xw06lB7vfF2/pMmF0+Z66SBEjz3z7+w5C IlPO81cCtXR4Y2Nm1tWz6D6moR0DSXE9jTdJIPd0a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: sanity check: is 9211-8i, on 8.3, with IT firmware still "the one" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 09:41:47 -0000 On 01/20/2012 03:51 PM, Peter Maloney wrote: > On 01/20/2012 03:22 PM, Dennis Glatting wrote: >> I am having a problem with Seagate ST1000DL002 disks but I haven't yet >> determined weather it is the disks themselves (they -- two of them, new >> -- fail under a MB controller too. > I happen to have some ST2000DL003 disks on hand (same as yours, but 2TB > instead of 1, and I don't know what firmware)... I could try my hot pull > test with them to see what happens. Update: I tested it, and it fails much like the Crucial SSD with old firmware, except: -with the SSD, I could still use smartctl to see the disk afterwards, but not with the Seagate Green. (I didn't verify this with the SSD, but I think it has a /dev/da# device, but the Seagate does not) -the Seagate Green never comes back at all, but the SSD which is reported as coming back, but has an error "daasync: Unable to attach to new device due to status 0x6" which makes the disk unusable until reboot So in the distant future, I will test newest firmware (currently using firmware CC45 I think, and yours is CC32), then send some email to Seagate about it. And in the near future, I will not be using those disks in ZFS. Your disk is firmware CC32 I would assume: da12: Fixed Direct Access SCSI-6 device Seagate Green (insert device) Jan 26 09:52:28 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x21 with try_count = 1 Jan 26 09:52:28 bcnas1bak kernel: SAS Address for SATA device = 1f605d2f7e735344 Jan 26 09:52:28 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x21 with try_count = 1 Jan 26 09:52:28 bcnas1bak kernel: da20 at mpslsi0 bus 0 scbus0 target 55 lun 0 Jan 26 09:52:28 bcnas1bak kernel: da20: Fixed Direct Access SCSI-6 device Jan 26 09:52:28 bcnas1bak kernel: da20: 600.000MB/s transfers Jan 26 09:52:28 bcnas1bak kernel: da20: Command Queueing enabled Jan 26 09:52:28 bcnas1bak kernel: da20: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) (insert another device, make a mirror vdev) (pull device while writing to it) Jan 26 09:53:53 bcnas1bak kernel: mpslsi0: mpssas_alloc_tm freezing simq Jan 26 09:53:53 bcnas1bak kernel: mpslsi0: mpssas_lost_target targetid 55 Jan 26 09:53:53 bcnas1bak kernel: (da20:mpslsi0:0:55:0): lost device Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9c 8b 0 1 0 0 length 131072 SMID 232 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d a2 8b 0 1 0 0 length 131072 SMID 856 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9b 8b 0 1 0 0 length 131072 SMID 813 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d a1 8b 0 1 0 0 length 131072 SMID 626 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d a0 8b 0 1 0 0 length 131072 SMID 141 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9f 8b 0 1 0 0 length 131072 SMID 250 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9e 8b 0 1 0 0 length 131072 SMID 734 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9d 8b 0 1 0 0 length 131072 SMID 531 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d a3 8b 0 1 0 0 length 131072 SMID 260 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: 2a 0 0 d 9a 8b 0 1 0 0 length 131072 SMID 503 terminated ioc 804b scsi 0 state c xfer 0 Jan 26 09:53:54 bcnas1bak kernel: mpslsi0: IOCStatus = 0x4b while resetting device 0x21 Jan 26 09:53:54 bcnas1bak kernel: mpslsi0: mpssas_free_tm releasing simq Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): removing device entry (put device back in) (no further logs) And then I tried: camcontrol reset 0:55:0 (or 0:0:55? forget where the 0 goes) and it said there was no device. camcontrol reset 0:54:0 (this is the other disk of the same type that I had in the same test mirror vdev), and the kernel panicked, and this appeared in /var/log/messages: Jan 26 09:57:14 bcnas1bak kernel: mpslsi0: mpssas_action XPT_RESET_DEV Crucial SSD with firmware 0001 (pull device while writing to it) Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): CAM status: SCSI Status Error Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI status: Check Condition Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f2 19 0 0 ff 0 length 130560 SMID 292 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f4 d3 0 0 9e 0 length 80896 SMID 426 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f5 71 0 0 cf 0 length 105984 SMID 978 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f6 40 0 0 b2 0 length 91136 SMID 695 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f6 f2 0 0 9f 0 length 81408 SMID 792 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f3 df 0 0 f4 0 length 124928 SMID 615 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f3 18 0 0 c7 0 length 101888 SMID 645 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 c2 83 ec 0 0 8 0 length 4096 SMID 163 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f8 61 0 0 b3 0 length 91648 SMID 222 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f9 14 0 0 ed 0 length 121344 SMID 651 terminated ioc 804b scsi 0 state 0 xfer 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: 28 0 0 ce f1 91 0 0 1c 0 Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): CAM status: SCSI Status Error Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI status: Check Condition Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): lost device Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: Reset aborted 21 commands Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: clearing target 46 handle 0x0024 Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: mpssas_remove_complete on handle 0x0024, IOCStatus= 0x0 Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: mpssas_free_tm releasing simq Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): Synchronize cache failed, status == 0x39, scsi status == 0x0 Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): removing device entry (put device back in) Jan 19 14:41:32 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x24 with try_count = 1 Jan 19 14:41:32 bcnas1bak kernel: SAS Address for SATA device = d828161ba16c7889 Jan 19 14:41:33 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x24 with try_count = 1 Jan 19 14:41:33 bcnas1bak kernel: da20 at mpslsi0 bus 0 scbus0 target 46 lun 0 Jan 19 14:41:33 bcnas1bak kernel: da20: Fixed Direct Access SCSI-6 device Jan 19 14:41:33 bcnas1bak kernel: da20: 600.000MB/s transfers Jan 19 14:41:33 bcnas1bak kernel: da20: Command Queueing enabled Jan 19 14:41:33 bcnas1bak kernel: da20: 244198MB (500118192 512 byte sectors: 255H 63S/T 31130C) Jan 19 14:41:42 bcnas1bak kernel: pid 19175 (gpart), uid 0: exited on signal 11 (core dumped) Jan 19 14:42:30 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x18 with try_count = 1 Jan 19 14:42:30 bcnas1bak kernel: SAS Address for SATA device = d828161ba16c748a Jan 19 14:42:30 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: got SATA identify successfully for handle = 0x18 with try_count = 1 Jan 19 14:42:31 bcnas1bak kernel: cam_periph_alloc: attempt to re-allocate valid device da10 rejected *Jan 19 14:42:31 bcnas1bak kernel: daasync: Unable to attach to new device due to status 0x6* (no further logs) > What sort of failure is happening? > > Do you use a ZIL on a device other than an ST1000DL002? > > Please send output of > smartctl -i > > (particularly interested in firmware version) > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 11:27:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 401E0106566C for ; Thu, 26 Jan 2012 11:27:10 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF3AE8FC12 for ; Thu, 26 Jan 2012 11:27:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q0QBQxbi035582; Thu, 26 Jan 2012 03:27:00 -0800 (PST) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: Peter Maloney In-Reply-To: <4F211FC7.3080709@brockmann-consult.de> References: <4F192ADA.5020903@brockmann-consult.de> <1327069331.29444.4.camel@btw.pki2.com> <4F197F8D.7010404@brockmann-consult.de> <4F211FC7.3080709@brockmann-consult.de> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 26 Jan 2012 03:26:59 -0800 Message-ID: <1327577219.19717.13.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: q0QBQxbi035582 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com Cc: freebsd-fs@freebsd.org Subject: Re: sanity check: is 9211-8i, on 8.3, with IT firmware still "the one" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 11:27:10 -0000 On Thu, 2012-01-26 at 10:41 +0100, Peter Maloney wrote: > On 01/20/2012 03:51 PM, Peter Maloney wrote: > > On 01/20/2012 03:22 PM, Dennis Glatting wrote: > >> I am having a problem with Seagate ST1000DL002 disks but I haven't yet > >> determined weather it is the disks themselves (they -- two of them, new > >> -- fail under a MB controller too. > > I happen to have some ST2000DL003 disks on hand (same as yours, but 2TB > > instead of 1, and I don't know what firmware)... I could try my hot pull > > test with them to see what happens. > Update: I tested it, and it fails much like the Crucial SSD with old > firmware, except: > > -with the SSD, I could still use smartctl to see the disk afterwards, > but not with the Seagate Green. (I didn't verify this with the SSD, but > I think it has a /dev/da# device, but the Seagate does not) > -the Seagate Green never comes back at all, but the SSD which is > reported as coming back, but has an error "daasync: Unable to attach to > new device due to status 0x6" which makes the disk unusable until reboot > > So in the distant future, I will test newest firmware (currently using > firmware CC45 I think, and yours is CC32), then send some email to > Seagate about it. And in the near future, I will not be using those > disks in ZFS. > Awesomeness dude. Thanks for the data. > Your disk is firmware CC32 I would assume: > > da12: Fixed Direct Access SCSI-6 device > > > > Seagate Green > > (insert device) > Jan 26 09:52:28 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x21 with try_count = 1 > Jan 26 09:52:28 bcnas1bak kernel: SAS Address for SATA device = > 1f605d2f7e735344 > Jan 26 09:52:28 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x21 with try_count = 1 > Jan 26 09:52:28 bcnas1bak kernel: da20 at mpslsi0 bus 0 scbus0 target 55 > lun 0 > Jan 26 09:52:28 bcnas1bak kernel: da20: > Fixed Direct Access SCSI-6 device > Jan 26 09:52:28 bcnas1bak kernel: da20: 600.000MB/s transfers > Jan 26 09:52:28 bcnas1bak kernel: da20: Command Queueing enabled > Jan 26 09:52:28 bcnas1bak kernel: da20: 1907729MB (3907029168 512 byte > sectors: 255H 63S/T 243201C) > (insert another device, make a mirror vdev) > (pull device while writing to it) > Jan 26 09:53:53 bcnas1bak kernel: mpslsi0: mpssas_alloc_tm freezing simq > Jan 26 09:53:53 bcnas1bak kernel: mpslsi0: mpssas_lost_target targetid 55 > Jan 26 09:53:53 bcnas1bak kernel: (da20:mpslsi0:0:55:0): lost device > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9c 8b 0 1 0 0 length 131072 SMID 232 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d a2 8b 0 1 0 0 length 131072 SMID 856 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9b 8b 0 1 0 0 length 131072 SMID 813 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d a1 8b 0 1 0 0 length 131072 SMID 626 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d a0 8b 0 1 0 0 length 131072 SMID 141 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9f 8b 0 1 0 0 length 131072 SMID 250 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9e 8b 0 1 0 0 length 131072 SMID 734 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9d 8b 0 1 0 0 length 131072 SMID 531 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d a3 8b 0 1 0 0 length 131072 SMID 260 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): WRITE(10). CDB: > 2a 0 0 d 9a 8b 0 1 0 0 length 131072 SMID 503 terminated ioc 804b scsi 0 > state c xfer 0 > Jan 26 09:53:54 bcnas1bak kernel: mpslsi0: IOCStatus = 0x4b while > resetting device 0x21 > Jan 26 09:53:54 bcnas1bak kernel: mpslsi0: mpssas_free_tm releasing simq > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): Synchronize > cache failed, status == 0xa, scsi status == 0x0 > Jan 26 09:53:54 bcnas1bak kernel: (da20:mpslsi0:0:55:0): removing device > entry > (put device back in) > (no further logs) > > And then I tried: > camcontrol reset 0:55:0 (or 0:0:55? forget where the 0 goes) and it said > there was no device. > camcontrol reset 0:54:0 (this is the other disk of the same type that I > had in the same test mirror vdev), and the kernel panicked, and this > appeared in /var/log/messages: > Jan 26 09:57:14 bcnas1bak kernel: mpslsi0: mpssas_action XPT_RESET_DEV > > > > Crucial SSD with firmware 0001 > > (pull device while writing to it) > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): CAM status: > SCSI Status Error > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI status: > Check Condition > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI sense: > ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f2 19 0 0 ff 0 length 130560 SMID 292 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f4 d3 0 0 9e 0 length 80896 SMID 426 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f5 71 0 0 cf 0 length 105984 SMID 978 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f6 40 0 0 b2 0 length 91136 SMID 695 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f6 f2 0 0 9f 0 length 81408 SMID 792 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f3 df 0 0 f4 0 length 124928 SMID 615 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f3 18 0 0 c7 0 length 101888 SMID 645 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 c2 83 ec 0 0 8 0 length 4096 SMID 163 terminated ioc 804b scsi 0 > state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f8 61 0 0 b3 0 length 91648 SMID 222 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f9 14 0 0 ed 0 length 121344 SMID 651 terminated ioc 804b scsi > 0 state 0 xfer 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): READ(10). CDB: > 28 0 0 ce f1 91 0 0 1c 0 > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): CAM status: > SCSI Status Error > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI status: > Check Condition > Jan 19 14:37:16 bcnas1bak kernel: (da20:mpslsi0:0:46:0): SCSI sense: > ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) > Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): lost device > Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: Reset aborted 21 commands > Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: clearing target 46 handle 0x0024 > Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: mpssas_remove_complete on > handle 0x0024, IOCStatus= 0x0 > Jan 19 14:40:05 bcnas1bak kernel: mpslsi0: mpssas_free_tm releasing simq > Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): Synchronize > cache failed, status == 0x39, scsi status == 0x0 > Jan 19 14:40:05 bcnas1bak kernel: (da20:mpslsi0:0:46:0): removing device > entry > (put device back in) > Jan 19 14:41:32 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x24 with try_count = 1 > Jan 19 14:41:32 bcnas1bak kernel: SAS Address for SATA device = > d828161ba16c7889 > Jan 19 14:41:33 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x24 with try_count = 1 > Jan 19 14:41:33 bcnas1bak kernel: da20 at mpslsi0 bus 0 scbus0 target 46 > lun 0 > Jan 19 14:41:33 bcnas1bak kernel: da20: Fixed > Direct Access SCSI-6 device > Jan 19 14:41:33 bcnas1bak kernel: da20: 600.000MB/s transfers > Jan 19 14:41:33 bcnas1bak kernel: da20: Command Queueing enabled > Jan 19 14:41:33 bcnas1bak kernel: da20: 244198MB (500118192 512 byte > sectors: 255H 63S/T 31130C) > Jan 19 14:41:42 bcnas1bak kernel: pid 19175 (gpart), uid 0: exited on > signal 11 (core dumped) > Jan 19 14:42:30 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x18 with try_count = 1 > Jan 19 14:42:30 bcnas1bak kernel: SAS Address for SATA device = > d828161ba16c748a > Jan 19 14:42:30 bcnas1bak kernel: mpssas_get_sas_address_for_sata_disk: > got SATA identify successfully for handle = 0x18 with try_count = 1 > Jan 19 14:42:31 bcnas1bak kernel: cam_periph_alloc: attempt to > re-allocate valid device da10 rejected > *Jan 19 14:42:31 bcnas1bak kernel: daasync: Unable to attach to new > device due to status 0x6* > (no further logs) > > > What sort of failure is happening? > > > > Do you use a ZIL on a device other than an ST1000DL002? > > > > Please send output of > > smartctl -i > > > > (particularly interested in firmware version) > > > > From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 17:24:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB5C0106566C for ; Thu, 26 Jan 2012 17:24:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F18A8FC16 for ; Thu, 26 Jan 2012 17:24:25 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 1D78115343A; Thu, 26 Jan 2012 18:24:24 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfPdOCd9D_qz; Thu, 26 Jan 2012 18:24:23 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 6D192153433; Thu, 26 Jan 2012 18:24:23 +0100 (CET) Message-ID: <4F218C49.9050905@digiware.nl> Date: Thu, 26 Jan 2012 18:24:25 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Maloney References: <4F193D90.9020703@digiware.nl> <20120121162906.0000518c@unknown> <4F1B0177.8080909@digiware.nl> <20120121230616.00006267@unknown> <4F1BC493.10304@brockmann-consult.de> <4F1C3597.4040009@digiware.nl> In-Reply-To: <4F1C3597.4040009@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Question about ZFS with log and cache on SSD with GPT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 17:24:25 -0000 On 2012-01-22 17:13, Willem Jan Withagen wrote: > On 22-1-2012 9:10, Peter Maloney wrote: >> Am 21.01.2012 23:06, schrieb Alexander Leidinger: >> Here is an example from our FreeBSD forum: >> http://forums.freebsd.org/showthread.php?t=19093 > > Thanx for this thread, there is a lot of usefull info there. > pithy thing is to blow 66Mb, but then again on 40 or 120 Gb SSDs it is > only marginal. (Guess it stems from the time that HDs where 5Mb :) ) > > I'm still not really shure that that is needed it the bios has nothing > to do with these disks, as in our case: SSDs are only used as caches > under ZFS. > > Especially the testing methods are useful. They are of course valid for > any type partinioning... > So getting things right on this level is the first required. > >>> I create the first partition at the usual 63 sectors offset from the >>> start of the disk (track 1) which is /unaligned/ with the SSD erase >>> block. The second partition is set to start at sector 21030912 >>> (10767826944 bytes) which is /aligned/ with the SSD erase block. I did have some testing time last night... So I removed the SSD's from the pool. En then first filled them up with atleas 40G of garbage to make shure the SSDs logic considered them full. Then I created the partitions without alignment gpart create -s GPT ada2 gpart add -s 512M -t freebsd-zfs ada2 gpart add -t freebsd-zfs ada2 (Not shure if this would TRIM the SSD?) On both partitions I got no more that 110Mb/s write speed, whatever I tried. (writing 512Mb or 10Gb of data) Then I recreated the partitions as suggested in the above article: gpart create -s GPT ada2 gpart add -b 129024 -s 512M -t freebsd-zfs ada2 gpart add -t freebsd-zfs ada2 Lo and behold: the write speed was 220Mb/s. So it does really, really really matter. And testing is relatively simple. I was not able to trash the zpool itself, so it still runds under ashift=9. And if that given akward SSD access, that is still around. But the lowest layer should now atleast perform. I'll get more testing time on the box next week when others are done testing. And then I'll rebuild the pool to get ashift=12. Regards, --WjW From owner-freebsd-fs@FreeBSD.ORG Thu Jan 26 22:44:52 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80E4106566B; Thu, 26 Jan 2012 22:44:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDC28FC16; Thu, 26 Jan 2012 22:44:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0QMiqAP076355; Thu, 26 Jan 2012 22:44:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0QMiq6n076351; Thu, 26 Jan 2012 22:44:52 GMT (envelope-from linimon) Date: Thu, 26 Jan 2012 22:44:52 GMT Message-Id: <201201262244.q0QMiq6n076351@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 22:44:52 -0000 Old Synopsis: unable to mount EXT2 filesystem New Synopsis: [ext2fs] unable to mount EXT2 filesystem Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 26 22:44:34 UTC 2012 Responsible-Changed-Why: reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=164516 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 00:16:24 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80AB91065673 for ; Fri, 27 Jan 2012 00:16:24 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4858C8FC19 for ; Fri, 27 Jan 2012 00:16:23 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q0QNnNvR000760; Thu, 26 Jan 2012 16:49:23 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q0QNnN4m000759; Thu, 26 Jan 2012 16:49:23 -0700 (MST) (envelope-from ken) Date: Thu, 26 Jan 2012 16:49:23 -0700 From: "Kenneth D. Merry" To: Nikolay Denev Message-ID: <20120126234923.GA712@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-fs@freebsd.org Subject: Re: BIO_DELETE support for ZVOLs? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 00:16:24 -0000 On Wed, Jan 25, 2012 at 09:51:04 +0200, Nikolay Denev wrote: > I'm don't know if anyone thought about this but it seems like a > nice feature to support TRIM like functionality for ZVOLs. > > For example : if there is a sparse ZFS volume, formatted with UFS, > and you fill it up once, then the disk space used will be with the size of the ZVOL. > Then even if there is freed space on the UFS filesystem, > the ZVOL disk space allocated from the ZVOL will remain the same. > > This also will be very nice if can be supported for FC exported ZVOLs via the new CAM Target Layer. > We're (i.e. Spectra Logic) planning to do trim support for CTL. The eventual goal is to plumb it all the way down through ZFS via the file and ZVOL paths, so that ZFS frees the space, and passes the trim commands down to any component disks so they can free the blocks as well. I don't know when that'll all get done, but we're planning to do it. If anyone wants it sooner, they're welcome to help with the implementation. :) Ken -- Kenneth Merry ken@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 00:53:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B560E106566B; Fri, 27 Jan 2012 00:53:05 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id D49988FC13; Fri, 27 Jan 2012 00:53:04 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so608225wgb.1 for ; Thu, 26 Jan 2012 16:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-virus-scanned; bh=96A9Ap1cKjjSG3Wq3oUNR2KVGmON8njWal6mIAoqB84=; b=v7aVJYBjywQ0H2Gf0shuVtvYIzXc+udcUuhDV8Cf0byT3vIQb2Z8fuVHXx2FaEkukm +pniQSFO1XoH4J8eUnGKARZE4qP2Gih0F1kDGTi3JluaRuQzEQJM/ylh1XtsDzqqrpv/ EZtSoHiSBZAyOLb3WTpJJ5AhvbCyxuXtpJaug= Received: by 10.180.81.35 with SMTP id w3mr7413940wix.10.1327625102068; Thu, 26 Jan 2012 16:45:02 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id u12sm8361921wiv.10.2012.01.26.16.45.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:45:01 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id 905B5CF06B; Fri, 27 Jan 2012 00:44:42 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id 31A24CF069; Fri, 27 Jan 2012 00:44:42 +0000 (WET) From: "=?iso-8859-1?Q?Ant=F3nio_Trindade?=" Date: Fri, 27 Jan 2012 00:44:41 +0000 References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-bugs@freebsd.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 00:53:05 -0000 > From: Ant=F3nio Trindade > Date: 27 de Janeiro de 2012 00:40:06 WET > To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, = freebsd-bugs@freebsd.org > Subject: kernel: panic: softdep_sync_buf: Unknown type jnewblk >=20 > Cheers. >=20 > I recently updated my system to FreeBSD-9.0 and activated softupdate = journaling for a number of file systems (name /home, /var, /usr). >=20 > Since then I have been experiencing kernel panics: > kernel: panic: softdep_sync_buf: Unknown type jnewblk >=20 > Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these = kernel panics. >=20 > I have now disabled softupdates journaling in the hope that the panics = disappear. >=20 > I am sorry for not providing more information about the panic, but = I'll gladly try to gather more info if instructed how to. >=20 > Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, > Ant=F3nio Trindade > Antonio Trindade gmail.com >=20 > S=EDtios pessoais: > Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ > Blog de fotografia: http://trindade.myphotos.cc/fotografia/ > Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ > Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >=20 I forgot some additional info: To deactivate softupdates journaling, I rebooted into single-user mode = and ran full fsck to every file system I had activated journaling for. To my surprise, fsck reported errors (namely wrong block counts and = bitmap errors, nothing serious). Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 01:03:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50F9B106566C; Fri, 27 Jan 2012 01:03:56 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA438FC0A; Fri, 27 Jan 2012 01:03:55 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1348052wib.13 for ; Thu, 26 Jan 2012 17:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-virus-scanned; bh=yBaQppE7IFfpT5fbyZJQlaenl56nUM8/S23+qTbKo6A=; b=QWcQBENQ8EBrcYKh6wlAilzEfUZx2UVpS5Psh03+UPV38w1F0v18XHvxFMxt8wK0wR 1jlXQBPCSq1cufArrMU0Y0z7V+kq5Fxafnmksv/CdvKq2MzBC9mIl2BUdcjEjKkz5o5M xYm1kCfURue0NdANjYku1Hm0ufNNaOCpRoOEA= Received: by 10.181.12.106 with SMTP id ep10mr8164858wid.8.1327626234429; Thu, 26 Jan 2012 17:03:54 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id ho4sm8463683wib.3.2012.01.26.17.03.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 17:03:53 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id C3B1DCF06B; Fri, 27 Jan 2012 01:03:50 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id 39A58CF069; Fri, 27 Jan 2012 01:03:50 +0000 (WET) From: "=?iso-8859-1?Q?Ant=F3nio_Trindade?=" Mime-Version: 1.0 (Apple Message framework v1084) Date: Fri, 27 Jan 2012 01:03:48 +0000 In-Reply-To: To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-bugs@freebsd.org References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> Message-Id: X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:03:56 -0000 I'm sorry for so many mails... Please cc me about this, because I'm not on any of the FreeBSD mailing = lists... Thanks in advance. Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ On 2012/01/27, at 00:44, Ant=F3nio Trindade wrote: >=20 >> From: Ant=F3nio Trindade >> Date: 27 de Janeiro de 2012 00:40:06 WET >> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, = freebsd-bugs@freebsd.org >> Subject: kernel: panic: softdep_sync_buf: Unknown type jnewblk >>=20 >> Cheers. >>=20 >> I recently updated my system to FreeBSD-9.0 and activated softupdate = journaling for a number of file systems (name /home, /var, /usr). >>=20 >> Since then I have been experiencing kernel panics: >> kernel: panic: softdep_sync_buf: Unknown type jnewblk >>=20 >> Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these = kernel panics. >>=20 >> I have now disabled softupdates journaling in the hope that the = panics disappear. >>=20 >> I am sorry for not providing more information about the panic, but = I'll gladly try to gather more info if instructed how to. >>=20 >> Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, >> Ant=F3nio Trindade >> Antonio Trindade gmail.com >>=20 >> S=EDtios pessoais: >> Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ >> Blog de fotografia: http://trindade.myphotos.cc/fotografia/ >> Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ >> Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >>=20 >=20 > I forgot some additional info: > To deactivate softupdates journaling, I rebooted into single-user mode = and ran full fsck to every file system I had activated journaling for. > To my surprise, fsck reported errors (namely wrong block counts and = bitmap errors, nothing serious). >=20 > Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, > Ant=F3nio Trindade > Antonio Trindade gmail.com >=20 > S=EDtios pessoais: > Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ > Blog de fotografia: http://trindade.myphotos.cc/fotografia/ > Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ > Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ >=20 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 01:09:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA73C106566C; Fri, 27 Jan 2012 01:09:05 +0000 (UTC) (envelope-from antonio.trindade@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC1B78FC0C; Fri, 27 Jan 2012 01:09:04 +0000 (UTC) Received: by werg1 with SMTP id g1so1365830wer.13 for ; Thu, 26 Jan 2012 17:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-virus-scanned; bh=yegifHQyyfqugG7BoEwQEM8bI96daTRUSkmQEWraQ78=; b=beQLFl+DJ5hRF0GpfKVXXFQ+nNjth9KjTvO1O90iuE6v78xusIyH+WLD9brHvJEI0Y WvfsRwB1mng7KKv9KqyRWEUxtUtyjXEvVRM1Jui/CEupI7TX0AjDa6MMNEZxeMtn6IVH vNDM3AsO9BuDaOi9T4J3KVaCMVd/05rCDk1nU= Received: by 10.216.134.3 with SMTP id r3mr2555935wei.40.1327624814222; Thu, 26 Jan 2012 16:40:14 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (a89-153-149-64.cpe.netcabo.pt. [89.153.149.64]) by mx.google.com with ESMTPS id fv6sm17754040wib.8.2012.01.26.16.40.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:40:13 -0800 (PST) Received: from gatekeeper.darklair.homeunix.net (localhost [127.0.0.1]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTP id B9186CF06B; Fri, 27 Jan 2012 00:40:08 +0000 (WET) Received: from altair-wifi.darklair.homeunix.net (altair-wifi.darklair.homeunix.net [10.0.0.11]) by gatekeeper.darklair.homeunix.net (Postfix) with ESMTPA id CE806CF069; Fri, 27 Jan 2012 00:40:07 +0000 (WET) From: =?iso-8859-1?Q?Ant=F3nio_Trindade?= Date: Fri, 27 Jan 2012 00:40:06 +0000 Message-Id: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org, freebsd-bugs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:09:05 -0000 Cheers. I recently updated my system to FreeBSD-9.0 and activated softupdate = journaling for a number of file systems (name /home, /var, /usr). Since then I have been experiencing kernel panics: kernel: panic: softdep_sync_buf: Unknown type jnewblk Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these kernel = panics. I have now disabled softupdates journaling in the hope that the panics = disappear. I am sorry for not providing more information about the panic, but I'll = gladly try to gather more info if instructed how to. Cumprimentos/Best regards/Mit freundlichen Gr=FC=DFen, Ant=F3nio Trindade Antonio Trindade gmail.com S=EDtios pessoais: Galeria Fotogr=E1fica: http://trindade.myphotos.cc/fotos/ Blog de fotografia: http://trindade.myphotos.cc/fotografia/ Blog de not=EDcias: http://trindade.myphotos.cc/noticiasavulsas/ Blog pessoal: http://trindade.myphotos.cc/pensamentosnoar/ From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 01:32:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 7A1B8106566C; Fri, 27 Jan 2012 01:32:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2AB2A151BF6; Fri, 27 Jan 2012 01:32:07 +0000 (UTC) Message-ID: <4F21FE96.7070805@FreeBSD.org> Date: Thu, 26 Jan 2012 17:32:06 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120119 Thunderbird/9.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ant=F3nio_Trindade?= References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> In-Reply-To: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:32:07 -0000 On 01/26/2012 16:40, António Trindade wrote: > Cheers. > > I recently updated my system to FreeBSD-9.0 and activated softupdate journaling for a number of file systems (name /home, /var, /usr). > > Since then I have been experiencing kernel panics: > kernel: panic: softdep_sync_buf: Unknown type jnewblk > > Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these kernel panics. > > I have now disabled softupdates journaling in the hope that the panics disappear. > > I am sorry for not providing more information about the panic, but I'll gladly try to gather more info if instructed how to. Make sure that dumpdev is defined in rc.conf. Usually you want to use your swap device. You should also boot into single user mode and do 'fsck -y' to make sure that the file systems are actually clean. There have been problems reported where SU+J doesn't recover fully after a crash, which leads to the kinds of instability you're reporting. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 01:54:32 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5801065678 for ; Fri, 27 Jan 2012 01:54:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id E70C38FC13 for ; Fri, 27 Jan 2012 01:54:31 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta15.emeryville.ca.mail.comcast.net with comcast id SQ4A1i00A1vN32cAFRuXyQ; Fri, 27 Jan 2012 01:54:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id SRuW1i00Z1t3BNj8iRuWle; Fri, 27 Jan 2012 01:54:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5C69D102C19; Thu, 26 Jan 2012 17:54:30 -0800 (PST) Date: Thu, 26 Jan 2012 17:54:30 -0800 From: Jeremy Chadwick To: Doug Barton Message-ID: <20120127015430.GA66235@icarus.home.lan> References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> <4F21FE96.7070805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F21FE96.7070805@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ant?nio Trindade , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 01:54:32 -0000 On Thu, Jan 26, 2012 at 05:32:06PM -0800, Doug Barton wrote: > On 01/26/2012 16:40, Ant?nio Trindade wrote: > > Cheers. > > > > I recently updated my system to FreeBSD-9.0 and activated softupdate journaling for a number of file systems (name /home, /var, /usr). > > > > Since then I have been experiencing kernel panics: > > kernel: panic: softdep_sync_buf: Unknown type jnewblk > > > > Yesterday, Jan 26th, I got 6 (six) automatic reboots due to these kernel panics. > > > > I have now disabled softupdates journaling in the hope that the panics disappear. > > > > I am sorry for not providing more information about the panic, but I'll gladly try to gather more info if instructed how to. > > Make sure that dumpdev is defined in rc.conf. Usually you want to use > your swap device. > > You should also boot into single user mode and do 'fsck -y' to make sure > that the file systems are actually clean. There have been problems > reported where SU+J doesn't recover fully after a crash, which leads to > the kinds of instability you're reporting. I'll also point out, though the OP isn't using snapshots, that it's confirmed use of snapshots on SU+J can result in a full filesystem hang. Confirmation is from Kirk McKusick (author of SU and designer of SU+J): http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013429.html Something really needs to be done about this combination of problems. Since SU+J is the default choice for all UFS filesystems on 9.0-RELEASE, the only solution I can think of is to send a massive announcement to relevant mailing lists, AND put something on the freebsd.org home page about these issues. For the snapshot issue, I believe not using SU+J (and only SU) works around the problem, so possibly that would be the best choice of recommendation at this time. I urge key members of the community and (as always) kernel developers to chime in here with advice. Something needs to be done, users need to be made aware of these problems, and so on. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 08:38:59 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E641065670; Fri, 27 Jan 2012 08:38:59 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 97D778FC12; Fri, 27 Jan 2012 08:38:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0R8cxV2053676; Fri, 27 Jan 2012 08:38:59 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0R8cxAQ053672; Fri, 27 Jan 2012 08:38:59 GMT (envelope-from jh) Date: Fri, 27 Jan 2012 08:38:59 GMT Message-Id: <201201270838.q0R8cxAQ053672@freefall.freebsd.org> To: vermaden@interia.pl, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 08:38:59 -0000 Synopsis: [ext2fs] unable to mount EXT2 filesystem State-Changed-From-To: open->closed State-Changed-By: jh State-Changed-When: Fri Jan 27 08:37:08 UTC 2012 State-Changed-Why: Not a bug. The file system type name is "ext2fs" not "ext2". Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. http://www.freebsd.org/cgi/query-pr.cgi?pr=164516 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 08:39:47 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C28106564A; Fri, 27 Jan 2012 08:39:47 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 479978FC16; Fri, 27 Jan 2012 08:39:47 +0000 (UTC) Received: from happy.home.yamagi.org (hmbg-5f77ef73.pool.mediaWays.net [95.119.239.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id B23EA1666334; Fri, 27 Jan 2012 09:39:45 +0100 (CET) Date: Fri, 27 Jan 2012 09:39:34 +0100 From: Yamagi Burmeister To: freebsd@jdc.parodius.com Message-Id: <20120127093934.ae7ca125.lists@yamagi.org> In-Reply-To: <20120127015430.GA66235@icarus.home.lan> References: <315A1E95-9064-494F-A3B8-48F1C4951624@gmail.com> <4F21FE96.7070805@FreeBSD.org> <20120127015430.GA66235@icarus.home.lan> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__27_Jan_2012_09_39_34_+0100_HXMDEpTt9rOFnD29" Cc: antonio.trindade@gmail.com, freebsd-fs@freebsd.org, dougb@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: kernel: panic: softdep_sync_buf: Unknown type jnewblk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 08:39:47 -0000 --Signature=_Fri__27_Jan_2012_09_39_34_+0100_HXMDEpTt9rOFnD29 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi :) On Thu, 26 Jan 2012 17:54:30 -0800 Jeremy Chadwick wrote: > I'll also point out, though the OP isn't using snapshots, that it's > confirmed use of snapshots on SU+J can result in a full filesystem hang. > Confirmation is from Kirk McKusick (author of SU and designer of SU+J): >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013429.html >=20 > Something really needs to be done about this combination of problems. >=20 > Since SU+J is the default choice for all UFS filesystems on 9.0-RELEASE, > the only solution I can think of is to send a massive announcement to > relevant mailing lists, AND put something on the freebsd.org home page > about these issues. The problem was analyzed but no immediate solution found. Therefor snapshots on filesystems with SU+J (but not SU alone) were disabled by Kirk McKusick in SVN r230250. The MFC to 9-STABLE has still to be done. Maybe this fix is a candidate for an errata notice / patch, distributed by freebsd-update? > For the snapshot issue, I believe not using SU+J (and only SU) works > around the problem, so possibly that would be the best choice of > recommendation at this time. Yes, snapshots with SU alone are working. > I urge key members of the community and (as always) kernel developers to > chime in here with advice. Something needs to be done, users need to be > made aware of these problems, and so on. Due to lack of time and not being the author of the rather complex code Kirk McKusick was not able to fix the problem. We're now waiting for Jeff Roberson to step up, but I was told that he is very busy and has no time too. > --=20 > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | >=20 > _______________________________________________ > 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" >=20 --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Fri__27_Jan_2012_09_39_34_+0100_HXMDEpTt9rOFnD29 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8iYtAACgkQWTjlg++8y8vsuQCgwHdjqZupfrQa9/MvR65JIyQQ r44An2u0CaN9Oh1Q2b7hf2RIjXn88+aa =qxCQ -----END PGP SIGNATURE----- --Signature=_Fri__27_Jan_2012_09_39_34_+0100_HXMDEpTt9rOFnD29-- From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 12:39:30 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B15E106566B for ; Fri, 27 Jan 2012 12:39:30 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4EB8FC15 for ; Fri, 27 Jan 2012 12:39:30 +0000 (UTC) Date: Fri, 27 Jan 2012 13:18:22 +0100 From: vermaden To: jh@FreeBSD.org X-Mailer: interia.pl/pf09 In-Reply-To: <201201270838.q0R8cxAQ053672@freefall.freebsd.org> References: <201201270838.q0R8cxAQ053672@freefall.freebsd.org> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1327666702; bh=/gTirFh5CGtun/lR5WeRxOxte7uxViuRt7ZGIvOgko0=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=c9GPuY/03yBGgfo3tFv2QaBXbi2ivNjRqCODNmYtpQj9IQFVjY+/WSU0OPsqY53MR MB343oTW334MsuAVMP6ugNuUtLwHCe/FoFj5xF6ep+tvZVQaavSBfe+v4kaIKb3Da1 0AJ9x7Ma+YBNw9XGAT6er/W/bQvuvYCxrimFnn3g= Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:39:30 -0000 True, my bad ... jh@FreeBSD.org pisze: > Synopsis: [ext2fs] unable to mount EXT2 filesystem >=20 > State-Changed-From-To: open->closed > State-Changed-By: jh > State-Changed-When: Fri Jan 27 08:37:08 UTC 2012 > State-Changed-Why:=20 > Not a bug. The file system type name is "ext2fs" not "ext2". >=20 > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D164516 ... From owner-freebsd-fs@FreeBSD.ORG Fri Jan 27 23:10:11 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86CFC106566C for ; Fri, 27 Jan 2012 23:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4BC8FC0C for ; Fri, 27 Jan 2012 23:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0RNABjr065759 for ; Fri, 27 Jan 2012 23:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0RNABvZ065758; Fri, 27 Jan 2012 23:10:11 GMT (envelope-from gnats) Date: Fri, 27 Jan 2012 23:10:11 GMT Message-Id: <201201272310.q0RNABvZ065758@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Uffe Jakobsen Cc: Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Uffe Jakobsen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:10:11 -0000 The following reply was made to PR kern/164516; it has been noted by GNATS. From: Uffe Jakobsen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem Date: Fri, 27 Jan 2012 20:49:05 +0100 > > Not a bug. The file system type name is "ext2fs" not "ext2". > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. > Instead of reporting "Operation not supported by device" Shouldn't it report unknown filesystem type ? /Uffe From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 00:47:58 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772D6106566B for ; Sat, 28 Jan 2012 00:47:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 248398FC14 for ; Sat, 28 Jan 2012 00:47:57 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id Snqt1i0011YDfWL5Fony0P; Sat, 28 Jan 2012 00:47:58 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.westchester.pa.mail.comcast.net with comcast id Sonx1i00F1t3BNj3gonxDp; Sat, 28 Jan 2012 00:47:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 10A20102C19; Fri, 27 Jan 2012 16:47:56 -0800 (PST) Date: Fri, 27 Jan 2012 16:47:56 -0800 From: Jeremy Chadwick To: Uffe Jakobsen Message-ID: <20120128004755.GA89980@icarus.home.lan> References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201272310.q0RNABvZ065758@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:47:58 -0000 On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: > The following reply was made to PR kern/164516; it has been noted by GNATS. > > From: Uffe Jakobsen > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem > Date: Fri, 27 Jan 2012 20:49:05 +0100 > > > > > Not a bug. The file system type name is "ext2fs" not "ext2". > > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. > > > > Instead of reporting "Operation not supported by device" > Shouldn't it report unknown filesystem type ? Please look through /usr/include/errno.h and let us know what error code would represent "unknown filesystem type". :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 10:32:50 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B53106566B for ; Sat, 28 Jan 2012 10:32:50 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5098FC12 for ; Sat, 28 Jan 2012 10:32:50 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2QV8d370WOrkZbOGHU= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.42] (hmbg-4d06f4c8.pool.mediaWays.net [77.6.244.200]) by smtp.strato.de (klopstock mo4) (RZmta 27.6 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id h010f5o0S8JIxR for ; Sat, 28 Jan 2012 11:32:47 +0100 (MET) Message-ID: <4F23CECD.3040905@brockmann-consult.de> Date: Sat, 28 Jan 2012 11:32:45 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> In-Reply-To: <20120128004755.GA89980@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 10:32:50 -0000 Am 28.01.2012 01:47, schrieb Jeremy Chadwick: > On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: >> The following reply was made to PR kern/164516; it has been noted by GNATS. >> >> From: Uffe Jakobsen >> To: bug-followup@FreeBSD.org >> Cc: >> Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem >> Date: Fri, 27 Jan 2012 20:49:05 +0100 >> >> > >> > Not a bug. The file system type name is "ext2fs" not "ext2". >> > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. >> > >> >> Instead of reporting "Operation not supported by device" >> Shouldn't it report unknown filesystem type ? > Please look through /usr/include/errno.h and let us know what error code > would represent "unknown filesystem type". :-) > #define EINVAL 22 /* Invalid argument */ From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 16:34:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05059106566C; Sat, 28 Jan 2012 16:34:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6C58FC08; Sat, 28 Jan 2012 16:34:19 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so3312855wib.13 for ; Sat, 28 Jan 2012 08:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B0Uq5I1mYaaDZ9rx5TMCGEzSJ3duNVCjxo12goClvtA=; b=tamz16P/toS/LtBK2qJiF4e7oTnjnqggp+Xv7k3YvtNEZGsQ3mLjrfn/0ng8XBrugs PlxO6tcBKAWbhpDhkIzaHHVeNm6bkGps/fTVKPnP8R7S1+VieP16am5XukUnbCt8b0zc WzWjEm3RBPFukqevJx9bFdfkJKJOloKXne46k= MIME-Version: 1.0 Received: by 10.180.109.77 with SMTP id hq13mr18401922wib.7.1327766591358; Sat, 28 Jan 2012 08:03:11 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Sat, 28 Jan 2012 08:03:11 -0800 (PST) In-Reply-To: References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Sat, 28 Jan 2012 17:03:11 +0100 X-Google-Sender-Auth: A3bGQKxC_f9Bc9MRYADpTfYRpZE Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 16:34:21 -0000 2011/11/8 Attilio Rao : > 2011/11/8 Attilio Rao : >> Author: attilio >> Date: Tue Nov =C2=A08 10:18:07 2011 >> New Revision: 227333 >> URL: http://svn.freebsd.org/changeset/base/227333 >> >> Log: >> =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default= on >> =C2=A0all the architectures. >> =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the >> =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. >> >> =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems >> =C2=A0from the tree. > > This is just a gentle reminder in order to point you further to the > "official" page: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > and encourage once again people in adopting a dying FS if it really > matters to them. > So far, unfortunately, I didn't see a lot of activity in this area but > I hope that this would change soon. This is a further reminder. So far I've not seen any improvement over the locking of any of our 'legacy' filesystems. I remind you that this may be meaning disconnecting them from the tree on 1st Semptember 2012, accordingly with this road-map: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS In one month I'm going to disable VFS_ALLOW_NONMPSAFE by defaults in order to see how well the users do with this option down. At the present times this means that from 1st March you won't be able to mount smbfs or ntfs volumes, for example. Please step up and fix your favourite filesystem. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 22:13:52 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F328B106566B for ; Sat, 28 Jan 2012 22:13:51 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 2EB8F8FC16 for ; Sat, 28 Jan 2012 22:13:50 +0000 (UTC) Received: (qmail 76964 invoked by uid 1004); 28 Jan 2012 21:47:31 -0000 Message-ID: <4F246CA9.30803@uffe.org> Date: Sat, 28 Jan 2012 22:46:17 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> In-Reply-To: <20120128004755.GA89980@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 22:13:52 -0000 On 2012-01-28 01:47, Jeremy Chadwick wrote: > On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: >> The following reply was made to PR kern/164516; it has been noted by GNATS. >> >> From: Uffe Jakobsen >> To: bug-followup@FreeBSD.org >> Cc: >> Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem >> Date: Fri, 27 Jan 2012 20:49:05 +0100 >> >> > >> > Not a bug. The file system type name is "ext2fs" not "ext2". >> > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. >> > >> >> Instead of reporting "Operation not supported by device" >> Shouldn't it report unknown filesystem type ? > > Please look through /usr/include/errno.h and let us know what error code > would represent "unknown filesystem type". :-) > There are plenty of other places in the mount src where we exit without a specific error code. Question is if there exists a scenario where the requested filesystem type would/could not be found by getvfsbyname() ? I've met this problem myself a number of times - and even in this case I did not spot the spelling error right away ('ext2fs' and not 'ext2'). The returned error 'Operation not supported by device' - atleast to me - indicates that the mount process got much further before running into some kind of problem. The times when I've met this error I've begun inspecting mount options etc before realizing that the fstype had a typo. /Uffe From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 23:01:01 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8351065674 for ; Sat, 28 Jan 2012 23:01:01 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54B418FC0A for ; Sat, 28 Jan 2012 23:01:01 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id o4so6115252iae.13 for ; Sat, 28 Jan 2012 15:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Goqvmvkb8u/H+4sFbB8JWoHhCZwOtPlPB/XTCBPRmw=; b=o1XpOv57pE97JTd6/05WEZyJzYgk6lLstC6wKhT92beQGsvQbfSD7xj1/vDclmncuB /brzYKFuY0GqWGPjjxCh26gtX2njyhXq7iPtuta+R1RI7o2ru+98QU05ay3srTvOJlGe zCI49iHVDkvORkPdnPgqAQ/bK+6Fz85H6t6h4= MIME-Version: 1.0 Received: by 10.50.236.73 with SMTP id us9mr12549399igc.16.1327789879986; Sat, 28 Jan 2012 14:31:19 -0800 (PST) Received: by 10.231.183.21 with HTTP; Sat, 28 Jan 2012 14:31:19 -0800 (PST) Received: by 10.231.183.21 with HTTP; Sat, 28 Jan 2012 14:31:19 -0800 (PST) In-Reply-To: <4F246CA9.30803@uffe.org> References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> <4F246CA9.30803@uffe.org> Date: Sat, 28 Jan 2012 22:31:19 +0000 Message-ID: From: Chris Rees To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 23:01:01 -0000 On 28 Jan 2012 22:14, "Uffe Jakobsen" wrote: > > > > On 2012-01-28 01:47, Jeremy Chadwick wrote: >> >> On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: >>> >>> The following reply was made to PR kern/164516; it has been noted by GNATS. >>> >>> From: Uffe Jakobsen >>> To: bug-followup@FreeBSD.org >>> Cc: >>> Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem >>> Date: Fri, 27 Jan 2012 20:49:05 +0100 >>> >>> > >>> > Not a bug. The file system type name is "ext2fs" not "ext2". >>> > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. >>> > >>> >>> Instead of reporting "Operation not supported by device" >>> Shouldn't it report unknown filesystem type ? >> >> >> Please look through /usr/include/errno.h and let us know what error code >> would represent "unknown filesystem type". :-) >> > > There are plenty of other places in the mount src where we exit without a specific error code. Question is if there exists a scenario where the requested filesystem type would/could not be found by getvfsbyname() ? > > I've met this problem myself a number of times - and even in this case I did not spot the spelling error right away ('ext2fs' and not 'ext2'). > > The returned error 'Operation not supported by device' - atleast to me - indicates that the mount process got much further before running into some kind of problem. The times when I've met this error I've begun inspecting mount options etc before realizing that the fstype had a typo. > Normally when an error comes up I check the manpage. Chris From owner-freebsd-fs@FreeBSD.ORG Sat Jan 28 23:57:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE63106566C for ; Sat, 28 Jan 2012 23:57:19 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with SMTP id 0D8AD8FC12 for ; Sat, 28 Jan 2012 23:57:18 +0000 (UTC) Received: (qmail 79874 invoked by uid 1004); 28 Jan 2012 23:57:40 -0000 Message-ID: <4F248B44.1090304@uffe.org> Date: Sun, 29 Jan 2012 00:56:52 +0100 From: Uffe Jakobsen X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201201272310.q0RNABvZ065758@freefall.freebsd.org> <20120128004755.GA89980@icarus.home.lan> <4F246CA9.30803@uffe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 23:57:19 -0000 On 2012-01-28 23:31, Chris Rees wrote: > > On 28 Jan 2012 22:14, "Uffe Jakobsen" > wrote: > > > > > > > > On 2012-01-28 01:47, Jeremy Chadwick wrote: > >> > >> On Fri, Jan 27, 2012 at 11:10:11PM +0000, Uffe Jakobsen wrote: > >>> > >>> The following reply was made to PR kern/164516; it has been noted > by GNATS. > >>> > >>> From: Uffe Jakobsen> > >>> To: bug-followup@FreeBSD.org > >>> Cc: > >>> Subject: Re: kern/164516: [ext2fs] unable to mount EXT2 filesystem > >>> Date: Fri, 27 Jan 2012 20:49:05 +0100 > >>> > >>> > > >>> > Not a bug. The file system type name is "ext2fs" not "ext2". > >>> > Use "mount -t ext2fs /dev/md0 /mnt/tmp0" instead. > >>> > > >>> > >>> Instead of reporting "Operation not supported by device" > >>> Shouldn't it report unknown filesystem type ? > >> > >> > >> Please look through /usr/include/errno.h and let us know what error code > >> would represent "unknown filesystem type". :-) > >> > > > > There are plenty of other places in the mount src where we exit > without a specific error code. Question is if there exists a scenario > where the requested filesystem type would/could not be found by > getvfsbyname() ? > > > > I've met this problem myself a number of times - and even in this > case I did not spot the spelling error right away ('ext2fs' and not 'ext2'). > > > > The returned error 'Operation not supported by device' - atleast to > me - indicates that the mount process got much further before running > into some kind of problem. The times when I've met this error I've begun > inspecting mount options etc before realizing that the fstype had a typo. > > > > Normally when an error comes up I check the manpage. Manpage for mount does not at all mention any error conditions. You'll have to know the inner workings of mount in order to know that in certain cases everything is thrown into nmount() and any error that comes up would come directly from nmount() Anyway - would you accept a patch that checked the fstype using getvfsbyname() before calling nmount() ? /Uffe