From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 08:12: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 5D536106564A for ; Sun, 12 Feb 2012 08:12:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id C0BC58FC08 for ; Sun, 12 Feb 2012 08:12:15 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1C8C7eR088242 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 12 Feb 2012 08:12:08 GMT (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1C8C7eR088242 Authentication-Results: smtp.infracaninophile.co.uk/q1C8C7eR088242; dkim=none (no signature); dkim-adsp=none Message-ID: <4F377457.4080807@FreeBSD.org> Date: Sun, 12 Feb 2012 08:12:07 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig96A94CE0E99749F3FE0846F4" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: ZFS Snapshot problems 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, 12 Feb 2012 08:12:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig96A94CE0E99749F3FE0846F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since about a week ago I've been intermittently getting a problem where I cannot access a snapshot after creating it: lucid-nonsense:~:# zfs snapshot zroot@test lucid-nonsense:~:# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zroot@test 67K - 8.36G - lucid-nonsense:~:# cd /.zfs/snapshot/test /.zfs/snapshot/test: Not a directory. This is playing silly buggers with my backups. Apart from that, the system is behaving normally. Nothing in syslog, nothing in dmesg. The only way I've found so far to clear the problem is to reboot, but then the problem seems to recur within a few days. 'zpool status' says everything is fine. 'zpool scrub' has no effect. lucid-nonsense:~:# uname -a FreeBSD lucid-nonsense.infracaninophile.co.uk 8.2-STABLE FreeBSD 8.2-STABLE #2 r231394: Fri Feb 10 20:35:13 GMT 2012 root@lucid-nonsense.infracaninophile.co.uk:/usr/obj/usr/src/sys/LUCID-NON= SENSE amd64 lucid-nonsense:~:# zpool upgrade This system is currently running ZFS pool version 28. All pools are formatted using this version. lucid-nonsense:~:# zfs upgrade This system is currently running ZFS filesystem version 5. All filesystems are formatted with the current version. Any clues about how I can debug this, and hopefully prevent it happening?= Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig96A94CE0E99749F3FE0846F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk83dFcACgkQ8Mjk52CukIw1IgCfUkqvyKjPv4KV1W+uhUQ63DKr xuoAniR/zrhn6qIUzzQ/gRTrD9SEE2/f =nooy -----END PGP SIGNATURE----- --------------enig96A94CE0E99749F3FE0846F4-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 08:40: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 648701065672 for ; Sun, 12 Feb 2012 08:40:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3A78FC08 for ; Sun, 12 Feb 2012 08:40:53 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta13.emeryville.ca.mail.comcast.net with comcast id YwfU1i0050b6N64ADwgtuK; Sun, 12 Feb 2012 08:40:53 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id Ywgt1i00F1t3BNj8PwgtAh; Sun, 12 Feb 2012 08:40:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0168E102C1E; Sun, 12 Feb 2012 00:40:52 -0800 (PST) Date: Sun, 12 Feb 2012 00:40:52 -0800 From: Jeremy Chadwick To: Matthew Seaman Message-ID: <20120212084052.GA43095@icarus.home.lan> References: <4F377457.4080807@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F377457.4080807@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 08:40:54 -0000 On Sun, Feb 12, 2012 at 08:12:07AM +0000, Matthew Seaman wrote: > > Since about a week ago I've been intermittently getting a problem where > I cannot access a snapshot after creating it: > > lucid-nonsense:~:# zfs snapshot zroot@test > lucid-nonsense:~:# zfs list -t snapshot > NAME USED AVAIL REFER MOUNTPOINT > zroot@test 67K - 8.36G - > lucid-nonsense:~:# cd /.zfs/snapshot/test > /.zfs/snapshot/test: Not a directory. > > This is playing silly buggers with my backups. Apart from that, the > system is behaving normally. Nothing in syslog, nothing in dmesg. > The only way I've found so far to clear the problem is to reboot, but > then the problem seems to recur within a few days. > > 'zpool status' says everything is fine. 'zpool scrub' has no effect. > > lucid-nonsense:~:# uname -a > FreeBSD lucid-nonsense.infracaninophile.co.uk 8.2-STABLE FreeBSD > 8.2-STABLE #2 r231394: Fri Feb 10 20:35:13 GMT 2012 > root@lucid-nonsense.infracaninophile.co.uk:/usr/obj/usr/src/sys/LUCID-NONSENSE > amd64 > lucid-nonsense:~:# zpool upgrade > This system is currently running ZFS pool version 28. > > All pools are formatted using this version. > lucid-nonsense:~:# zfs upgrade > This system is currently running ZFS filesystem version 5. > > All filesystems are formatted with the current version. > > Any clues about how I can debug this, and hopefully prevent it happening? Could this be related (somehow) to the below commit? I'm doubting it, but... http://www.freebsd.org/cgi/cvsweb.cgi/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c I realise you're not destroying a snapshot, but I wonder if an old snapshot which was previously destroyed wasn't really destroyed, thus resulting in the behaviour you see. As stated, I doubt it, but I imagine it depends on how this issue manifests itself. -- | 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 Sun Feb 12 09:43:44 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 8FEDF106564A for ; Sun, 12 Feb 2012 09:43:44 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id F1AC38FC0C for ; Sun, 12 Feb 2012 09:43:43 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1C9hcCW091535 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 12 Feb 2012 09:43:38 GMT (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1C9hcCW091535 Authentication-Results: smtp.infracaninophile.co.uk/q1C9hcCW091535; dkim=none (no signature); dkim-adsp=none Message-ID: <4F3789C1.9000903@FreeBSD.org> Date: Sun, 12 Feb 2012 09:43:29 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> In-Reply-To: <20120212084052.GA43095@icarus.home.lan> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD11B1E39C603561EC070CFF" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 09:43:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD11B1E39C603561EC070CFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/02/2012 08:40, Jeremy Chadwick wrote: > Could this be related (somehow) to the below commit? I'm doubting it, > but... >=20 > http://www.freebsd.org/cgi/cvsweb.cgi/src/cddl/contrib/opensolaris/cmd/= zfs/zfs_main.c No -- I was seeing the problem on a system compiled before then. This didn't start in close proximity to doing an upgrade. There was at least a two week delay. Now, I did try updating to see if that fixed the trouble, but no joy. > I realise you're not destroying a snapshot, but I wonder if an old > snapshot which was previously destroyed wasn't really destroyed, thus > resulting in the behaviour you see. As stated, I doubt it, but I > imagine it depends on how this issue manifests itself. Actually, I do destroy the snapshots, which works just fine. I tend to have either 0 or 1 snapshots at any one time. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigAD11B1E39C603561EC070CFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk83ickACgkQ8Mjk52CukIx7fACgh+s/LnJ23apqBq8zKGNh5g1s i+IAnixHTE3VKWbMwcfBWFv6KkPmyCOn =JhkE -----END PGP SIGNATURE----- --------------enigAD11B1E39C603561EC070CFF-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 11:56: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 8093A106564A for ; Sun, 12 Feb 2012 11:56:29 +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 DEB9C8FC19 for ; Sun, 12 Feb 2012 11:56:28 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23mtcWl82a4= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.39] (hmbg-5f761430.pool.mediaWays.net [95.118.20.48]) by smtp.strato.de (fruni mo21) (RZmta 27.6 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id 603b2fo1CBgKmj for ; Sun, 12 Feb 2012 12:56:26 +0100 (MET) Message-ID: <4F37A8E7.7060102@brockmann-consult.de> Date: Sun, 12 Feb 2012 12:56:23 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> In-Reply-To: <4F3789C1.9000903@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 11:56:29 -0000 I had a problem where I could not delete, rename, send, etc. a snapshot... , (possibly caused by a kernel panic during a zfs replication). Maybe yours is related. I did not try viewing the contents of my snapshot. If it is related, the solution is: zdb -d poolname | grep % Expect the command to take long, and output should include all your clones you made, plus some "Input/output errors" for some others. Pay attention to the ones with errors, and then delete those, then try to access your snapshot again. Am 12.02.2012 10:43, schrieb Matthew Seaman: > On 12/02/2012 08:40, Jeremy Chadwick wrote: >> Could this be related (somehow) to the below commit? I'm doubting it, >> but... >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c > No -- I was seeing the problem on a system compiled before then. This > didn't start in close proximity to doing an upgrade. There was at least > a two week delay. Now, I did try updating to see if that fixed the > trouble, but no joy. > >> I realise you're not destroying a snapshot, but I wonder if an old >> snapshot which was previously destroyed wasn't really destroyed, thus >> resulting in the behaviour you see. As stated, I doubt it, but I >> imagine it depends on how this issue manifests itself. > Actually, I do destroy the snapshots, which works just fine. I tend to > have either 0 or 1 snapshots at any one time. > > Cheers > > Matthew > From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 12:36:59 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 8FDAE106564A for ; Sun, 12 Feb 2012 12:36:59 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 13A0A8FC0A for ; Sun, 12 Feb 2012 12:36:58 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1CCaoFm069083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 12 Feb 2012 12:36:50 GMT (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1CCaoFm069083 Authentication-Results: smtp.infracaninophile.co.uk/q1CCaoFm069083; dkim=none (no signature); dkim-adsp=none Message-ID: <4F37B25A.10002@FreeBSD.org> Date: Sun, 12 Feb 2012 12:36:42 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> In-Reply-To: <4F37A8E7.7060102@brockmann-consult.de> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig76F55B07FC6F80EB7C1B7234" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 12:36:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76F55B07FC6F80EB7C1B7234 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/02/2012 11:56, Peter Maloney wrote: > I had a problem where I could not delete, rename, send, etc. a > snapshot... , (possibly caused by a kernel panic during a zfs > replication). Maybe yours is related. I did not try viewing the content= s > of my snapshot. >=20 > If it is related, the solution is: >=20 > zdb -d poolname | grep % >=20 > Expect the command to take long, and output should include all your > clones you made, plus some "Input/output errors" for some others. Pay > attention to the ones with errors, and then delete those, then try to > access your snapshot again. Interesting. I guess this is not the expected output? lucid-nonsense:/usr/home/matthew:# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zroot 448G 42.9G 405G 9% 1.20x ONLINE - lucid-nonsense:/usr/home/matthew:# zdb -d zroot | grep % zdb: can't open 'zroot': No such file or directory Running truss(1) on zdb shows: open("/dev/gpt/disk0",O_RDONLY,00) ERR#2 'No such file or directory' open("/dev/gpt/disk2",O_RDONLY,00) ERR#2 'No such file or directory' which is true -- /dev/gpt is empty. But disk0 and disk1 should show up: lucid-nonsense:/usr/home/matthew:# gpart show -l /dev/ad0 =3D> 34 976773101 ad0 GPT (465G) 34 128 1 (null) (64k) 162 33554432 2 swap0 (16G) 33554594 943218541 3 disk0 (449G) lucid-nonsense:/usr/home/matthew:# gpart show -l /dev/ad2 =3D> 34 976773101 ad2 GPT (465G) 34 128 1 (null) (64k) 162 33554432 2 swap2 (16G) 33554594 943218541 3 disk2 (449G) =2E.. and come to think of it: the disk0 and disk2 labels used to show up= here too: lucid-nonsense:/usr/home/matthew:# zpool status zroot pool: zroot state: ONLINE scan: scrub repaired 0 in 3h35m with 0 errors on Sun Feb 12 11:14:10 20= 12 config: NAME STATE READ WRITE CKS= UM zroot ONLINE 0 0 = 0 mirror-0 ONLINE 0 0 = 0 gptid/848287e9-5f8e-11df-808e-e0cb4e266481 ONLINE 0 0 = 0 gptid/a6d0bec4-5f8e-11df-808e-e0cb4e266481 ONLINE 0 0 = 0 errors: No known data errors Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig76F55B07FC6F80EB7C1B7234 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk83smIACgkQ8Mjk52CukIzv5wCgg5i2sIYZkgb5cdogo8jqLAla JIAAn3qC18Iyf1wBl5y++A/O+tkap2dz =yVae -----END PGP SIGNATURE----- --------------enig76F55B07FC6F80EB7C1B7234-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 13:10: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 CDC5E106564A for ; Sun, 12 Feb 2012 13:10:49 +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 36C818FC0A for ; Sun, 12 Feb 2012 13:10:49 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23mtcWl82a4= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.39] (hmbg-5f761430.pool.mediaWays.net [95.118.20.48]) by smtp.strato.de (cohen mo53) (RZmta 27.6 DYNA|AUTH) with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 20030ao1CCGg28 for ; Sun, 12 Feb 2012 14:10:34 +0100 (MET) Message-ID: <4F37BA49.50700@brockmann-consult.de> Date: Sun, 12 Feb 2012 14:10:33 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> In-Reply-To: <4F37B25A.10002@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 13:10:50 -0000 Am 12.02.2012 13:36, schrieb Matthew Seaman: > On 12/02/2012 11:56, Peter Maloney wrote: >> I had a problem where I could not delete, rename, send, etc. a >> snapshot... , (possibly caused by a kernel panic during a zfs >> replication). Maybe yours is related. I did not try viewing the contents >> of my snapshot. >> >> If it is related, the solution is: >> >> zdb -d poolname | grep % >> >> Expect the command to take long, and output should include all your >> clones you made, plus some "Input/output errors" for some others. Pay >> attention to the ones with errors, and then delete those, then try to >> access your snapshot again. > Interesting. I guess this is not the expected output? > > lucid-nonsense:/usr/home/matthew:# zpool list > NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT > zroot 448G 42.9G 405G 9% 1.20x ONLINE - > lucid-nonsense:/usr/home/matthew:# zdb -d zroot | grep % > zdb: can't open 'zroot': No such file or directory > > Running truss(1) on zdb shows: > > open("/dev/gpt/disk0",O_RDONLY,00) ERR#2 'No such file or directory' > open("/dev/gpt/disk2",O_RDONLY,00) ERR#2 'No such file or directory' > > which is true -- /dev/gpt is empty. I've had the same problem also... it is very annoying. It seems that after the first time you import a pool using another boot system (USB stick, DVD, etc.), it breaks the gpt label usage and uses gptid for everything after that. Before this, you have gpt and gptid, but after this, you only have gptid. You could try adding: kern.geom.label.gptid.enable=0 to /boot/loader.conf and reboot, which will then show the /dev/gpt/... labels everywhere again, and will make the /dev/gptid directory empty/disappear. (but you get gptid labels again if you disable that option and reboot again) I don't know what side effects that change has though. You can usually assume that ZFS will just figure out the pool regardless of labels (because it uses its own label metadata; see zdb output to see the other id), but apparently your case is something special, getting actual errors instead of only wrong names. In my experience, there are no strange side effects. But maybe there would be if you inserted some other disks with the same gpt/ labels. And another long shot idea: you could also try booting off of a DVD and importing using "-o cachefile=.... -o altroot=..." and then copying the cachefile over your current one (/boot/zfs/zpool.cache I think) to see if it then has the right names when you reboot again. And again, I don't know if your data is at risk using any of my suggestions. I always play around with things like that in test virtual machines first. > But disk0 and disk1 should show up: > > lucid-nonsense:/usr/home/matthew:# gpart show -l /dev/ad0 > => 34 976773101 ad0 GPT (465G) > 34 128 1 (null) (64k) > 162 33554432 2 swap0 (16G) > 33554594 943218541 3 disk0 (449G) > > lucid-nonsense:/usr/home/matthew:# gpart show -l /dev/ad2 > => 34 976773101 ad2 GPT (465G) > 34 128 1 (null) (64k) > 162 33554432 2 swap2 (16G) > 33554594 943218541 3 disk2 (449G) > > ... and come to think of it: the disk0 and disk2 labels used to show up > here too: > > lucid-nonsense:/usr/home/matthew:# zpool status zroot > pool: zroot > state: ONLINE > scan: scrub repaired 0 in 3h35m with 0 errors on Sun Feb 12 11:14:10 2012 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gptid/848287e9-5f8e-11df-808e-e0cb4e266481 ONLINE 0 0 0 > gptid/a6d0bec4-5f8e-11df-808e-e0cb4e266481 ONLINE 0 0 0 > > errors: No known data errors > > Cheers, > > Matthew > From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 13:57: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 641C91065675 for ; Sun, 12 Feb 2012 13:57:15 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id BD2E48FC16 for ; Sun, 12 Feb 2012 13:57:14 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1CDv6QG065925 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 12 Feb 2012 13:57:06 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1CDv6QG065925 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1329055026; bh=y4rFxRkKmUNNEz45jZq67/17LVNo1l+hNuUO6WWG0CU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=ZAwUvuYXDR5o6MFPrG3EoefEToKObKk33wez0mvL4o4kifI+XSazyY7Ap3sK8A0C6 X4ZhwuuUXTDUWMkRnxqRUgztF6uEGINmljySRNfZEhh6bWcfYgyZB7Fhp5QksFbC1c AyDJf3LDkzCAW8wudVGCF12vUOlJ4MB16iRBmL4o= Message-ID: <4F37C52A.2030803@infracaninophile.co.uk> Date: Sun, 12 Feb 2012 13:56:58 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> <4F37BA49.50700@brockmann-consult.de> In-Reply-To: <4F37BA49.50700@brockmann-consult.de> X-Enigmail-Version: 1.3.5 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig56BF8A60871CD11D67F14A4C" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS Snapshot problems 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, 12 Feb 2012 13:57:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig56BF8A60871CD11D67F14A4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/02/2012 13:10, Peter Maloney wrote: > I don't know what side effects that change has though. You can usually > assume that ZFS will just figure out the pool regardless of labels > (because it uses its own label metadata; see zdb output to see the othe= r > id), but apparently your case is something special, getting actual > errors instead of only wrong names. Yes. This is most perplexing -- it's such a specific effect. The gpt thing may well be a red herring. It is odd though that zdb somehow discovers the gpart labels through reading zpool.cache, but zpool(1) uses the gptids instead. > In my experience, there are no strange side effects. But maybe there > would be if you inserted some other disks with the same gpt/ labels. That's not going to be a problem in my environment. It's not physically possible to insert more disks[*], and I'd have to power off to swap out one of the existing ones. > And another long shot idea: you could also try booting off of a DVD and= > importing using "-o cachefile=3D.... -o altroot=3D..." and then copying= the > cachefile over your current one (/boot/zfs/zpool.cache I think) to see > if it then has the right names when you reboot again. >=20 >=20 > And again, I don't know if your data is at risk using any of my > suggestions. I always play around with things like that in test virtual= > machines first. Hmmm... as the one and only operational effect of this problem I've identified is to prevent my getting good backups, that's quite the catch-22 there. Definitely time to go virtual, lest the cure have worse effects than the disease. Thanks, Matthew [*] Well, unless I created a zfs on a usb stick, but I've no reason to do that. --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig56BF8A60871CD11D67F14A4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk83xTEACgkQ8Mjk52CukIwy1ACdHjpTn4gNYlOQz2eUvFmcQzrg RRYAn2XCZI0ERfKEhNRMt4Y3leAGhVpR =KlJ9 -----END PGP SIGNATURE----- --------------enig56BF8A60871CD11D67F14A4C-- From owner-freebsd-fs@FreeBSD.ORG Sun Feb 12 19:00: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 0BEC3106564A for ; Sun, 12 Feb 2012 19:00:16 +0000 (UTC) (envelope-from cdorbell@free.fr) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCE98FC16 for ; Sun, 12 Feb 2012 19:00:14 +0000 (UTC) Received: from [192.168.0.249] (unknown [78.234.248.38]) by smtp1-g21.free.fr (Postfix) with ESMTP id CAFF794019B for ; Sun, 12 Feb 2012 20:00:09 +0100 (CET) Message-ID: <4F380CCE.5080605@free.fr> Date: Sun, 12 Feb 2012 20:02:38 +0100 From: Charles Orbello 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: <4F2FF72B.6000509@pean.org> <20120206162206.GA541@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: HPC and zfs. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cdorbell@free.fr List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 19:00:17 -0000 Hi Michael what is the impact on the latency read and latency write to use a distributed system ? Regards Charles Le 06/02/2012 17:49, Michael Aronsen a écrit : > Hi, > > On Feb 6, 2012, at 17:22 , Jeremy Chadwick wrote: >> - What single motherboard supports up to 192GB of RAM > Get an HP DL580/585 - they support 2TB/1TB RAM. > >> - How you plan on getting roughly 410 hard disks (or 422 assuming >> an additional 12 SSDs) hooked up to a single machine > Use LSI SAS92XX 4 (x4) port external controllers, and SuperMicro SC847E26-RJBOD1 disk shelves. > Each disk shelf needs 2 ports on the LSI controller, which means you get 90 disks per LSI card. > The DL580/585's have 11 PCIe slots, so you'd end up with 990 disks per server using this setup. > >> If you are considering investing the time and especially money (the cost >> here is almost unfathomable, IMO) into this, I strongly recommend you >> consider an actual hardware filer (e.g. NetApp). Your performance and >> reliability will be much greater, plus you will get overall better >> support from NetApp in the case something goes wrong. In the case you >> run into problems with FreeBSD (and I can assure you in this kind of >> setup you will) with this kind of extensive setup, you will be at the >> mercy of developers' time/schedules with absolutely no guarantee that >> your problem will be solved. You definitely want a support contract. >> Thus, go NetApp. > We have NetApp's at our University for home storage, but I would struggle to recommend them for HPC storage. > > A dedicated HPC filesystem such as Lustre or FhGFS (http://www.fhgfs.com/cms/) will almost certainly give you better performance as they're purpose made. > > We use FhGFS in a rather small setup (44 TB usable space and ~200 HPC nodes), but they do have installations with 700TB+. > The setup consists of 2 metadata nodes and 4 storage nodes, all supermicro servers with 24 WD Velociraptor 600 GB 10K RPM disks. > This setup gives us 4.8GB/sec write and 4.3GB/sec read speeds, all for a lot less than a comparable NetApp solution (we paid around €30.000). > It now has support for mirroring on a per folder level for resilience. > > Currently it only runs on Linux but i'm considering a FreeBSD port to get ZFS for volume management and now that OFED is in FreeBSD 9, Infinifband is possible. > > I'd highly recommend a parallel filesystem, unfortunately not many, if any, are available on FreeBSD at this time. > > Regards, > Michael > > _______________________________________________ > 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 Mon Feb 13 09:00:34 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 2B55A106564A for ; Mon, 13 Feb 2012 09:00:34 +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 192948FC18 for ; Mon, 13 Feb 2012 09:00:34 +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 q1D90XTP060565 for ; Mon, 13 Feb 2012 09:00:33 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1D90XML060563; Mon, 13 Feb 2012 09:00:33 GMT (envelope-from gnats) Date: Mon, 13 Feb 2012 09:00:33 GMT Message-Id: <201202130900.q1D90XML060563@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Maloney Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Maloney List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 09:00:34 -0000 The following reply was made to PR kern/161968; it has been noted by GNATS. From: Peter Maloney To: bug-followup@FreeBSD.org, peter.maloney@brockmann-consult.de Cc: Subject: Re: kern/161968: [zfs] [hang] renaming snapshot with -r including a zvol snapshot causes total ZFS freeze/lockup Date: Mon, 13 Feb 2012 09:56:54 +0100 correction, the newly tested version was csup'd on 2012-02-04 (February, not Janurary) -- -------------------------------------------- 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 Mon Feb 13 11:07: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 E6207106566C for ; Mon, 13 Feb 2012 11:07:50 +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 D343E8FC1B for ; Mon, 13 Feb 2012 11:07:50 +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 q1DB7oLh090861 for ; Mon, 13 Feb 2012 11:07:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1DB7n9R090857 for freebsd-fs@FreeBSD.org; Mon, 13 Feb 2012 11:07:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Feb 2012 11:07:49 GMT Message-Id: <201202131107.q1DB7n9R090857@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, 13 Feb 2012 11:07:51 -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/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164462 fs [nfs] NFSv4 mounting fails to mount; asks for stronger 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/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/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/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 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 261 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 16:18:13 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 91526106566B for ; Mon, 13 Feb 2012 16:18:13 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9308FC14 for ; Mon, 13 Feb 2012 16:18:12 +0000 (UTC) Received: by ghbg15 with SMTP id g15so3133498ghb.13 for ; Mon, 13 Feb 2012 08:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=GuGCCon2EXlWczzIPiQsBTH39q4ElJxOY+/wJVnSR1I=; b=qGauxOFd5j2TdKABoULCfGA+P2wbs83dbLxhX8V1QOkCPBDqfp2lTTVrrgfEsYSdg1 EVY/4Z7ggo1WH+3u+UCP6KRuCV+LlgywWgdQIqcljMgHzSyW/7iLV2yiSDw8YaU+u/9X rcW07gY7RoY2IkLRHOiA1FaCSW1K0xUyYvZAI= Received: by 10.50.34.202 with SMTP id b10mr28204533igj.2.1329148545481; Mon, 13 Feb 2012 07:55:45 -0800 (PST) Received: from static177.us.your.org (static177.us.your.org. [204.9.55.177]) by mx.google.com with ESMTPS id en8sm8929719igc.5.2012.02.13.07.55.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 07:55:44 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 09:55:36 -0600 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQlm5ha3OgxLIwU3qFkJ+WntX81Oiu40fKFE31fWJ4KNtTftEBmd0KtYeY2uFVHjAwlLA0Ch Subject: Simultaneous read-only snapshot 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: Mon, 13 Feb 2012 16:18:13 -0000 It's now possible/somewhat common for the ability to have two systems = can see the same disk(s) at the same time (through iSCSI or storage = systems that support dual controllers, etc).=20 Suppose system A has a filesystem mounted RW, and takes a snapshot. Can = system B access that snapshot via a read only mount, while system A = continues to read/write to that filesystem? Or more basically, is = everything needed to read a snapshot stable/unchanging enough that a = second system can read from it while the filesystem is still being = updated? -- Kevin From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 16:45: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 F3D8F1065672 for ; Mon, 13 Feb 2012 16:45:25 +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 4AB548FC18 for ; Mon, 13 Feb 2012 16:45:24 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA25536; Mon, 13 Feb 2012 18:45:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F393E20.3070308@FreeBSD.org> Date: Mon, 13 Feb 2012 18:45:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Kevin Day References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Simultaneous read-only snapshot 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: Mon, 13 Feb 2012 16:45:26 -0000 on 13/02/2012 17:55 Kevin Day said the following: > > It's now possible/somewhat common for the ability to have two systems can see > the same disk(s) at the same time (through iSCSI or storage systems that > support dual controllers, etc). > > Suppose system A has a filesystem mounted RW, and takes a snapshot. Can system > B access that snapshot via a read only mount, while system A continues to > read/write to that filesystem? Or more basically, is everything needed to read > a snapshot stable/unchanging enough that a second system can read from it while > the filesystem is still being updated? Generally, no. The RO fs typically still caches a lot of information (metadata) in RAM, the cached data may become stale and inconsistent. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 18:18: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 C0AA4106566B for ; Mon, 13 Feb 2012 18:18:24 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 94B338FC0C for ; Mon, 13 Feb 2012 18:18:24 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rx0TY-0005e8-A2; Mon, 13 Feb 2012 13:18:08 -0500 Date: Mon, 13 Feb 2012 13:18:08 -0500 From: Gary Palmer To: Kevin Day Message-ID: <20120213181808.GC78733@in-addr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org Subject: Re: Simultaneous read-only snapshot 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: Mon, 13 Feb 2012 18:18:24 -0000 On Mon, Feb 13, 2012 at 09:55:36AM -0600, Kevin Day wrote: > > It's now possible/somewhat common for the ability to have two systems can see the same disk(s) at the same time (through iSCSI or storage systems that support dual controllers, etc). > > Suppose system A has a filesystem mounted RW, and takes a snapshot. Can system B access that snapshot via a read only mount, while system A continues to read/write to that filesystem? Or more basically, is everything needed to read a snapshot stable/unchanging enough that a second system can read from it while the filesystem is still being updated? If the snapshot is taken on the filesystem, take the snapshot, mount it on server 1 and export it over NFS (or other network filesystem of your choice) to server 2. Anything else will likely result in undefined behaviour. I don't think any FS guarantees that metadata related to files in a snapshot will not change as the original read/write FS changes. If nothing else, most (all?) times you have to have the original FS mounted to get to the snapshot, which leads to obvious data consistency problems given the original FS is read/write on server1. Alternatively, do a snapshot on the shared storage rather than at the filesystem layer. e.g. export a LUN via FC/iSCSI from a NetApp to server 1, take a snapshot on the volume that contains server 1 and through some commands that escape me right now you can use the LUN in the snapshot and export it to server 2. I'm sure other storage systems can do something similar, I just happen to know offhand NetApp can do it. Gary From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 21:02:40 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 CDCAA106566B; Mon, 13 Feb 2012 21:02:40 +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 7109414E780; Mon, 13 Feb 2012 21:02:40 +0000 (UTC) Message-ID: <4F397A70.3080104@FreeBSD.org> Date: Mon, 13 Feb 2012 13:02:40 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org 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: Why won't 8.2 umount -f? 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, 13 Feb 2012 21:02:40 -0000 Is there some magic I'm missing to convince an 8.2 system to umount -f? I had an NFS server crash, so I'm trying to get the mounts updated. All of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly 8.2-pN) are just hanging forever. Is this a bug, or is it something I'm missing? 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 Feb 13 21:21:20 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 298F41065672; Mon, 13 Feb 2012 21:21:20 +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 EBAA1203270; Mon, 13 Feb 2012 21:20:55 +0000 (UTC) Message-ID: <4F397EB7.1010402@FreeBSD.org> Date: Mon, 13 Feb 2012 13:20:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4F397A70.3080104@FreeBSD.org> In-Reply-To: <4F397A70.3080104@FreeBSD.org> 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: Why won't 8.2 umount -f? 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, 13 Feb 2012 21:21:20 -0000 On 02/13/2012 13:02, Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount -f? > I had an NFS server crash, so I'm trying to get the mounts updated. All > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > 8.2-pN) are just hanging forever. ... and it gets worse. I just 'shutdown -r now'ed one of my less-critical 8.2 systems, and it hung for several minutes after "All buffers synced." After a power cycle it came back, but the buffers weren't actually synced because it's still fsck'ing some pretty large file systems. What the heck? -- 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 Feb 13 22:14: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 8E82D1065673; Mon, 13 Feb 2012 22:14:14 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-lpp01m020-f182.google.com (mail-lpp01m020-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C61428FC0C; Mon, 13 Feb 2012 22:14:13 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so3996955lbb.13 for ; Mon, 13 Feb 2012 14:14:12 -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 :content-type; bh=Why2PvYEvQ8zEAy0gHmBjsTg84PA4/YydzfNfB4Ahxs=; b=YVY7hQ09Qbr3oZrSgSqyzUhQm0qHcf62HQEpvbSQWydc6kPr39p8/AiSb2aeJsbF+Y UbKpYjJO5YdCThm0aCn3ItkjhC2KDzY8LHO5J2fEFuvVFUw8YDjsTaDm7ZaoY+JMKORg iVzEguumb04xuzjetNG8YkFFIsTriYBrToz70= MIME-Version: 1.0 Received: by 10.152.136.20 with SMTP id pw20mr12678718lab.32.1329169549195; Mon, 13 Feb 2012 13:45:49 -0800 (PST) Received: by 10.152.114.197 with HTTP; Mon, 13 Feb 2012 13:45:49 -0800 (PST) In-Reply-To: <4F397EB7.1010402@FreeBSD.org> References: <4F397A70.3080104@FreeBSD.org> <4F397EB7.1010402@FreeBSD.org> Date: Mon, 13 Feb 2012 22:45:49 +0100 Message-ID: From: claudiu vasadi To: Doug Barton , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Why won't 8.2 umount -f? 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, 13 Feb 2012 22:14:14 -0000 On Mon, Feb 13, 2012 at 10:20 PM, Doug Barton wrote: > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? > > -- > > 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/ > > _______________________________________________ > 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" > Ok, I remember another bug we had some while ago ... so, humor me on this: reproduce the problem where you "shutdown -r now", actually do "shutdown -r now" and leave it be, but check the time at which you issued the cmd. If this is the old but I was told about, the system should reboot exactly after 60 minutes (1 hour). PS: I might be wrong, It's just a hunch. -- Best regards, Claudiu Vasadi From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 22:40: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 51EF21065672; Mon, 13 Feb 2012 22:40:26 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6B38FC13; Mon, 13 Feb 2012 22:40:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1DMe9pR023171 ; Mon, 13 Feb 2012 23:40:09 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1DMd7PL074483; Mon, 13 Feb 2012 23:39:07 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1DMd6tg074479; Mon, 13 Feb 2012 23:39:06 +0100 (CET) (envelope-from arno) To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" References: Date: Mon, 13 Feb 2012 23:39:06 +0100 In-Reply-To: (Arno J. Klaassen's message of "Sat\, 11 Feb 2012 16\:53\:10 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F399149.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F399149.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 13 Feb 2012 22:40:26 -0000 hello, to eventually gain interest in this issue : I updated to today's -stable, tested with vfs.zfs.debug=1 and vfs.zfs.prefetch_disable=0, no difference. I also tested to read the raw partition : [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror 103746636+0 records in 103746636+0 records out 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) [root@cc /usr/ports]# Disk is brand new, looks ok, either my setup is not good or there is a bug somewhere; I can play around with this box for some more time, please feel free to provide me with some hints what to do to be useful for you. Best, Arno "Arno J. Klaassen" writes: > Hello, > > > I finally decided to 'play' a bit with ZFS on a notebook, some years > old, but I installed a brand new disk and memtest passes OK. > > I installed base+ports on partition 2, using 'classical' UFS. > > I crypted partition 3 and created a single zpool on it containing > 4 Z-"file-systems" : > > [root@cc ~]# zfs list > NAME USED AVAIL REFER MOUNTPOINT > zfiles 10.7G 377G 152K /zfiles > zfiles/home 10.6G 377G 119M /zfiles/home > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito > > > I export the ZFS's via nfs and rsynced on the other machine some backup > of my current note-book (geli + UFS, (almost) same 9-stable version, no > problem) to the ZFS's. > > > Quite fast, I see on the notebook : > > > [root@cc /usr/temp]# zpool status -v > pool: zfiles > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 > 2012 > config: > > NAME STATE READ WRITE CKSUM > zfiles ONLINE 0 0 11 > ada0s3.eli ONLINE 0 0 23 > > errors: Permanent errors have been detected in the following files: > > /zfiles/home/arno/.scito/contrib/XNAT.tar > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error > [root@cc /usr/temp]# > > > As said, memtest is OK, nothing is logged to the console, UFS on the > same disk works OK (I did some tests copying and comparing random data) > and smartctl as well seems to trust the disk : > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > # 1 Extended offline Completed without error 00% 388 > # 2 Short offline Completed without error 00% 387 > > > Am I doing something wrong and/or let me know what I could provide as > extra info to try to solve this (dmesg.boot at the end of this mail). > > Thanx a lot in advance, > > best, Arno > > > > ################### demsg.boot ####### > > Table 'FACP' at 0xbdd90200 > Table 'APIC' at 0xbdd90390 > APIC: Found table at 0xbdd90390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 130 ACPI ID 3: disabled > MADT: Found CPU APIC ID 131 ACPI ID 4: disabled > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-STABLE #0: Fri Feb 3 22:48:57 CET 2012 > toor@cc:/usr/obj/raid1/bsd/9/src/sys/VR603 amd64 > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bba000. > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80bba200. > Calibrating TSC clock ... TSC clock: 2161296371 Hz > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz (2161.30-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > Features=0xbfebfbff > Features2=0xe39d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 3221225472 (3072 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x0000000000095fff, 610304 bytes (149 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x0000000000be9000 - 0x00000000b8402fff, 3078725632 bytes (751642 pages) > avail memory = 3057152000 (2915 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 > x86bios: SSEG 0x001000-0x001fff at 0xffffff8000210000 > x86bios: EBDA 0x099000-0x09ffff at 0xfffffe0000099000 > x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf9420 00014 (v00 ACPIAM) > ACPI: RSDT 0xbdd90000 00048 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: FACP 0xbdd90200 00084 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: DSDT 0xbdd905c0 072D3 (v01 1ADTS 1ADTS012 00000012 INTL 20051117) > ACPI: FACS 0xbdd9e000 00040 > ACPI: APIC 0xbdd90390 0006C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: MCFG 0xbdd90400 0003C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: SLIC 0xbdd90440 00176 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: OEMB 0xbdd9e040 00072 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: HPET 0xbdd9a5c0 00038 (v01 MSI_NB OEMHPET 20091013 MSFT 00000097) > ACPI: ASF! 0xbdd9a600 00099 (v32 LEGEND I865PASF 00000001 INTL 20051117) > ACPI: GSCI 0xbdd9e0c0 02024 (v01 MSI_NB GMCHSCI 20091013 MSFT 00000097) > ACPI: SSDT 0xbdda0a50 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > wlan: <802.11 Link Layer> > random: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > nfslock: pseudo-device > io: > null: > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > ACPI: Executed 1 blocks of module-level executable AML code > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bdd00000 (3) failed > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > ACPI: SSDT 0xbdda04b0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > cpu1: on acpi0 > ACPI: SSDT 0xbdda0420 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > acpi_ec0: port 0x62,0x66 on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 5 > Validation 0 5 N 0 5 > After Disable 0 255 N 0 5 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: decoding 4 range 0-0xcf7 > pcib0: decoding 4 range 0xd00-0xffff > pcib0: decoding 3 range 0xa0000-0xbffff > pcib0: decoding 3 range 0xd0000-0xdffff > pcib0: decoding 3 range 0xbde00000-0xdfffffff > pcib0: decoding 3 range 0xf0000000-0xfed8ffff > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x2a40, revid=0x07 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2a42, revid=0x07 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 64, base 0xfd800000, size 22, enabled > pcib0: allocated type 3 (0xfd800000-0xfdbfffff) for rid 10 of pci0:0:2:0 > map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled > pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 > map[20]: type I/O Port, range 32, base 0xb400, size 3, enabled > pcib0: allocated type 4 (0xb400-0xb407) for rid 20 of pci0:0:2:0 > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2a43, revid=0x07 > domain=0, bus=0, slot=2, func=1 > class=03-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 3 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfdd00000, size 20, enabled > pcib0: allocated type 3 (0xfdd00000-0xfddfffff) for rid 10 of pci0:0:2:1 > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled > pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:0 > pcib0: matched entry for 0.26.INTA > pcib0: slot 26 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=7 > map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled > pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:26:1 > pcib0: matched entry for 0.26.INTB > pcib0: slot 26 INTB hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdefec00, size 10, enabled > pcib0: allocated type 3 (0xfdefec00-0xfdefefff) for rid 10 of pci0:0:26:7 > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xfdef8000, size 14, enabled > pcib0: allocated type 3 (0xfdef8000-0xfdefbfff) for rid 10 of pci0:0:27:0 > pcib0: matched entry for 0.27.INTA > pcib0: slot 27 INTA hardwired to IRQ 22 > found-> vendor=0x8086, dev=0x2940, revid=0x03 > domain=0, bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTA > pcib0: slot 28 INTA hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x2942, revid=0x03 > domain=0, bus=0, slot=28, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTB > pcib0: slot 28 INTB hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2946, revid=0x03 > domain=0, bus=0, slot=28, func=3 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTD > pcib0: slot 28 INTD hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=14 > map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled > pcib0: allocated type 4 (0xc000-0xc01f) for rid 20 of pci0:0:29:0 > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled > pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:29:1 > pcib0: matched entry for 0.29.INTB > pcib0: slot 29 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled > pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:29:2 > pcib0: matched entry for 0.29.INTC > pcib0: slot 29 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=14 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdeff000, size 10, enabled > pcib0: allocated type 3 (0xfdeff000-0xfdeff3ff) for rid 10 of pci0:0:29:7 > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2448, revid=0x93 > domain=0, bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2919, revid=0x03 > domain=0, bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2929, revid=0x03 > domain=0, bus=0, slot=31, func=2 > class=01-06-01, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 16 messages > map[10]: type I/O Port, range 32, base 0xcc00, size 3, enabled > pcib0: allocated type 4 (0xcc00-0xcc07) for rid 10 of pci0:0:31:2 > map[14]: type I/O Port, range 32, base 0xc880, size 2, enabled > pcib0: allocated type 4 (0xc880-0xc883) for rid 14 of pci0:0:31:2 > map[18]: type I/O Port, range 32, base 0xc800, size 3, enabled > pcib0: allocated type 4 (0xc800-0xc807) for rid 18 of pci0:0:31:2 > map[1c]: type I/O Port, range 32, base 0xc480, size 2, enabled > pcib0: allocated type 4 (0xc480-0xc483) for rid 1c of pci0:0:31:2 > map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled > pcib0: allocated type 4 (0xc400-0xc41f) for rid 20 of pci0:0:31:2 > map[24]: type Memory, range 32, base 0xfdeff800, size 11, enabled > pcib0: allocated type 3 (0xfdeff800-0xfdefffff) for rid 24 of pci0:0:31:2 > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > map[10]: type Memory, range 64, base 0xfdeff400, size 8, enabled > pcib0: allocated type 3 (0xfdeff400-0xfdeff4ff) for rid 10 of pci0:0:31:3 > map[20]: type I/O Port, range 32, base 0x400, size 5, enabled > pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 > pcib0: matched entry for 0.31.INTC > pcib0: slot 31 INTC hardwired to IRQ 18 > vgapci0: port 0xb400-0xb407 mem 0xfd800000-0xfdbfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: aperture size is 256M, detected 32764k stolen memory > vgapci1: mem 0xfdd00000-0xfddfffff at device 2.1 on pci0 > pci0: at device 26.0 (no driver attached) > pci0: at device 26.1 (no driver attached) > pci0: at device 26.7 (no driver attached) > pci0: at device 27.0 (no driver attached) > pcib1: irq 17 at device 28.0 on pci0 > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 > pcib0: allocated type 3 (0xfdf00000-0xfdffffff) for rid 20 of pcib1 > pcib0: allocated type 3 (0xf9f00000-0xf9ffffff) for rid 24 of pcib1 > pcib1: domain 0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode 0xd000-0xdfff > pcib1: memory decode 0xfdf00000-0xfdffffff > pcib1: prefetched decode 0xf9f00000-0xf9ffffff > pci2: on pcib1 > pci2: domain=0, physical bus=2 > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > domain=0, bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 2 messages in map 0x20 > map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled > pcib1: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 > map[18]: type Memory, range 64, base 0xfdfff000, size 12, enabled > pcib1: allocated memory range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 > map[20]: type Prefetchable Memory, range 64, base 0xf9ff0000, size 16, enabled > pcib1: allocated prefetch range (0xf9ff0000-0xf9ffffff) for rid 20 of pci0:2:0:0 > pcib1: matched entry for 2.0.INTA > pcib1: slot 0 INTA hardwired to IRQ 16 > pci2: at device 0.0 (no driver attached) > pcib2: irq 16 at device 28.1 on pci0 > pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 > pcib0: allocated type 3 (0xfe000000-0xfeafffff) for rid 20 of pcib2 > pcib0: allocated type 3 (0xfa000000-0xfcffffff) for rid 24 of pcib2 > pcib2: domain 0 > pcib2: secondary bus 3 > pcib2: subordinate bus 4 > pcib2: I/O decode 0xe000-0xefff > pcib2: memory decode 0xfe000000-0xfeafffff > pcib2: prefetched decode 0xfa000000-0xfcffffff > pci3: on pcib2 > pci3: domain=0, physical bus=3 > pcib3: irq 19 at device 28.3 on pci0 > pcib0: allocated type 3 (0xfeb00000-0xfebfffff) for rid 20 of pcib3 > pcib3: domain 0 > pcib3: secondary bus 5 > pcib3: subordinate bus 5 > pcib3: memory decode 0xfeb00000-0xfebfffff > pcib3: no prefetched decode > pci5: on pcib3 > pci5: domain=0, physical bus=5 > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > map[10]: type Memory, range 64, base 0xfebf0000, size 16, enabled > pcib3: allocated memory range (0xfebf0000-0xfebfffff) for rid 10 of pci0:5:0:0 > pcib3: matched entry for 5.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 19 > pci5: at device 0.0 (no driver attached) > pci0: at device 29.0 (no driver attached) > pci0: at device 29.1 (no driver attached) > pci0: at device 29.2 (no driver attached) > pci0: at device 29.7 (no driver attached) > pcib4: at device 30.0 on pci0 > pcib4: domain 0 > pcib4: secondary bus 1 > pcib4: subordinate bus 1 > pcib4: no prefetched decode > pcib4: Subtractively decoded bridge. > pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND > pci1: on pcib4 > pci1: domain=0, physical bus=1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfdeff800-0xfdefffff irq 19 at device 31.2 on pci0 > ahci0: attempting to allocate 1 MSI vectors (16 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > ahci0: using IRQ 256 for MSI > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 4ports > ahci0: Caps2: > ahci0: EM Caps: ALHD XMT SMB LED > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > ahcich2: not probed (disabled) > ahcich3: not probed (disabled) > ahcich4: at channel 4 on ahci0 > ahcich4: Caps: > ahcich5: at channel 5 on ahci0 > ahcich5: Caps: > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 51 > Event timer "RTC" frequency 32768 Hz quality 0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 52 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0065 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 53 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route > hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic > hpet0: t1: irqs 0x00f00000 (0) > hpet0: t2: irqs 0x00f00800 (0) > hpet0: t3: irqs 0x00f01000 (0) > Timecounter "HPET" frequency 14318180 Hz quality 950 > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > acpi_button1: on acpi0 > acpi0: wakeup code va 0xffffff80d4544000 pa 0x4000 > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 > isa_probe_children: disabling PnP devices > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xcf7ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > ppc0 failed to probe at irq 7 on isa0 > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > Device configuration finished. > procfs registered > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > ahcich0: AHCI reset... > ahcich0: SATA connect time=100us status=00000123 > ahcich0: AHCI reset: device found > ahcich1: AHCI reset... > ahcich1: SATA offline status=00000004 > ahcich1: AHCI reset: device not found > ahcich4: AHCI reset... > ahcich4: SATA offline status=00000004 > ahcich4: AHCI reset: device not found > ahcich5: AHCI reset... > ahcich5: SATA connect time=900us status=00000113 > ahcich5: AHCI reset: device found > ahcich5: AHCI reset: device ready after 0ms > (aprobe1:ahcich5:0:0:0): SIGNATURE: eb14 > acpi_acad0: acline initialization start > battery0: battery initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > ahcich5: SNTF 0x0001 > ahcich0: AHCI reset: device ready after 100ms > (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 2.x device > GEOM: new disk cd0 > pass0: Serial Number 5YX0J5YD > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number 30651780 1165921Q111 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich5 bus 0 scbus3 target 0 lun 0 > pass1: Removable CD-ROM SCSI-0 device > pass1: Serial Number 30651780 1165921Q111 > pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > ada0: ATA-8 SATA 2.x device > ada0: Serial Number 5YX0J5YD > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > TSC timecounter disabled: C3 enabled. > Timecounter "TSC" frequency 2161296371 Hz quality -1000 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:battery0: battery initialization done, tried 1 times > 0:0): Error 6, Unretryable error > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > GEOM: new disk ada0 > GEOM: ada0s3: media size does not match label. > Trying to mount root from ufs:/dev/ada0s2a [rw,noatime]... > start_init: trying /sbin/init > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > ZFS filesystem version 5 > ZFS storage pool version 28 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > tap0: bpf attached > tap0: Ethernet address: 00:bd:0b:07:00:00 > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > domain=0, bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 2 messages in map 0x20 > pci0:2:0:0: reprobing on driver added > re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xf9ff0000-0xf9ffffff irq 16 at device 0.0 on pci2 > re0: MSI count : 1 > re0: MSI-X count : 2 > re0: attempting to allocate 1 MSI-X vectors (2 supported) > msi: routing MSI-X IRQ 257 to local APIC 0 vector 55 > re0: using IRQ 257 for MSI-X > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: bpf attached > re0: Ethernet address: 00:24:21:61:e0:20 > pci3: driver added > pci5: driver added > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=19 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > pci0:5:0:0: reprobing on driver added > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > pci3: driver added > pci5: driver added > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=19 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > pci0:5:0:0: reprobing on driver added > ath0: mem 0xfebf0000-0xfebfffff irq 19 at device 0.0 on pci5 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 56 > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > ath0: Use hw queue 1 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 2 for WME_AC_VI traffic > ath0: Use hw queue 3 for WME_AC_VO traffic > ath0: Use hw queue 8 for CAB traffic > ath0: Use hw queue 9 for beacons > ath0: using multicast key search > crypto: > cryptosoft0: on motherboard > crypto: assign cryptosoft0 driver id 0, flags 100663296 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > GEOM_ELI: Device ada0s3.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > pci3: driver added > pci5: driver added > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > coretemp0: on cpu0 > coretemp0: Setting TjMax=100 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > coretemp1: on cpu1 > coretemp1: Setting TjMax=100 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-fs@FreeBSD.ORG Mon Feb 13 23:36:34 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 6C1071065672; Mon, 13 Feb 2012 23:36:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3114D8FC19; Mon, 13 Feb 2012 23:36:33 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id q1DMQuUT013743; Mon, 13 Feb 2012 17:01:06 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com with ESMTP id 12y9b7gk2x-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Feb 2012 17:01:06 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Feb 2012 17:01:05 -0600 From: Devin Teske To: Doug Barton References: <4F3993C9.1040506@fisglobal.com> In-Reply-To: <4F3993C9.1040506@fisglobal.com> Date: Mon, 13 Feb 2012 15:01:08 -0800 Message-ID: <08c101cceaa3$5ff9d880$1fed8980$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdwB4ZmQ9SgfWzRn8l+XRpwNy7FJcZxISg Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-13_05:2012-02-13, 2012-02-13, 1970-01-01 signatures=0 Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, "Robison, Dave" Subject: RE: Re: Why won't 8.2 umount -f? 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, 13 Feb 2012 23:36:34 -0000 > -------- Original Message -------- > Subject: Re: Why won't 8.2 umount -f? > Date: Mon, 13 Feb 2012 13:20:55 -0800 > From: Doug Barton > Organization: http://SupersetSolutions.com/ > To: > CC: > Cross posting? (gasp!) > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? We've noticed this behavior too (on 8.1-RELEASE-p6). The work-around (to avoid long fsck) is to: 1. Drop to the kernel debugger (Ctrl+Alt+ESC -- requires DDB to be enabled in kernel) 2. Type: call boot(0) This causes the system to attempt a second sync of the buffers. This second attempt ends up timing out but succeeds in resetting the CPU (after 3x 60s timeouts). The price (waiting 180s before cpu_reset() is called) can be well worth it (avoiding multi-hour fsck) because the disks will be marked clean. For us, this is a serious issue and like Doug, we too exclaim "what the heck?" Shouldn't have to drop to kernel debugger and [redundantly] invoke boot(0) after syncer's hang just prior to cpu_reset(). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 02:23: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 08BD9106566C; Tue, 14 Feb 2012 02:23:40 +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 9B2248FC08; Tue, 14 Feb 2012 02:23:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPXEOU+DaFvO/2dsb2JhbAA7CIUQrB2BcgEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIdbCac/kh6BL4dpgjAVFwUKBwEDAgQHAh0BAwIUBIMeAQYBDQYCg0CBFgSISopAgiiTAg X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="156285400" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 21:23:38 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 82976B3F0E; Mon, 13 Feb 2012 21:23:38 -0500 (EST) Date: Mon, 13 Feb 2012 21:23:38 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F397A70.3080104@FreeBSD.org> 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 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 02:23:40 -0000 Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount > -f? > I had an NFS server crash, so I'm trying to get the mounts updated. > All > of the 7.x systems happily did 'umount -f', but the 8.x systems > (mostly > 8.2-pN) are just hanging forever. > > Is this a bug, or is it something I'm missing? > Well, I didn't realize that a 7.n system would "umount -f" an NFS mount when the server was down and there were dirty blocks that needed to be written back, but I don't know. (I seem to recall that someone encouraged me to MFC one of my changes related to this back to stable/7, but I'm not sure if it mattered?) I have pretty well fixed the new client w.r.t. this except for the case where you do a "umount " and that gets hung. Once a non "-f" umount gets hung, there is nothing you can do, because the mount point is locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). My guess is that the old (default for 8.n) client isn't fixed for this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it used some in the old/regular client, but not as much as the new one. You also need a fairly recent (can't remember if that is in 8.2) version of umount.c, since the code had a "sync();" at the beginning of it that would hang before even getting to the umount(2) syscall. Bottom line, I think the newnfs client (the default for 9.0) can do this, but I'm doubtful the old/reguler one can. (I also wouldn't be surprised if there is still a bug other than the above mentioned one w.r.t. doing a "umount /mnt" and getting that hung before trying "umount -f /mnt". rick > > 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/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 02:41: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 29C77106566B; Tue, 14 Feb 2012 02:41:14 +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 1A63014EB5A; Tue, 14 Feb 2012 02:41:13 +0000 (UTC) Message-ID: <4F39C9C8.7060700@FreeBSD.org> Date: Mon, 13 Feb 2012 18:41:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Rick Macklem References: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <318799457.1320617.1329186218494.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, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 02:41:14 -0000 On 02/13/2012 18:23, Rick Macklem wrote: > Doug Barton wrote: >> Is there some magic I'm missing to convince an 8.2 system to umount >> -f? >> I had an NFS server crash, so I'm trying to get the mounts updated. >> All >> of the 7.x systems happily did 'umount -f', but the 8.x systems >> (mostly >> 8.2-pN) are just hanging forever. >> >> Is this a bug, or is it something I'm missing? >> > Well, I didn't realize that a 7.n system would "umount -f" an NFS > mount when the server was down and there were dirty blocks that > needed to be written back, but I don't know. I'm doubtful that any of those systems had dirty blocks. > (I seem to recall that > someone encouraged me to MFC one of my changes related to this back > to stable/7, but I'm not sure if it mattered?) Please don't unless you can verify that it doesn't make this situation worse. :) > I have pretty well fixed the new client w.r.t. this except for the > case where you do a "umount " and that gets hung. Once a non "-f" > umount gets hung, there is nothing you can do, because the mount point is > locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). I'm aware of this issue, and I did 'umount -f' first. But I wonder if this isn't something that should be fixed because I think most users would expect that 'umount -> umount -f' would be the natural progression, similar to 'kill -> kill -9'. > My guess is that the old (default for 8.n) client isn't fixed for > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > used some in the old/regular client, but not as much as the new one. > > You also need a fairly recent (can't remember if that is in 8.2) > version of umount.c, since the code had a "sync();" at the beginning > of it that would hang before even getting to the umount(2) syscall. > > Bottom line, I think the newnfs client (the default for 9.0) can > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > be surprised if there is still a bug other than the above mentioned > one w.r.t. doing a "umount /mnt" and getting that hung before trying > "umount -f /mnt". Is the new client in 8-stable up to date relevant to 9.0, and/or is it considered safe to use in production? Thanks, 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 Tue Feb 14 03:13:31 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 131C1106564A; Tue, 14 Feb 2012 03:13:31 +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 925378FC12; Tue, 14 Feb 2012 03:13:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACLQOU+DaFvO/2dsb2JhbAA7CIUQrB6BcgEBBAEjBFIbGAICDQgCDwJZBogPp0KSHYEvh2mCPggKBgUHARgNAQICCAMOBAYDBQwVAoM7gS0CgXSBFgSISoxokwI X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="159429863" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 22:13:29 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 80EC1B3F33; Mon, 13 Feb 2012 22:13:29 -0500 (EST) Date: Mon, 13 Feb 2012 22:13:29 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39C9C8.7060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:13:31 -0000 Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > sbruno did the MFC. I don't think the changes would make it worse. > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > I just looked and at least some of the fixes were MFC'd to stable/8 about 8months ago. So, they aren't in 8.2, but will be in 8.3. > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > It looks like stable/8 might be ok using either client. The newnfs in stable/8 should be up to date w.r.t. bugfixes in the new/regular client in 9.0. > > Thanks, > > 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 Tue Feb 14 03:18:34 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 6A2B8106564A; Tue, 14 Feb 2012 03:18:34 +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 EE2C98FC08; Tue, 14 Feb 2012 03:18:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANnROU+DaFvO/2dsb2JhbAA7CIUQrB6BcgEBBAEjBFIbGAICDQgCDwJZBogPp0CSGoEvh2mCQAYKBgMCBAQBJAECAggDDgQGAwUMF4M7gS0CgXSBFgSISoxokwI X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="156290538" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 22:18:33 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 43B14B3F3B; Mon, 13 Feb 2012 22:18:33 -0500 (EST) Date: Mon, 13 Feb 2012 22:18:33 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39C9C8.7060700@FreeBSD.org> 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 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:18:34 -0000 Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > I suspect that is "very difficult" to fix. The regular "umount /mnt" will stuck somewhere inside vinvalbuf() trying to flush blocks back to the server while holding a lock on the mount point. Although kib@ is the guy who would most likely know, I don't think it would be easy to get it to come out ok. For example, one approach might be to make all the sleeps interruptible and then add code to gracefully handle an EINTR return from them and then release locks as they return and..... well it's not something I would want to tackle. > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > > > Thanks, > > 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 Tue Feb 14 03:22:44 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 086C6106564A; Tue, 14 Feb 2012 03:22:44 +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 C3B4B14ED12; Tue, 14 Feb 2012 03:22:42 +0000 (UTC) Message-ID: <4F39D382.50209@FreeBSD.org> Date: Mon, 13 Feb 2012 19:22:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Rick Macklem References: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <2040914240.1324793.1329189209494.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, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:22:44 -0000 On 02/13/2012 19:13, Rick Macklem wrote: > I just looked and at least some of the fixes were MFC'd to stable/8 about > 8months ago. So, they aren't in 8.2, but will be in 8.3. Well 8.3 is about to enter code freeze, any way we can check to be sure all of the relevant fixes can be mfc'ed? 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 Tue Feb 14 09:14:44 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 AD4F31065670 for ; Tue, 14 Feb 2012 09:14:44 +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 530FE8FC17 for ; Tue, 14 Feb 2012 09:14:42 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Ll4mA-1SX6zH1CYY-00bOFG; Tue, 14 Feb 2012 10:14:41 +0100 Message-ID: <4F3A2600.80400@brockmann-consult.de> Date: Tue, 14 Feb 2012 10:14:40 +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: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:0AFLWcqV5wV2m7nPXFaDffHjXQB6zV3JklW1HqlIRUM o7UAL/5HQsJhXfdksJUeGWH3n2u0HnYIO473vb6bmUl6ymJXea B0Qf0sVmTKnv3IRTwvgBk66fURSBQ1nMZL0oNNK09kl8oMWBZr Ar6TaUmv+OtFdH7G+7H5/RAnJGg6suFQIGnIHbOzw2soPebQ2O 4S+HSniMxdVXVE84vmI7M+YM/6OENUvPy9gchfX1jy55l7chM+ 2WfG/ShSbHFi/y+iw1E1/1jhgTBJKgFeaZQW9hz7hIrGn/a19q pnMIIuN569guUGPCBsk9dQid94VUUNOGb7P6HsfKM8d+l5BT6E fgefAQyXUQ4yt3qKPO9pqr7K/7ejed3HHV7wbKgBd Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 09:14:44 -0000 On 02/14/2012 04:18 AM, Rick Macklem wrote: > Doug Barton wrote: >> On 02/13/2012 18:23, Rick Macklem wrote: >>> Doug Barton wrote: >>>> Is there some magic I'm missing to convince an 8.2 system to umount >>>> -f? >>>> I had an NFS server crash, so I'm trying to get the mounts updated. >>>> All >>>> of the 7.x systems happily did 'umount -f', but the 8.x systems >>>> (mostly >>>> 8.2-pN) are just hanging forever. >>>> >>>> Is this a bug, or is it something I'm missing? >>>> >>> Well, I didn't realize that a 7.n system would "umount -f" an NFS >>> mount when the server was down and there were dirty blocks that >>> needed to be written back, but I don't know. >> I'm doubtful that any of those systems had dirty blocks. >> >>> (I seem to recall that >>> someone encouraged me to MFC one of my changes related to this back >>> to stable/7, but I'm not sure if it mattered?) >> Please don't unless you can verify that it doesn't make this situation >> worse. :) >> >>> I have pretty well fixed the new client w.r.t. this except for the >>> case where you do a "umount " and that gets hung. Once a non >>> "-f" >>> umount gets hung, there is nothing you can do, because the mount >>> point is >>> locked up, so a subsequent "umount -f" can't get as far as >>> nfs_umount(). >> I'm aware of this issue, and I did 'umount -f' first. But I wonder if >> this isn't something that should be fixed because I think most users >> would expect that 'umount -> umount -f' would be the natural >> progression, similar to 'kill -> kill -9'. >> > I suspect that is "very difficult" to fix. The regular "umount /mnt" will > stuck somewhere inside vinvalbuf() trying to flush blocks back to the server > while holding a lock on the mount point. Although kib@ is the guy who > would most likely know, I don't think it would be easy to get it to come > out ok. For example, one approach might be to make all the sleeps interruptible > and then add code to gracefully handle an EINTR return from them and then > release locks as they return and..... well it's not something I would want > to tackle. > Lately (last 5 years or so), Linux seems to always hang or fail on "umount -f mountpoint", but there is another option "-l" which always works, even after "umount" or "umount -f" fails. I've never seen corruption from NFS using "-l", which I use often. So if it is very difficult to fix -f, why not add -l? -l Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as it is not busy anymore. (Requires kernel 2.4.11 or later.) -f Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.) And I realize they are not equivalent in all ways, but in cases of mounts that are hung and will never work again, it works the same. "cleanup ... as soon as it is not busy" probably means never clean up if it is hung, but that is similar enough to "-f". >>> My guess is that the old (default for 8.n) client isn't fixed for >>> this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it >>> used some in the old/regular client, but not as much as the new one. >>> >>> You also need a fairly recent (can't remember if that is in 8.2) >>> version of umount.c, since the code had a "sync();" at the beginning >>> of it that would hang before even getting to the umount(2) syscall. >>> >>> Bottom line, I think the newnfs client (the default for 9.0) can >>> do this, but I'm doubtful the old/reguler one can. (I also wouldn't >>> be surprised if there is still a bug other than the above mentioned >>> one w.r.t. doing a "umount /mnt" and getting that hung before trying >>> "umount -f /mnt". >> Is the new client in 8-stable up to date relevant to 9.0, and/or is it >> considered safe to use in production? >> >> >> Thanks, >> >> 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/ > _______________________________________________ > 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 Tue Feb 14 10:00:22 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 9F7121065673 for ; Tue, 14 Feb 2012 10:00:22 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 4664C8FC17 for ; Tue, 14 Feb 2012 10:00:19 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1EA0AQM033304 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 14 Feb 2012 10:00:10 GMT (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1EA0AQM033304 Authentication-Results: smtp.infracaninophile.co.uk/q1EA0AQM033304; dkim=none (no signature); dkim-adsp=none Message-ID: <4F3A30A2.9050603@FreeBSD.org> Date: Tue, 14 Feb 2012 10:00:02 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> <4F37BA49.50700@brockmann-consult.de> <4F37C52A.2030803@infracaninophile.co.uk> In-Reply-To: <4F37C52A.2030803@infracaninophile.co.uk> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigABA72FEEFCADB51739FE12FD" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: ZFS Snapshot problems 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, 14 Feb 2012 10:00:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigABA72FEEFCADB51739FE12FD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/02/2012 13:56, Matthew Seaman wrote: > On 12/02/2012 13:10, Peter Maloney wrote: >> > I don't know what side effects that change has though. You can usual= ly >> > assume that ZFS will just figure out the pool regardless of labels >> > (because it uses its own label metadata; see zdb output to see the o= ther >> > id), but apparently your case is something special, getting actual >> > errors instead of only wrong names. > Yes. This is most perplexing -- it's such a specific effect. The gpt > thing may well be a red herring. It is odd though that zdb somehow > discovers the gpart labels through reading zpool.cache, but zpool(1) > uses the gptids instead. Some more data about the underlying problem. -- There is another symptom: once the snapshots get wedged, the system will crash on shutdown. I don't have a crashdump or anything particularly useful, but this is what appeared in the kernel log: + +Fatal trap 12: page fault while in kernel mode +cpuid =3D 0; apic id =3D 00 +fault virtual address =3D 0xa8 +fault code =3D supervisor write data, page not present +instruction pointer =3D 0x20:0xffffffff805f9e65 +stack pointer =3D 0x28:0xffffff800003a920 +frame pointer =3D 0x28:0xffffff800003a930 +code segment =3D base 0x0, limit 0xfffff, type 0x1b + =3D DPL 0, pres 1, long 1, def32 0, gran 1 +processor eflags =3D interrupt enabled, resume, IOPL =3D 0 +current process =3D 1 (init) +trap number =3D 12 +panic: page fault +cpuid =3D 0 +KDB: stack backtrace: +#0 0xffffffff80624c0e at kdb_backtrace+0x5e +#1 0xffffffff805f1d53 at panic+0x183 +#2 0xffffffff808df490 at trap_fatal+0x290 +#3 0xffffffff808df7e1 at trap_pfault+0x201 +#4 0xffffffff808dfc9f at trap+0x3df +#5 0xffffffff808c7284 at calltrap+0x8 +#6 0xffffffff80f8a2e5 at zfsctl_umount_snapshots+0xa5 +#7 0xffffffff80f9b74f at zfs_umount+0x6f +#8 0xffffffff8067dc1c at dounmount+0x26c +#9 0xffffffff80681332 at vfs_unmountall+0x42 +#10 0xffffffff805f1b70 at boot+0x790 +#11 0xffffffff805f1e4c at reboot+0x6c +#12 0xffffffff808deb44 at amd64_syscall+0x1f4 +#13 0xffffffff808c757c at Xfast_syscall+0xfc +Uptime: 10d23h49m19s +FreeBSD 8.2-STABLE #2 r231394: Fri Feb 10 20:35:13 GMT 2012 +CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3166.33-MHz K8-class CPU) +avail memory =3D 8196075520 (7816 MB) +dcons_crom0: bus_addr 0x3d94000 +pid 89559 (emacs) is using legacy pty devices - not logging anymore +instruction pointer =3D 0x20:0xffffffff8060d275 +#0 0xffffffff8063801e at kdb_backtrace+0x5e +#1 0xffffffff80605163 at panic+0x183 +#2 0xffffffff808f2da0 at trap_fatal+0x290 +#3 0xffffffff808f30f1 at trap_pfault+0x201 +#4 0xffffffff808f35af at trap+0x3df +#5 0xffffffff808dab94 at calltrap+0x8 +#6 0xffffffff80fa42e5 at zfsctl_umount_snapshots+0xa5 +#7 0xffffffff80fb574f at zfs_umount+0x6f +#8 0xffffffff8069103c at dounmount+0x26c +#9 0xffffffff80695482 at vfs_unmountall+0x42 +#10 0xffffffff80604f80 at boot+0x790 +#11 0xffffffff8060525c at reboot+0x6c +#12 0xffffffff808f2454 at amd64_syscall+0x1f4 +#13 0xffffffff808dae8c at Xfast_syscall+0xfc +Uptime: 2d10h51m47s +FreeBSD 8.2-STABLE #3 r231563: Mon Feb 13 01:37:39 GMT 2012 +avail memory =3D 8196034560 (7816 MB) -- I can't conform this yet, but I've a feeling that removing the *last* snapshot is significant. Whether it's the last snapshot of a particular zfs or the last snapshot in the zpool I don't know yet. Testing this is a long-winded affair as I can't afford to keep rebooting this server, and I need it to backup successfully most of the time. -- The problem only seems to occur when snapshots are removed, so my workaround for the time being is not to remove the snapshots I create for each nightly backup. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigABA72FEEFCADB51739FE12FD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk86MKkACgkQ8Mjk52CukIxgegCfZQKceGfOlDNbBzwq9CZx4P17 zAUAn3Qh/8HJ9Qq0qHbj971zHDiV87dq =Y+9S -----END PGP SIGNATURE----- --------------enigABA72FEEFCADB51739FE12FD-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 14:18:46 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 A6ADA1065672 for ; Tue, 14 Feb 2012 14:18:46 +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 50EB98FC0A for ; Tue, 14 Feb 2012 14:18:46 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MCMOD-1RokVg0n1V-0090sz; Tue, 14 Feb 2012 15:18:45 +0100 Message-ID: <4F3A6D44.4040105@brockmann-consult.de> Date: Tue, 14 Feb 2012 15:18:44 +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: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> <4F37BA49.50700@brockmann-consult.de> <4F37C52A.2030803@infracaninophile.co.uk> <4F3A30A2.9050603@FreeBSD.org> In-Reply-To: <4F3A30A2.9050603@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:WjI56l9y8OWVJUDK1MJ9QJT99z7LiLEp9S1Y7w7PMdJ qKq7qG0Xj2bTM48h0t73dOn7bJ9/F+VzcuW2nqcdTYVOOrSRvt lrPHO/rvAH0nppfwEWtrYbVJ85hamMHvC5X7FDsCrC1btvC75R dgKOoPOOtT5IPGrNNuLtBoI0qcPMu+cugdRHdo1xkaTlckfXTq B1i3Jjso+EiKTSrdNB0s8FvkD9b1CWVul8Um44ByZfw0jfQ4zb eG5RC70q1SpL/Tz1rVxSaF0VdAmvwXga4o6zH5Bp5I6dj/Upoz hm+XfYG01IsnDzeYJuIO7+sy90t6iEgXagviht5qipxZJfb/oa nGfwMJuyhR93ShzKoWKgmBJ6xY6sB38/iG19MlERV Subject: Re: ZFS Snapshot problems 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, 14 Feb 2012 14:18:46 -0000 Was your pool created at the current version, or upgraded? Some pools have issues when upgraded. Mine had a separate log that could not be removed after being upgraded to v28. So I destroyed it and recreated it, and things are fine. I don't know if it is the upgrade process that is broken, or just that the old ZFS code in FreeBSD was buggy, so pools are slightly corrupt. And what zpool and zfs version are you running? Is this your FreeBSD version? (FreeBSD 8.2-STABLE #2 r231394: Fri Feb 10 20:35:13 GMT 2012) Your FreeBSD sounds very old. I tried 8.2 stable from April and it was unusably unstable with zfs. If you are using a recent STABLE pull, and have created the pool with an old version of FreeBSD, have you considered destroying the pool and recreating it with your backups, using zfs send & recv? On 02/14/2012 11:00 AM, Matthew Seaman wrote: > On 12/02/2012 13:56, Matthew Seaman wrote: >> On 12/02/2012 13:10, Peter Maloney wrote: >>>> I don't know what side effects that change has though. You can usually >>>> assume that ZFS will just figure out the pool regardless of labels >>>> (because it uses its own label metadata; see zdb output to see the other >>>> id), but apparently your case is something special, getting actual >>>> errors instead of only wrong names. >> Yes. This is most perplexing -- it's such a specific effect. The gpt >> thing may well be a red herring. It is odd though that zdb somehow >> discovers the gpart labels through reading zpool.cache, but zpool(1) >> uses the gptids instead. > Some more data about the underlying problem. > > -- There is another symptom: once the snapshots get wedged, the > system will crash on shutdown. I don't have a crashdump or > anything particularly useful, but this is what appeared in the > kernel log: > > + > +Fatal trap 12: page fault while in kernel mode > +cpuid = 0; apic id = 00 > +fault virtual address = 0xa8 > +fault code = supervisor write data, page not present > +instruction pointer = 0x20:0xffffffff805f9e65 > +stack pointer = 0x28:0xffffff800003a920 > +frame pointer = 0x28:0xffffff800003a930 > +code segment = base 0x0, limit 0xfffff, type 0x1b > + = DPL 0, pres 1, long 1, def32 0, gran 1 > +processor eflags = interrupt enabled, resume, IOPL = 0 > +current process = 1 (init) > +trap number = 12 > +panic: page fault > +cpuid = 0 > +KDB: stack backtrace: > +#0 0xffffffff80624c0e at kdb_backtrace+0x5e > +#1 0xffffffff805f1d53 at panic+0x183 > +#2 0xffffffff808df490 at trap_fatal+0x290 > +#3 0xffffffff808df7e1 at trap_pfault+0x201 > +#4 0xffffffff808dfc9f at trap+0x3df > +#5 0xffffffff808c7284 at calltrap+0x8 > +#6 0xffffffff80f8a2e5 at zfsctl_umount_snapshots+0xa5 > +#7 0xffffffff80f9b74f at zfs_umount+0x6f > +#8 0xffffffff8067dc1c at dounmount+0x26c > +#9 0xffffffff80681332 at vfs_unmountall+0x42 > +#10 0xffffffff805f1b70 at boot+0x790 > +#11 0xffffffff805f1e4c at reboot+0x6c > +#12 0xffffffff808deb44 at amd64_syscall+0x1f4 > +#13 0xffffffff808c757c at Xfast_syscall+0xfc > +Uptime: 10d23h49m19s > +FreeBSD 8.2-STABLE #2 r231394: Fri Feb 10 20:35:13 GMT 2012 > +CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3166.33-MHz > K8-class CPU) > +avail memory = 8196075520 (7816 MB) > +dcons_crom0: bus_addr 0x3d94000 > +pid 89559 (emacs) is using legacy pty devices - not logging anymore > +instruction pointer = 0x20:0xffffffff8060d275 > +#0 0xffffffff8063801e at kdb_backtrace+0x5e > +#1 0xffffffff80605163 at panic+0x183 > +#2 0xffffffff808f2da0 at trap_fatal+0x290 > +#3 0xffffffff808f30f1 at trap_pfault+0x201 > +#4 0xffffffff808f35af at trap+0x3df > +#5 0xffffffff808dab94 at calltrap+0x8 > +#6 0xffffffff80fa42e5 at zfsctl_umount_snapshots+0xa5 > +#7 0xffffffff80fb574f at zfs_umount+0x6f > +#8 0xffffffff8069103c at dounmount+0x26c > +#9 0xffffffff80695482 at vfs_unmountall+0x42 > +#10 0xffffffff80604f80 at boot+0x790 > +#11 0xffffffff8060525c at reboot+0x6c > +#12 0xffffffff808f2454 at amd64_syscall+0x1f4 > +#13 0xffffffff808dae8c at Xfast_syscall+0xfc > +Uptime: 2d10h51m47s > +FreeBSD 8.2-STABLE #3 r231563: Mon Feb 13 01:37:39 GMT 2012 > +avail memory = 8196034560 (7816 MB) > > -- I can't conform this yet, but I've a feeling that removing the > *last* snapshot is significant. Whether it's the last snapshot > of a particular zfs or the last snapshot in the zpool I don't know > yet. Testing this is a long-winded affair as I can't afford to > keep rebooting this server, and I need it to backup successfully > most of the time. > > -- The problem only seems to occur when snapshots are removed, so my > workaround for the time being is not to remove the snapshots I > create for each nightly backup. > > Cheers, > > Matthew > -- -------------------------------------------- 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 Tue Feb 14 14:40:53 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 69FF8106567C for ; Tue, 14 Feb 2012 14:40:53 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id BF6528FC13 for ; Tue, 14 Feb 2012 14:40:52 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1EEeiNx061994 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 14 Feb 2012 14:40:44 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1EEeiNx061994 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1329230444; bh=Jb1OIl5spvelGcxWuKt+Q3UAILAZbVEmm2aCfEXodDU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=RPb5cDKu3aIkavXEnsN3CQbt8Q0kAU5r+FWckAVL2vkstL8EomW1Ejls5jXbjQj4c +Xyqy/1TLpO4Vwf5R37JpnTH0liWlFF13BWHJxc24Lbzb0zujC/zIleQeGHotUCHpf SxuuDD8XXT658+IqutW/Q3qnk/FTTqOabiSGQRdY= Message-ID: <4F3A7264.8080301@infracaninophile.co.uk> Date: Tue, 14 Feb 2012 14:40:36 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> <4F37BA49.50700@brockmann-consult.de> <4F37C52A.2030803@infracaninophile.co.uk> <4F3A30A2.9050603@FreeBSD.org> <4F3A6D44.4040105@brockmann-consult.de> In-Reply-To: <4F3A6D44.4040105@brockmann-consult.de> X-Enigmail-Version: 1.3.5 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD06EDE91F002052F982823E" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS Snapshot problems 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, 14 Feb 2012 14:40:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD06EDE91F002052F982823E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/02/2012 14:18, Peter Maloney wrote: > Was your pool created at the current version, or upgraded? Upgraded. I was testing the v28 patches for quite a while. > Some pools have issues when upgraded. Mine had a separate log that coul= d > not be removed after being upgraded to v28. So I destroyed it and > recreated it, and things are fine. I don't know if it is the upgrade > process that is broken, or just that the old ZFS code in FreeBSD was > buggy, so pools are slightly corrupt. Well, it's been on v28 for more than a year. Odd that this should suddenly appear now. > And what zpool and zfs version are you running? Like I posted in the very first message in this thread: zpool v28, zfs v5= =2E > Is this your FreeBSD version? (FreeBSD 8.2-STABLE #2 r231394: Fri Feb 1= 0 > 20:35:13 GMT 2012) > Your FreeBSD sounds very old. I tried 8.2 stable from April and it was > unusably unstable with zfs. Right now it's: FreeBSD lucid-nonsense.infracaninophile.co.uk 8.2-STABLE FreeBSD 8.2-STABLE #3 r231563: Mon Feb 13 01:37:39 GMT 2012 root@lucid-nonsense.infracaninophile.co.uk:/usr/obj/usr/src/sys/LUCID-NON= SENSE amd64 Which is stable/8 from last Sunday. I hardly think that qualifies as "old." I am planning to upgrade to stable/9 in the reasonably near future -- perhaps I'll do that sooner rather than later if it offers any potential fixes. I wasn't aware that there were many changes between stable/8 and stable/9 in respect of ZFS. > If you are using a recent STABLE pull, and have created the pool with a= n > old version of FreeBSD, have you considered destroying the pool and > recreating it with your backups, using zfs send & recv? Hmmm... no. That sounds like a thing to try when I have a day or so that I can take the machine down for. Probably right around the point that I do the upgrade to 9.x. Thinking about it, I'd probably split the mirror, rebuild one of the drives, pull the ZFSes across, boot from the rebuilt drive and then add the old drive back to the mirror. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigAD06EDE91F002052F982823E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk86cmsACgkQ8Mjk52CukIya5gCfa1cGxTeZX9bh2LkeKZGJosnP hlMAmgL7/Y4Eba/gNJ8wHEnn4jtLeCON =YbBd -----END PGP SIGNATURE----- --------------enigAD06EDE91F002052F982823E-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 16:40:04 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 B3145106566B; Tue, 14 Feb 2012 16:40:04 +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 2B3BE8FC16; Tue, 14 Feb 2012 16:40:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAD6OOk+DaFvO/2dsb2JhbABDhRCsGYFyAQEEASNWGxgCAg0ZAlkGiA+naZIIgS+KKCQZDQECAggDDgQGAwUMDwMBAgKDO4MjgRYEiEqMaJMC X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="159505570" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 14 Feb 2012 11:39:51 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 43FF1B4040; Tue, 14 Feb 2012 11:39:51 -0500 (EST) Date: Tue, 14 Feb 2012 11:39:51 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39D382.50209@FreeBSD.org> 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, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 16:40:04 -0000 Doug Barton wrote: > On 02/13/2012 19:13, Rick Macklem wrote: > > I just looked and at least some of the fixes were MFC'd to stable/8 > > about > > 8months ago. So, they aren't in 8.2, but will be in 8.3. > > Well 8.3 is about to enter code freeze, any way we can check to be > sure > all of the relevant fixes can be mfc'ed? > I took a look and they seem to have been MFC'd. rick > > 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 Tue Feb 14 18:30: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 8EB691065691; Tue, 14 Feb 2012 18:30:54 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1DF8FC29; Tue, 14 Feb 2012 18:30:53 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q1EIK1Sb023178; Tue, 14 Feb 2012 18:20:01 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q1EIK1pa032530; Tue, 14 Feb 2012 18:20:01 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q1EIK1MP032526; Tue, 14 Feb 2012 18:20:01 GMT Date: Tue, 14 Feb 2012 18:20:01 GMT Message-Id: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> From: Martin Simmons To: "Arno J. Klaassen" In-reply-to: (arno@heho.snv.jussieu.fr) References: Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 18:30:54 -0000 Some random ideas: 1) Can you dd the whole of ada0s3.eli without errors? 2) If you scrub a few more times, does it find the same number of errors each time and are they always in that XNAT.tar file? 3) Can you try zfs without geli? 4) Is the slice/partition layout definitely correct? __Martin >>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: > > hello, > > to eventually gain interest in this issue : > > I updated to today's -stable, tested with vfs.zfs.debug=1 > and vfs.zfs.prefetch_disable=0, no difference. > > I also tested to read the raw partition : > > [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror > 103746636+0 records in > 103746636+0 records out > 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) > [root@cc /usr/ports]# > > Disk is brand new, looks ok, either my setup is not good or there is > a bug somewhere; I can play around with this box for some more time, > please feel free to provide me with some hints what to do to be useful > for you. > > Best, > > Arno > > > "Arno J. Klaassen" writes: > > > Hello, > > > > > > I finally decided to 'play' a bit with ZFS on a notebook, some years > > old, but I installed a brand new disk and memtest passes OK. > > > > I installed base+ports on partition 2, using 'classical' UFS. > > > > I crypted partition 3 and created a single zpool on it containing > > 4 Z-"file-systems" : > > > > [root@cc ~]# zfs list > > NAME USED AVAIL REFER MOUNTPOINT > > zfiles 10.7G 377G 152K /zfiles > > zfiles/home 10.6G 377G 119M /zfiles/home > > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno > > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv > > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito > > > > > > I export the ZFS's via nfs and rsynced on the other machine some backup > > of my current note-book (geli + UFS, (almost) same 9-stable version, no > > problem) to the ZFS's. > > > > > > Quite fast, I see on the notebook : > > > > > > [root@cc /usr/temp]# zpool status -v > > pool: zfiles > > state: ONLINE > > status: One or more devices has experienced an error resulting in data > > corruption. Applications may be affected. > > action: Restore the file in question if possible. Otherwise restore the > > entire pool from backup. > > see: http://www.sun.com/msg/ZFS-8000-8A > > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 > > 2012 > > config: > > > > NAME STATE READ WRITE CKSUM > > zfiles ONLINE 0 0 11 > > ada0s3.eli ONLINE 0 0 23 > > > > errors: Permanent errors have been detected in the following files: > > > > /zfiles/home/arno/.scito/contrib/XNAT.tar > > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar > > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error > > [root@cc /usr/temp]# > > > > > > As said, memtest is OK, nothing is logged to the console, UFS on the > > same disk works OK (I did some tests copying and comparing random data) > > and smartctl as well seems to trust the disk : > > > > SMART Self-test log structure revision number 1 > > Num Test_Description Status Remaining LifeTime(hours) > > # 1 Extended offline Completed without error 00% 388 > > # 2 Short offline Completed without error 00% 387 > > > > > > Am I doing something wrong and/or let me know what I could provide as > > extra info to try to solve this (dmesg.boot at the end of this mail). > > > > Thanx a lot in advance, > > > > best, Arno > > > > > > > > ################### demsg.boot ####### > > > > Table 'FACP' at 0xbdd90200 > > Table 'APIC' at 0xbdd90390 > > APIC: Found table at 0xbdd90390 > > APIC: Using the MADT enumerator. > > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > > SMP: Added CPU 0 (AP) > > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > > SMP: Added CPU 1 (AP) > > MADT: Found CPU APIC ID 130 ACPI ID 3: disabled > > MADT: Found CPU APIC ID 131 ACPI ID 4: disabled > > Copyright (c) 1992-2012 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 9.0-STABLE #0: Fri Feb 3 22:48:57 CET 2012 > > toor@cc:/usr/obj/raid1/bsd/9/src/sys/VR603 amd64 > > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bba000. > > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80bba200. > > Calibrating TSC clock ... TSC clock: 2161296371 Hz > > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz (2161.30-MHz K8-class CPU) > > Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > Features=0xbfebfbff > > Features2=0xe39d > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > real memory = 3221225472 (3072 MB) > > Physical memory chunk(s): > > 0x0000000000001000 - 0x0000000000095fff, 610304 bytes (149 pages) > > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > > 0x0000000000be9000 - 0x00000000b8402fff, 3078725632 bytes (751642 pages) > > avail memory = 3057152000 (2915 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > INTR: Adding local APIC 1 as a target > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 > > x86bios: SSEG 0x001000-0x001fff at 0xffffff8000210000 > > x86bios: EBDA 0x099000-0x09ffff at 0xfffffe0000099000 > > x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > > APIC: CPU 0 has ACPI ID 1 > > APIC: CPU 1 has ACPI ID 2 > > ULE: setup cpu 0 > > ULE: setup cpu 1 > > ACPI: RSDP 0xf9420 00014 (v00 ACPIAM) > > ACPI: RSDT 0xbdd90000 00048 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: FACP 0xbdd90200 00084 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: DSDT 0xbdd905c0 072D3 (v01 1ADTS 1ADTS012 00000012 INTL 20051117) > > ACPI: FACS 0xbdd9e000 00040 > > ACPI: APIC 0xbdd90390 0006C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: MCFG 0xbdd90400 0003C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: SLIC 0xbdd90440 00176 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: OEMB 0xbdd9e040 00072 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: HPET 0xbdd9a5c0 00038 (v01 MSI_NB OEMHPET 20091013 MSFT 00000097) > > ACPI: ASF! 0xbdd9a600 00099 (v32 LEGEND I865PASF 00000001 INTL 20051117) > > ACPI: GSCI 0xbdd9e0c0 02024 (v01 MSI_NB GMCHSCI 20091013 MSFT 00000097) > > ACPI: SSDT 0xbdda0a50 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) > > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > > ioapic0: Routing external 8259A's -> intpin 0 > > MADT: Interrupt override: source 0, irq 2 > > ioapic0: Routing IRQ 0 -> intpin 2 > > MADT: Interrupt override: source 9, irq 9 > > ioapic0: intpin 9 trigger: level > > ioapic0 irqs 0-23 on motherboard > > cpu0 BSP: > > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > > wlan: <802.11 Link Layer> > > random: > > kbd: new array size 4 > > kbd1 at kbdmux0 > > mem: > > nfslock: pseudo-device > > io: > > null: > > acpi0: on motherboard > > PCIe: Memory Mapped configuration base @ 0xe0000000 > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > > ACPI: Executed 1 blocks of module-level executable AML code > > acpi0: Power Button (fixed) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > acpi0: reservation of fee00000, 1000 (3) failed > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, bdd00000 (3) failed > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > cpu0: on acpi0 > > ACPI: SSDT 0xbdda04b0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > cpu1: on acpi0 > > ACPI: SSDT 0xbdda0420 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > > acpi_ec0: port 0x62,0x66 on acpi0 > > pci_link0: Index IRQ Rtd Ref IRQs > > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link1: Index IRQ Rtd Ref IRQs > > Initial Probe 0 5 N 0 5 > > Validation 0 5 N 0 5 > > After Disable 0 255 N 0 5 > > pci_link2: Index IRQ Rtd Ref IRQs > > Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link3: Index IRQ Rtd Ref IRQs > > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link4: Index IRQ Rtd Ref IRQs > > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link5: Index IRQ Rtd Ref IRQs > > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link6: Index IRQ Rtd Ref IRQs > > Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link7: Index IRQ Rtd Ref IRQs > > Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pcib0: port 0xcf8-0xcff on acpi0 > > pcib0: decoding 4 range 0-0xcf7 > > pcib0: decoding 4 range 0xd00-0xffff > > pcib0: decoding 3 range 0xa0000-0xbffff > > pcib0: decoding 3 range 0xd0000-0xdffff > > pcib0: decoding 3 range 0xbde00000-0xdfffffff > > pcib0: decoding 3 range 0xf0000000-0xfed8ffff > > pci0: on pcib0 > > pci0: domain=0, physical bus=0 > > found-> vendor=0x8086, dev=0x2a40, revid=0x07 > > domain=0, bus=0, slot=0, func=0 > > class=06-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2a42, revid=0x07 > > domain=0, bus=0, slot=2, func=0 > > class=03-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > map[10]: type Memory, range 64, base 0xfd800000, size 22, enabled > > pcib0: allocated type 3 (0xfd800000-0xfdbfffff) for rid 10 of pci0:0:2:0 > > map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled > > pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 > > map[20]: type I/O Port, range 32, base 0xb400, size 3, enabled > > pcib0: allocated type 4 (0xb400-0xb407) for rid 20 of pci0:0:2:0 > > pcib0: matched entry for 0.2.INTA > > pcib0: slot 2 INTA hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2a43, revid=0x07 > > domain=0, bus=0, slot=2, func=1 > > class=03-80-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > powerspec 3 supports D0 D3 current D0 > > map[10]: type Memory, range 64, base 0xfdd00000, size 20, enabled > > pcib0: allocated type 3 (0xfdd00000-0xfddfffff) for rid 10 of pci0:0:2:1 > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled > > pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:0 > > pcib0: matched entry for 0.26.INTA > > pcib0: slot 26 INTA hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=7 > > map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled > > pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:26:1 > > pcib0: matched entry for 0.26.INTB > > pcib0: slot 26 INTB hardwired to IRQ 21 > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > powerspec 2 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xfdefec00, size 10, enabled > > pcib0: allocated type 3 (0xfdefec00-0xfdefefff) for rid 10 of pci0:0:26:7 > > pcib0: matched entry for 0.26.INTC > > pcib0: slot 26 INTC hardwired to IRQ 18 > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=3 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > map[10]: type Memory, range 64, base 0xfdef8000, size 14, enabled > > pcib0: allocated type 3 (0xfdef8000-0xfdefbfff) for rid 10 of pci0:0:27:0 > > pcib0: matched entry for 0.27.INTA > > pcib0: slot 27 INTA hardwired to IRQ 22 > > found-> vendor=0x8086, dev=0x2940, revid=0x03 > > domain=0, bus=0, slot=28, func=0 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=5 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTA > > pcib0: slot 28 INTA hardwired to IRQ 17 > > found-> vendor=0x8086, dev=0x2942, revid=0x03 > > domain=0, bus=0, slot=28, func=1 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=10 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTB > > pcib0: slot 28 INTB hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2946, revid=0x03 > > domain=0, bus=0, slot=28, func=3 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=d, irq=11 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTD > > pcib0: slot 28 INTD hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=14 > > map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled > > pcib0: allocated type 4 (0xc000-0xc01f) for rid 20 of pci0:0:29:0 > > pcib0: matched entry for 0.29.INTA > > pcib0: slot 29 INTA hardwired to IRQ 23 > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=11 > > map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled > > pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:29:1 > > pcib0: matched entry for 0.29.INTB > > pcib0: slot 29 INTB hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled > > pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:29:2 > > pcib0: matched entry for 0.29.INTC > > pcib0: slot 29 INTC hardwired to IRQ 18 > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=14 > > powerspec 2 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xfdeff000, size 10, enabled > > pcib0: allocated type 3 (0xfdeff000-0xfdeff3ff) for rid 10 of pci0:0:29:7 > > pcib0: matched entry for 0.29.INTA > > pcib0: slot 29 INTA hardwired to IRQ 23 > > found-> vendor=0x8086, dev=0x2448, revid=0x93 > > domain=0, bus=0, slot=30, func=0 > > class=06-04-01, hdrtype=0x01, mfdev=0 > > cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2919, revid=0x03 > > domain=0, bus=0, slot=31, func=0 > > class=06-01-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2929, revid=0x03 > > domain=0, bus=0, slot=31, func=2 > > class=01-06-01, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=11 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 16 messages > > map[10]: type I/O Port, range 32, base 0xcc00, size 3, enabled > > pcib0: allocated type 4 (0xcc00-0xcc07) for rid 10 of pci0:0:31:2 > > map[14]: type I/O Port, range 32, base 0xc880, size 2, enabled > > pcib0: allocated type 4 (0xc880-0xc883) for rid 14 of pci0:0:31:2 > > map[18]: type I/O Port, range 32, base 0xc800, size 3, enabled > > pcib0: allocated type 4 (0xc800-0xc807) for rid 18 of pci0:0:31:2 > > map[1c]: type I/O Port, range 32, base 0xc480, size 2, enabled > > pcib0: allocated type 4 (0xc480-0xc483) for rid 1c of pci0:0:31:2 > > map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled > > pcib0: allocated type 4 (0xc400-0xc41f) for rid 20 of pci0:0:31:2 > > map[24]: type Memory, range 32, base 0xfdeff800, size 11, enabled > > pcib0: allocated type 3 (0xfdeff800-0xfdefffff) for rid 24 of pci0:0:31:2 > > pcib0: matched entry for 0.31.INTB > > pcib0: slot 31 INTB hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > map[10]: type Memory, range 64, base 0xfdeff400, size 8, enabled > > pcib0: allocated type 3 (0xfdeff400-0xfdeff4ff) for rid 10 of pci0:0:31:3 > > map[20]: type I/O Port, range 32, base 0x400, size 5, enabled > > pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 > > pcib0: matched entry for 0.31.INTC > > pcib0: slot 31 INTC hardwired to IRQ 18 > > vgapci0: port 0xb400-0xb407 mem 0xfd800000-0xfdbfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > > agp0: on vgapci0 > > agp0: aperture size is 256M, detected 32764k stolen memory > > vgapci1: mem 0xfdd00000-0xfddfffff at device 2.1 on pci0 > > pci0: at device 26.0 (no driver attached) > > pci0: at device 26.1 (no driver attached) > > pci0: at device 26.7 (no driver attached) > > pci0: at device 27.0 (no driver attached) > > pcib1: irq 17 at device 28.0 on pci0 > > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 > > pcib0: allocated type 3 (0xfdf00000-0xfdffffff) for rid 20 of pcib1 > > pcib0: allocated type 3 (0xf9f00000-0xf9ffffff) for rid 24 of pcib1 > > pcib1: domain 0 > > pcib1: secondary bus 2 > > pcib1: subordinate bus 2 > > pcib1: I/O decode 0xd000-0xdfff > > pcib1: memory decode 0xfdf00000-0xfdffffff > > pcib1: prefetched decode 0xf9f00000-0xf9ffffff > > pci2: on pcib1 > > pci2: domain=0, physical bus=2 > > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > > domain=0, bus=2, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 3 supports D0 D1 D2 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 2 messages in map 0x20 > > map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled > > pcib1: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 > > map[18]: type Memory, range 64, base 0xfdfff000, size 12, enabled > > pcib1: allocated memory range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 > > map[20]: type Prefetchable Memory, range 64, base 0xf9ff0000, size 16, enabled > > pcib1: allocated prefetch range (0xf9ff0000-0xf9ffffff) for rid 20 of pci0:2:0:0 > > pcib1: matched entry for 2.0.INTA > > pcib1: slot 0 INTA hardwired to IRQ 16 > > pci2: at device 0.0 (no driver attached) > > pcib2: irq 16 at device 28.1 on pci0 > > pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 > > pcib0: allocated type 3 (0xfe000000-0xfeafffff) for rid 20 of pcib2 > > pcib0: allocated type 3 (0xfa000000-0xfcffffff) for rid 24 of pcib2 > > pcib2: domain 0 > > pcib2: secondary bus 3 > > pcib2: subordinate bus 4 > > pcib2: I/O decode 0xe000-0xefff > > pcib2: memory decode 0xfe000000-0xfeafffff > > pcib2: prefetched decode 0xfa000000-0xfcffffff > > pci3: on pcib2 > > pci3: domain=0, physical bus=3 > > pcib3: irq 19 at device 28.3 on pci0 > > pcib0: allocated type 3 (0xfeb00000-0xfebfffff) for rid 20 of pcib3 > > pcib3: domain 0 > > pcib3: secondary bus 5 > > pcib3: subordinate bus 5 > > pcib3: memory decode 0xfeb00000-0xfebfffff > > pcib3: no prefetched decode > > pci5: on pcib3 > > pci5: domain=0, physical bus=5 > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=11 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > map[10]: type Memory, range 64, base 0xfebf0000, size 16, enabled > > pcib3: allocated memory range (0xfebf0000-0xfebfffff) for rid 10 of pci0:5:0:0 > > pcib3: matched entry for 5.0.INTA > > pcib3: slot 0 INTA hardwired to IRQ 19 > > pci5: at device 0.0 (no driver attached) > > pci0: at device 29.0 (no driver attached) > > pci0: at device 29.1 (no driver attached) > > pci0: at device 29.2 (no driver attached) > > pci0: at device 29.7 (no driver attached) > > pcib4: at device 30.0 on pci0 > > pcib4: domain 0 > > pcib4: secondary bus 1 > > pcib4: subordinate bus 1 > > pcib4: no prefetched decode > > pcib4: Subtractively decoded bridge. > > pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND > > pci1: on pcib4 > > pci1: domain=0, physical bus=1 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfdeff800-0xfdefffff irq 19 at device 31.2 on pci0 > > ahci0: attempting to allocate 1 MSI vectors (16 supported) > > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > > ahci0: using IRQ 256 for MSI > > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported > > ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 4ports > > ahci0: Caps2: > > ahci0: EM Caps: ALHD XMT SMB LED > > ahcich0: at channel 0 on ahci0 > > ahcich0: Caps: > > ahcich1: at channel 1 on ahci0 > > ahcich1: Caps: > > ahcich2: not probed (disabled) > > ahcich3: not probed (disabled) > > ahcich4: at channel 4 on ahci0 > > ahcich4: Caps: > > ahcich5: at channel 5 on ahci0 > > ahcich5: Caps: > > pci0: at device 31.3 (no driver attached) > > acpi_button0: on acpi0 > > acpi_tz0: on acpi0 > > attimer0: port 0x40-0x43 irq 0 on acpi0 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 > > Event timer "i8254" frequency 1193182 Hz quality 100 > > atrtc0: port 0x70-0x71 irq 8 on acpi0 > > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) > > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 51 > > Event timer "RTC" frequency 32768 Hz quality 0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > atkbd: the current kbd controller command byte 0065 > > atkbd: keyboard ID 0x41ab (2) > > kbd0 at atkbd0 > > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 52 > > atkbd0: [GIANT-LOCKED] > > psm0: unable to allocate IRQ > > psmcpnp0: irq 12 on acpi0 > > psm0: current command byte:0065 > > psm0: irq 12 on atkbdc0 > > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 53 > > psm0: [GIANT-LOCKED] > > psm0: model IntelliMouse, device ID 3-00, 3 buttons > > psm0: config:00000000, flags:00000008, packet size:4 > > psm0: syncmask:08, syncbits:00 > > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route > > hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic > > hpet0: t1: irqs 0x00f00000 (0) > > hpet0: t2: irqs 0x00f00800 (0) > > hpet0: t3: irqs 0x00f01000 (0) > > Timecounter "HPET" frequency 14318180 Hz quality 950 > > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 > > Event timer "HPET" frequency 14318180 Hz quality 450 > > Event timer "HPET1" frequency 14318180 Hz quality 440 > > Event timer "HPET2" frequency 14318180 Hz quality 440 > > Event timer "HPET3" frequency 14318180 Hz quality 440 > > acpi_acad0: on acpi0 > > battery0: on acpi0 > > acpi_lid0: on acpi0 > > acpi_button1: on acpi0 > > acpi0: wakeup code va 0xffffff80d4544000 pa 0x4000 > > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 > > isa_probe_children: disabling PnP devices > > atkbdc: atkbdc0 already exists; skipping it > > atrtc: atrtc0 already exists; skipping it > > attimer: attimer0 already exists; skipping it > > sc: sc0 already exists; skipping it > > isa_probe_children: probing non-PnP devices > > orm0: at iomem 0xc0000-0xcf7ff on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > ppc0 failed to probe at irq 7 on isa0 > > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > > uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 > > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > > isa_probe_children: probing PnP devices > > Device configuration finished. > > procfs registered > > Timecounters tick every 1.000 msec > > vlan: initialized, using hash tables with chaining > > lo0: bpf attached > > ahcich0: AHCI reset... > > ahcich0: SATA connect time=100us status=00000123 > > ahcich0: AHCI reset: device found > > ahcich1: AHCI reset... > > ahcich1: SATA offline status=00000004 > > ahcich1: AHCI reset: device not found > > ahcich4: AHCI reset... > > ahcich4: SATA offline status=00000004 > > ahcich4: AHCI reset: device not found > > ahcich5: AHCI reset... > > ahcich5: SATA connect time=900us status=00000113 > > ahcich5: AHCI reset: device found > > ahcich5: AHCI reset: device ready after 0ms > > (aprobe1:ahcich5:0:0:0): SIGNATURE: eb14 > > acpi_acad0: acline initialization start > > battery0: battery initialization start > > acpi_acad0: On Line > > acpi_acad0: acline initialization done, tried 1 times > > ahcich5: SNTF 0x0001 > > ahcich0: AHCI reset: device ready after 100ms > > (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > pass0: ATA-8 SATA 2.x device > > GEOM: new disk cd0 > > pass0: Serial Number 5YX0J5YD > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: Serial Number 30651780 1165921Q111 > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open > > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > pass0: Command Queueing enabled > > pass1 at ahcich5 bus 0 scbus3 target 0 lun 0 > > pass1: Removable CD-ROM SCSI-0 device > > pass1: Serial Number 30651780 1165921Q111 > > pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > ada0: ATA-8 SATA 2.x device > > ada0: Serial Number 5YX0J5YD > > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad4 > > SMP: AP CPU #1 Launched! > > cpu1 AP: > > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > > TSC timecounter disabled: C3 enabled. > > Timecounter "TSC" frequency 2161296371 Hz quality -1000 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:battery0: battery initialization done, tried 1 times > > 0:0): Error 6, Unretryable error > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > GEOM: new disk ada0 > > GEOM: ada0s3: media size does not match label. > > Trying to mount root from ufs:/dev/ada0s2a [rw,noatime]... > > start_init: trying /sbin/init > > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > > ZFS filesystem version 5 > > ZFS storage pool version 28 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > tap0: bpf attached > > tap0: Ethernet address: 00:bd:0b:07:00:00 > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > > domain=0, bus=2, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > powerspec 3 supports D0 D1 D2 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 2 messages in map 0x20 > > pci0:2:0:0: reprobing on driver added > > re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xf9ff0000-0xf9ffffff irq 16 at device 0.0 on pci2 > > re0: MSI count : 1 > > re0: MSI-X count : 2 > > re0: attempting to allocate 1 MSI-X vectors (2 supported) > > msi: routing MSI-X IRQ 257 to local APIC 0 vector 55 > > re0: using IRQ 257 for MSI-X > > re0: Using 1 MSI-X message > > re0: ASPM disabled > > re0: Chip rev. 0x3c000000 > > re0: MAC rev. 0x00400000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > re0: bpf attached > > re0: Ethernet address: 00:24:21:61:e0:20 > > pci3: driver added > > pci5: driver added > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=19 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > pci0:5:0:0: reprobing on driver added > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci3: driver added > > pci5: driver added > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=19 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > pci0:5:0:0: reprobing on driver added > > ath0: mem 0xfebf0000-0xfebfffff irq 19 at device 0.0 on pci5 > > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 56 > > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > ath0: Use hw queue 1 for WME_AC_BE traffic > > ath0: Use hw queue 0 for WME_AC_BK traffic > > ath0: Use hw queue 2 for WME_AC_VI traffic > > ath0: Use hw queue 3 for WME_AC_VO traffic > > ath0: Use hw queue 8 for CAB traffic > > ath0: Use hw queue 9 for beacons > > ath0: using multicast key search > > crypto: > > cryptosoft0: on motherboard > > crypto: assign cryptosoft0 driver id 0, flags 100663296 > > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > > GEOM_ELI: Device ada0s3.eli created. > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: software > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci3: driver added > > pci5: driver added > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > p4tcc0: on cpu0 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > coretemp0: on cpu0 > > coretemp0: Setting TjMax=100 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > coretemp1: on cpu1 > > coretemp1: Setting TjMax=100 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > -- > > Arno J. Klaassen > > SCITO S.A. > 8 rue des Haies > F-75020 Paris, France > http://scito.com > _______________________________________________ > 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 Tue Feb 14 18:31:59 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 C80E31065688 for ; Tue, 14 Feb 2012 18:31:59 +0000 (UTC) (envelope-from fauzi.fanny@yahoo.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id A04A88FC16 for ; Tue, 14 Feb 2012 18:31:58 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RxMrM-0003wa-0f for freebsd-fs@freebsd.org; Tue, 14 Feb 2012 10:12:12 -0800 Date: Tue, 14 Feb 2012 10:12:12 -0800 (PST) From: fannyfauzi To: freebsd-fs@freebsd.org Message-ID: <1329243132007-5483280.post@n5.nabble.com> In-Reply-To: References: <20101213143030.GE1740@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: HAST role failure 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, 14 Feb 2012 18:31:59 -0000 Hi, I have the same errors with you, could you share how to fix it? thanks alot xiaoxi# hastctl status all shared: role: init provname: shared localpath: /dev/ada0p4 extentsize: 0 (0B) keepdirty: 0 remoteaddr: tcp4://192.168.208.132 replication: fullsync dirty: 0 (0B) statistics: reads: 0 writes: 0 deletes: 0 flushes: 0 activemap updates: 0 xiaoxi# Feb 15 02:03:03 xiaoxi hastd[2184]: [shared] (primary) Unable to read metadata from /dev/ada0p4: No such file or directory. Feb 15 02:03:08 xiaoxi hastd[2182]: [shared] (primary) Worker process exited ungracefully (pid=2184, exitcode=66). fauzi -- View this message in context: http://freebsd.1045724.n5.nabble.com/HAST-role-failure-tp4033049p5483280.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 18:54: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 DDE4B1065678; Tue, 14 Feb 2012 18:54:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 463378FC1F; Tue, 14 Feb 2012 18:54:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1EIsKiN062109 ; Tue, 14 Feb 2012 19:54:20 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1EIrhgw084894; Tue, 14 Feb 2012 19:53:44 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1EIrhIq084891; Tue, 14 Feb 2012 19:53:43 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Tue, 14 Feb 2012 19:53:43 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3AADDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3AADDC.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 18:54:26 -0000 Hi, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? I just started it; will take some hours > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? I deleted the XNAT.tar; I also copied files by 'ssh tar -c | tar -xp' to rule out NFS, same type of errors; Looks like multiple scrubs give the same files but not the same number of chksum errors (to be confirmed) > 3) Can you try zfs without geli? sure, I will split the place in one partition with geli and one without > 4) Is the slice/partition layout definitely correct? I (still ???) use sysinstall to do the dirty computations in my place. This is what gpart says (looks OK (to me ...) : [root@cc ~]# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 976773167 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada0s1 Mediasize: 40802001408 (38G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 rawtype: 7 length: 40802001408 offset: 32256 type: ntfs index: 1 end: 79691471 start: 63 2. Name: ada0s2 Mediasize: 34359607296 (32G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2147328000 Mode: r3w3e5 attrib: active rawtype: 165 length: 34359607296 offset: 40802033664 type: freebsd index: 2 end: 146800079 start: 79691472 3. Name: ada0s3 Mediasize: 424946221056 (395G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2147196928 Mode: r1w1e1 rawtype: 165 length: 424946221056 offset: 75161640960 type: freebsd index: 3 end: 976773167 start: 146800080 Consumers: 1. Name: ada0 Mediasize: 500107862016 (465G) Sectorsize: 512 Mode: r4w4e10 Merci, Arno > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > >> > [ dmesg.boot deleted ] From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 19:46: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 8E2AF1065696 for ; Tue, 14 Feb 2012 19:46:17 +0000 (UTC) (envelope-from to.my.trociny@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 152208FC1C for ; Tue, 14 Feb 2012 19:46:16 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so421177bkc.13 for ; Tue, 14 Feb 2012 11:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=pcyCQe6UCULHG6a0Es0dGoUUceLtBq5kTNzrJQQ0Te0=; b=t3zyRZZ7QkMhOmS9xgo4rbCyBIxaIlIHJeA88D+Lapx//lUlOJCqhM9Of8zqbCToTp +EjGG86WuaOCOPvMp5JtBiyxB1Bck8QNxcoWxcpu/Yei0FVVBiJllcWtK8M/l3F9Jyp7 cAc9AOapNKjGexQULvbAtmbasMi4tZ0S8tq0o= Received: by 10.204.152.75 with SMTP id f11mr9771465bkw.127.1329246985101; Tue, 14 Feb 2012 11:16:25 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id ut6sm1212621bkb.14.2012.02.14.11.16.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 11:16:23 -0800 (PST) From: Mikolaj Golub To: fannyfauzi References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> X-Comment-To: fannyfauzi Sender: Mikolaj Golub Date: Tue, 14 Feb 2012 21:16:20 +0200 In-Reply-To: <1329243132007-5483280.post@n5.nabble.com> (fannyfauzi's message of "Tue, 14 Feb 2012 10:12:12 -0800 (PST)") Message-ID: <861upxmdiz.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: HAST role failure 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, 14 Feb 2012 19:46:17 -0000 On Tue, 14 Feb 2012 10:12:12 -0800 (PST) fannyfauzi wrote: f> Hi, I have the same errors with you, could you share how to fix it? thanks f> alot f> xiaoxi# hastctl status all f> shared: f> role: init f> provname: shared f> localpath: /dev/ada0p4 f> extentsize: 0 (0B) f> keepdirty: 0 f> remoteaddr: tcp4://192.168.208.132 f> replication: fullsync f> dirty: 0 (0B) f> statistics: f> reads: 0 f> writes: 0 f> deletes: 0 f> flushes: 0 f> activemap updates: 0 f> xiaoxi# f> Feb 15 02:03:03 xiaoxi hastd[2184]: [shared] (primary) Unable to read f> metadata from /dev/ada0p4: No such file or directory. f> Feb 15 02:03:08 xiaoxi hastd[2182]: [shared] (primary) Worker process exited f> ungracefully (pid=2184, exitcode=66). And does /dev/ada0p4 device exist? -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 21:05:53 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 8ECE6106567A; Tue, 14 Feb 2012 21:05:53 +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 268E7151DDE; Tue, 14 Feb 2012 21:05:24 +0000 (UTC) Message-ID: <4F3ACC91.7030104@FreeBSD.org> Date: Tue, 14 Feb 2012 13:05:21 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: Rick Macklem References: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <511955909.1353483.1329237591261.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, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 21:05:53 -0000 On 02/14/2012 08:39, Rick Macklem wrote: > I took a look and they seem to have been MFC'd. That's awesome! Thanks for your time on this. I guess we've got some upgrading to do. 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 Tue Feb 14 21:15:37 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 7D33F1065673; Tue, 14 Feb 2012 21:15:37 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27A738FC0A; Tue, 14 Feb 2012 21:15:36 +0000 (UTC) Received: by yhfs35 with SMTP id s35so378403yhf.13 for ; Tue, 14 Feb 2012 13:15:36 -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=E7TU/leN2G4Pe0CgnPBrogB2qjvQd/G20JyFb/Q2abs=; b=lQ/pmBN2tguhveZiMdKUYPCuPPa3BLgDtfEjAyo91Oc2I5QBy13Jeipza3OaehoeYC ATtKbkjkYK1xiio08Ebdlqvjvju3yaUJOgpLTi+9Gh3ZGNe2mC4DmYLoFqIQMQ5kyDpw MD/PjVemcrJW3lV/kkPJQ8JamzyJEhpTTqZ2w= MIME-Version: 1.0 Received: by 10.50.94.228 with SMTP id df4mr38023170igb.12.1329254135369; Tue, 14 Feb 2012 13:15:35 -0800 (PST) Received: by 10.231.231.17 with HTTP; Tue, 14 Feb 2012 13:15:35 -0800 (PST) In-Reply-To: <861upxmdiz.fsf@kopusha.home.net> References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> <861upxmdiz.fsf@kopusha.home.net> Date: Tue, 14 Feb 2012 23:15:35 +0200 Message-ID: From: George Kontostanos To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mikolaj Golub , fannyfauzi Subject: Re: HAST role failure 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, 14 Feb 2012 21:15:37 -0000 On Tue, Feb 14, 2012 at 9:16 PM, Mikolaj Golub wrote: > > On Tue, 14 Feb 2012 10:12:12 -0800 (PST) fannyfauzi wrote: > > =A0f> Hi, I have the same errors with you, could you share how to fix it?= thanks > =A0f> alot > > =A0f> xiaoxi# hastctl status all > =A0f> shared: > =A0f> =A0 role: init > =A0f> =A0 provname: shared > =A0f> =A0 localpath: /dev/ada0p4 > =A0f> =A0 extentsize: 0 (0B) > =A0f> =A0 keepdirty: 0 > =A0f> =A0 remoteaddr: tcp4://192.168.208.132 > =A0f> =A0 replication: fullsync > =A0f> =A0 dirty: 0 (0B) > =A0f> =A0 statistics: > =A0f> =A0 =A0 reads: 0 > =A0f> =A0 =A0 writes: 0 > =A0f> =A0 =A0 deletes: 0 > =A0f> =A0 =A0 flushes: 0 > =A0f> =A0 =A0 activemap updates: 0 > =A0f> xiaoxi# > > =A0f> Feb 15 02:03:03 xiaoxi hastd[2184]: [shared] (primary) Unable to re= ad > =A0f> metadata from /dev/ada0p4: No such file or directory. > =A0f> Feb 15 02:03:08 xiaoxi hastd[2182]: [shared] (primary) Worker proce= ss exited > =A0f> ungracefully (pid=3D2184, exitcode=3D66). > > And does /dev/ada0p4 device exist? > > -- > Mikolaj Golub > _______________________________________________ > 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" Well, even if it does I doubt that the hast resource was declared and initialized properly since it is points to a partition rather than a specific vdev. HAST resources should point to devices. Once HAST has been initialized you can then partition the resource under /dev/hast/ directory. Regards --=20 George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 22:05: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 AEBDF106564A for ; Tue, 14 Feb 2012 22:05:16 +0000 (UTC) (envelope-from nowakpl@platinum.linux.pl) Received: from platinum.linux.pl (platinum.edu.pl [81.161.192.4]) by mx1.freebsd.org (Postfix) with ESMTP id 641768FC08 for ; Tue, 14 Feb 2012 22:05:16 +0000 (UTC) Received: by platinum.linux.pl (Postfix, from userid 87) id 9E63747E1A; Tue, 14 Feb 2012 22:48:50 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on platinum.linux.pl X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.3.2 Received: from [172.19.191.2] (078088011125.bialystok.vectranet.pl [78.88.11.125]) by platinum.linux.pl (Postfix) with ESMTPA id 8C34847E14 for ; Tue, 14 Feb 2012 22:48:44 +0100 (CET) Message-ID: <4F3AD6B1.9050609@platinum.linux.pl> Date: Tue, 14 Feb 2012 22:48:33 +0100 From: Adam Nowacki User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 22:05:16 -0000 It appears that zfs detects mismatch between data stored on the disk and checksum of what should be there. With a single disk setup like you have here there is nothing more to do than to delete the file and restore from a backup if you have one. When the error occured, what caused it or is the error in data or checksum you'll probably never know. On 2012-02-11 16:53, Arno J. Klaassen wrote: > > Hello, > > > I finally decided to 'play' a bit with ZFS on a notebook, some years > old, but I installed a brand new disk and memtest passes OK. > > I installed base+ports on partition 2, using 'classical' UFS. > > I crypted partition 3 and created a single zpool on it containing > 4 Z-"file-systems" : > > [root@cc ~]# zfs list > NAME USED AVAIL REFER MOUNTPOINT > zfiles 10.7G 377G 152K /zfiles > zfiles/home 10.6G 377G 119M /zfiles/home > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito > > > I export the ZFS's via nfs and rsynced on the other machine some backup > of my current note-book (geli + UFS, (almost) same 9-stable version, no > problem) to the ZFS's. > > > Quite fast, I see on the notebook : > > > [root@cc /usr/temp]# zpool status -v > pool: zfiles > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 > 2012 > config: > > NAME STATE READ WRITE CKSUM > zfiles ONLINE 0 0 11 > ada0s3.eli ONLINE 0 0 23 > > errors: Permanent errors have been detected in the following files: > > /zfiles/home/arno/.scito/contrib/XNAT.tar > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error > [root@cc /usr/temp]# > > > As said, memtest is OK, nothing is logged to the console, UFS on the > same disk works OK (I did some tests copying and comparing random data) > and smartctl as well seems to trust the disk : > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > # 1 Extended offline Completed without error 00% 388 > # 2 Short offline Completed without error 00% 387 > > > Am I doing something wrong and/or let me know what I could provide as > extra info to try to solve this (dmesg.boot at the end of this mail). > > Thanx a lot in advance, > > best, Arno From owner-freebsd-fs@FreeBSD.ORG Tue Feb 14 23:33: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 558F91065700; Tue, 14 Feb 2012 23:33:55 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1C81E8FC12; Tue, 14 Feb 2012 23:33:54 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id q1ENQO1m005548; Tue, 14 Feb 2012 17:33:53 -0600 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com with ESMTP id 1300fgg60x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 17:33:53 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 17:33:52 -0600 From: Devin Teske To: "'Doug Barton'" , "'Rick Macklem'" References: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> <4F3ACC91.7030104@FreeBSD.org> In-Reply-To: <4F3ACC91.7030104@FreeBSD.org> Date: Tue, 14 Feb 2012 15:33:58 -0800 Message-ID: <09bf01cceb71$207a2790$616e76b0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSc4LeLj7QlldhfqGzt105NKM1bAJFPsjSlx/QMhA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_06:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: RE: Why won't 8.2 umount -f? 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, 14 Feb 2012 23:33:55 -0000 > -----Original Message----- > From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] > On Behalf Of Doug Barton > Sent: Tuesday, February 14, 2012 1:05 PM > To: Rick Macklem > Cc: freebsd-fs@FreeBSD.org; freebsd-stable@FreeBSD.org > Subject: Re: Why won't 8.2 umount -f? > > On 02/14/2012 08:39, Rick Macklem wrote: > > I took a look and they seem to have been MFC'd. > > That's awesome! Thanks for your time on this. I guess we've got some > upgrading to do. > +1 Awaiting 8.3 with bated breath! -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 02:35:11 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 6C2F11065680 for ; Wed, 15 Feb 2012 02:35:11 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 570458FC21 for ; Wed, 15 Feb 2012 02:35: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 q1F2ZBtL046750 for ; Wed, 15 Feb 2012 02:35:11 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1F2ZBFS046749 for freebsd-fs@freebsd.org; Wed, 15 Feb 2012 02:35:11 GMT (envelope-from jwd) Date: Wed, 15 Feb 2012 02:35:11 +0000 From: John To: freebsd-fs@freebsd.org Message-ID: <20120215023511.GA7613@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Enable chown by non-root users over NFS 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, 15 Feb 2012 02:35:11 -0000 Hi Folks, We have a $NFS_FILESERVER we're trying to replace with a ZFS based system. Everything works quite well except for some processes which fail trying to give away ownership of a file. In this instance, $NFS_FILESERVER has a system level option, root_only_chown, which is disabled, which allows the chown ownership giveaways to work. (Yes, it's a security issue. No, I can't change the process). Note, this is not a maproot issue. Wrong rabbit hole :-) I've started poking through the code. Also thought I'd ask here if anyone has run into this issue and how they solved it, or if anyone has any suggestions. Feel free to tell me I'm missing something obvious also... Thanks, John From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 03:06: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 242BE106564A for ; Wed, 15 Feb 2012 03:06:27 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id DA3CC8FC08 for ; Wed, 15 Feb 2012 03:06:26 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q1F36PxZ020522; Tue, 14 Feb 2012 21:06:25 -0600 (CST) Date: Tue, 14 Feb 2012 21:06:25 -0600 (CST) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Adam Nowacki In-Reply-To: <4F3AD6B1.9050609@platinum.linux.pl> Message-ID: References: <4F3AD6B1.9050609@platinum.linux.pl> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 14 Feb 2012 21:06:25 -0600 (CST) Cc: freebsd-fs@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 15 Feb 2012 03:06:27 -0000 On Tue, 14 Feb 2012, Adam Nowacki wrote: > It appears that zfs detects mismatch between data stored on the disk and > checksum of what should be there. With a single disk setup like you have here > there is nothing more to do than to delete the file and restore from a backup > if you have one. When the error occured, what caused it or is the error in > data or checksum you'll probably never know. If a particular filesystem is deemed to be particularly important, but there is just one disk, then setting the zfs filesystem attribute 'copies' to 2 or 3 will dramatically reduce the odds of data loss if there is minor media failure. The attribute needs to be set before the data is written. If the whole disk goes, then everything is still lost. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 03:08: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 D52D8106564A; Wed, 15 Feb 2012 03:08:05 +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 73A238FC15; Wed, 15 Feb 2012 03:08:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EALMgO0+DaFvO/2dsb2JhbABDhRCsUoFyAQEBAwEBAQEgBCcgCwUWGAICDRkCKQEJJgYIBwQBHASHWwmnQpFzgS+KNQcBBAEOAwYVAggHAQICCQwCCgIDChEDgxJlAoI0gRYEiEuKQYIokwQ X-IronPort-AV: E=Sophos;i="4.73,421,1325480400"; d="scan'208";a="159608889" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 14 Feb 2012 22:08:04 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 69AF0B3F25; Tue, 14 Feb 2012 22:08:04 -0500 (EST) Date: Tue, 14 Feb 2012 22:08:04 -0500 (EST) From: Rick Macklem To: John Message-ID: <465555006.1396842.1329275284383.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120215023511.GA7613@FreeBSD.org> 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 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: Enable chown by non-root users over NFS 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, 15 Feb 2012 03:08:05 -0000 John wrote: > Hi Folks, > > We have a $NFS_FILESERVER we're trying to replace with a ZFS based > system. Everything works quite well except for some processes which > fail > trying to give away ownership of a file. > > In this instance, $NFS_FILESERVER has a system level option, > root_only_chown, > which is disabled, which allows the chown ownership giveaways to work. > (Yes, it's a security issue. No, I can't change the process). Note, > this is > not a maproot issue. Wrong rabbit hole :-) > > I've started poking through the code. Also thought I'd ask here if > anyone has run into this issue and how they solved it, or if anyone > has any suggestions. Feel free to tell me I'm missing something > obvious > also... > Well, at least for NFSv3 (NFSv4 has some further checks I'd have to look at), this is allowed/not allowed by the underlying file system. (I have no idea if ZFS can be changed easily to allow this?) If ZFS only allows root to chown and you want to allow it, you could hack nfsrvd_setattr() to use cred for root to do the nfsvno_setatt() for this case. nva2.na_uid is who owns the file before the setattr nd->nd_cred->cr_uid is who is trying to do the chown nva.na_uid != VNOVAL is what it is trying to change it to You can rootcred = newnfs_getcred(); /* get new root cred. */ NFSFREECRED(rootcred); /* to release them when done. */ For an NFSv3 specific change, you can put this stuff just before/after nfsvno_setattr() for the "else" case, after all the NFSv4 calls. If you want the hack and can't figure out how to do it, I can do it for you. Just email. rick > Thanks, > John > > > _______________________________________________ > 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 Feb 15 06:27: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 AA3DA106566B for ; Wed, 15 Feb 2012 06:27:09 +0000 (UTC) (envelope-from fauzi.fanny@yahoo.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC5E8FC08 for ; Wed, 15 Feb 2012 06:27:09 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RxYKa-0001zh-UY for freebsd-fs@freebsd.org; Tue, 14 Feb 2012 22:27:08 -0800 Date: Tue, 14 Feb 2012 22:27:08 -0800 (PST) From: fannyfauzi To: freebsd-fs@freebsd.org Message-ID: <1329287228940-5485041.post@n5.nabble.com> In-Reply-To: References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> <861upxmdiz.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: HAST role failure 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, 15 Feb 2012 06:27:09 -0000 Hi, And does /dev/ada0p4 device exist? yeah.. the previous i did 'umount /dev/ada0p4'.. and i returned to 'mount /dev/ada0p4' xiaoxi# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ada0p2 9.9G 6.2G 2.9G 68% / devfs 1.0k 1.0k 0B 100% /dev /dev/ada0p3 4G 32M 3.6G 1% /home /dev/ada0p4 4G 32M 3.6G 1% /shared xiaoxi# hastctl role primary shared xiaoxi# hastctl status shared shared: role: init provname: shared localpath: /dev/ada0p4 extentsize: 0 (0B) keepdirty: 0 remoteaddr: tcp4://192.168.208.132 replication: fullsync dirty: 0 (0B) statistics: reads: 0 writes: 0 deletes: 0 flushes: 0 activemap updates: 0 Feb 15 14:17:18 xiaoxi hastd[66931]: [shared] (primary) Unable to open /dev/ada0p4: Operation not permitted. I have ufs partition on /dev/ada0p4 /dev/ada0p4 /shared ufs rw 2 2 should i delete ufs partition on /dev/ada0p4 or any other advices? -- View this message in context: http://freebsd.1045724.n5.nabble.com/HAST-role-failure-tp4033049p5485041.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 06:59: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 C05141065672; Wed, 15 Feb 2012 06:59:16 +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 03D948FC12; Wed, 15 Feb 2012 06:59:15 +0000 (UTC) Received: from [192.92.129.180] ([192.92.129.180]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q1F6x56P017906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Feb 2012 08:59:10 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Daniel Kalchev In-Reply-To: Date: Wed, 15 Feb 2012 08:59:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> <861upxmdiz.fsf@kopusha.home.net> To: George Kontostanos X-Mailer: Apple Mail (2.1257) Cc: freebsd-fs@freebsd.org, Mikolaj Golub , fannyfauzi Subject: Re: HAST role failure 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, 15 Feb 2012 06:59:16 -0000 On Feb 14, 2012, at 11:15 PM, George Kontostanos wrote: > > Well, even if it does I doubt that the hast resource was declared and > initialized properly since it is points to a partition rather than a > specific vdev. HAST works on geom providers and thus works happily on an partition. Daniel From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:04: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 B471C1065675; Wed, 15 Feb 2012 10:04:23 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 674148FC19; Wed, 15 Feb 2012 10:04:23 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so1632227obc.13 for ; Wed, 15 Feb 2012 02:04:23 -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=zzQpNuDJ1Hfkry01hs1vvtX86BC0LL6BksIkoCppSB0=; b=tv7gOTnQuFMqEWmlKs4Wct4rEkB73ZWowsUkYCWRT/XaIC+Tb0NcSZUasG9MnBL7w8 3hmUE0IJuFvL4ZZXOTAcTv6nqcZGCNI/as96nOLrQvrdYzb7zCugnk8Oq0pSDM04e1H2 MgZ1xMf4ZejZIwLWMJaXJLdf2guDhbDsG4Icg= MIME-Version: 1.0 Received: by 10.50.15.231 with SMTP id a7mr40035775igd.8.1329300262923; Wed, 15 Feb 2012 02:04:22 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 02:04:22 -0800 (PST) In-Reply-To: References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> <861upxmdiz.fsf@kopusha.home.net> Date: Wed, 15 Feb 2012 12:04:22 +0200 Message-ID: From: George Kontostanos To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org, Mikolaj Golub , fannyfauzi Subject: Re: HAST role failure 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, 15 Feb 2012 10:04:23 -0000 On Wed, Feb 15, 2012 at 8:59 AM, Daniel Kalchev wrote: > > On Feb 14, 2012, at 11:15 PM, George Kontostanos wrote: > >> >> Well, even if it does I doubt that the hast resource was declared and >> initialized properly since it is points to a partition rather than a >> specific vdev. > > > HAST works on geom providers and thus works happily on an partition. > > Daniel Yes it does but you really shouldn't access directly that partition. You should use /dev/hast/(resource) instead. Regards -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:11: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 EF08F1065670 for ; Wed, 15 Feb 2012 10:11:23 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe12.ukr.net (ffe12.ukr.net [195.214.192.40]) by mx1.freebsd.org (Postfix) with ESMTP id DA1AB8FC16 for ; Wed, 15 Feb 2012 10:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=oS3MZdex1NkqU9Vz0HKf1guB5As9QldWUiGkR/VqJ74=; b=IC0v0H0ItRnKGsI8kN3Xhwe9ilDOjWOC3d5Yo1YBGicNydHvT0fbdr9Fxpl0MRPEsz69fERIemKl07r0h8efzvnDMpaU3uOZ31NPpxIgdKzJ2ltd5l4pfSAd8dIAaDTZO+7ukZnJvlvwpqVhr1VL7ONZHr8BlurVb/Ca4gSlSIk=; Received: from mail by ffe12.ukr.net with local ID 1RxbLQ-0004Hp-23 for freebsd-fs@freebsd.org; Wed, 15 Feb 2012 11:40:12 +0200 MIME-Version: 1.0 To: freebsd-fs@freebsd.org From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <15861.1329298812.1414986334451204096@ffe12.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 11:40:12 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS and mem management 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, 15 Feb 2012 10:11:24 -0000 Hello. We have an issue with memory management on FreeBSD and i suspect it is related to FS. We are using ZFS, here quick stats: zpool status pool: disk1 state: ONLINE scan: resilvered 657G in 8h30m with 0 errors on Tue Feb 14 21:17:37 2012 config: NAME STATE READ WRITE CKSUM disk1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk6 ONLINE 0 0 0 gpt/disk8 ONLINE 0 0 0 gpt/disk10 ONLINE 0 0 0 gpt/disk12 ONLINE 0 0 0 mirror-7 ONLINE 0 0 0 gpt/disk14 ONLINE 0 0 0 gpt/disk15 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: resilvered 34.9G in 0h11m with 0 errors on Tue Feb 14 12:57:52 2012 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/sys0 ONLINE 0 0 0 gpt/sys1 ONLINE 0 0 0 errors: No known data errors ------------------------------------------------------------------------ System Memory: 0.95% 75.61 MiB Active, 0.24% 19.02 MiB Inact 18.25% 1.41 GiB Wired, 0.01% 480.00 KiB Cache 80.54% 6.24 GiB Free, 0.01% 604.00 KiB Gap Real Installed: 8.00 GiB Real Available: 99.84% 7.99 GiB Real Managed: 96.96% 7.74 GiB Logical Total: 8.00 GiB Logical Used: 21.79% 1.74 GiB Logical Free: 78.21% 6.26 GiB Kernel Memory: 1.18 GiB Data: 99.05% 1.17 GiB Text: 0.95% 11.50 MiB Kernel Memory Map: 4.39 GiB Size: 23.32% 1.02 GiB Free: 76.68% 3.37 GiB ------------------------------------------------------------------------ ------------------------------------------------------------------------ ZFS Subsystem Report Wed Feb 15 10:53:03 2012 ------------------------------------------------------------------------ System Information: Kernel Version: 802516 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 28 ZFS Filesystem Version: 5 FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root 10:53AM up 56 mins, 6 users, load averages: 0.00, 0.00, 0.00 ------------------------------------------------------------------------ Background: we are using some tool that does indexing of some data and then pushes it into database (currently bdb-5.2). Instances of indexer are running continuously one after another. Time of indexing for one instance of indexer may vary between 2 seconds and 30 minutes. But mostly it is below one minute. There is nothing else running on the machine except system stuff and daemons. After several hours of indexing i can see a lot of active memory, it's ok. Then i check the number of vnodes. and it's really huge: 300k+ even tho nobody has so many opened files. Reading docs and googling i figured that's because of cached pages that reside in memory (unmounting of disk causes whole memory to be freed). Also I figured that happens only when I am accessing files via mmap(). Looks like pretty legit behaviour but the issue is: This spectacle continues (approximately for 12 hours) unlit indexers began to be killed out of swap. As I wrote above I observe a lot of used vnodes and like 7GB of active memory. I made a tool that allocates memory using malloc() to check what's the limit of available memory that can be allocated. It is several megabytes, sometimes more. Unless that tool gets killed out of swap as well. So how i can see the issue: for some reason after some process had exited normally all mapped pages don't get freed. I red about and I agree that this is reasonable behaviour if we have spare memory. But following this logic these pages can be flushed back to file at any time when system is under stress conditions. So when I ask for a piece of RAM, OS should do that trick and give me what I ask. But that's never happens. Those pages are like frozen. Until I unmount disk. Even after there is not a single instance of indexer running. I believe all this is caused by mmap() for sure : BDB uses mmap() for accessing databases and we tested indexing with out pushing data to DB. Worked shiny. You may suggest that that's something wrong with BDB. But we have some more tools of ours that using mmap() as well and the behaviour is exact. Thank you. Paul, Ukraine. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:21: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 378FE1065672 for ; Wed, 15 Feb 2012 10:21:32 +0000 (UTC) (envelope-from gkontos.mail@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 F27428FC15 for ; Wed, 15 Feb 2012 10:21:31 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id o4so1623027iae.13 for ; Wed, 15 Feb 2012 02:21:31 -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=i9ZS6xlY9JcU0NY3Rcana2QdUH9/L0bDWsf8eDlD0OY=; b=kHvrylJSLvXSVQbNlsQtSyVq3yChX6ubR3gMxfuGlrDdsO46SDpsB3JnrBfBQVAIOd EovfFDh1+NfB6Umm4+Vtjva9CiBYK0fIERZf7kijvlAOffOxHtQoRxjt3NLrAF8PKglY uiMweXo3nUPhFBeJhzLt9KBPiyUHeS6WauWls= MIME-Version: 1.0 Received: by 10.50.94.228 with SMTP id df4mr40931225igb.12.1329301291734; Wed, 15 Feb 2012 02:21:31 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 02:21:31 -0800 (PST) In-Reply-To: <15861.1329298812.1414986334451204096@ffe12.ukr.net> References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> Date: Wed, 15 Feb 2012 12:21:31 +0200 Message-ID: From: George Kontostanos To: Pavlo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 10:21:32 -0000 2012/2/15 Pavlo : > > > > Hello. > > We have an issue with memory management on FreeBSD and i suspect it is > related to FS. > We are using ZFS, here quick stats: > > > zpool status > pool: disk1 > state: ONLINE > scan: resilvered 657G in 8h30m with 0 errors on Tue Feb 14 21:17:37 2012 > config: > > NAME =A0 =A0 =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > disk1 =A0 =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > mirror-0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk1 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk2 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk4 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk6 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk8 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk10 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk12 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > mirror-7 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk14 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/disk15 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > errors: No known data errors > > pool: zroot > state: ONLINE > scan: resilvered 34.9G in 0h11m with 0 errors on Tue Feb 14 12:57:52 2012 > config: > > NAME =A0 =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > zroot =A0 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > mirror-0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/sys0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > gpt/sys1 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > > errors: No known data errors > > ------------------------------------------------------------------------ > > System Memory: > > 0.95% =A0 =A075.61 =A0 =A0MiB Active, =A0 =A00.24% =A0 =A019.02 =A0 =A0Mi= B Inact > 18.25% =A0 =A01.41 =A0 =A0GiB Wired, =A0 =A00.01% =A0 =A0480.00 =A0 =A0Ki= B Cache > 80.54% =A0 =A06.24 =A0 =A0GiB Free, =A0 =A00.01% =A0 =A0604.00 =A0 =A0KiB= Gap > > Real Installed: =A0 =A08.00 =A0 =A0GiB > Real Available: =A0 =A099.84% =A0 =A07.99 =A0 =A0GiB > Real Managed: =A0 =A096.96% =A0 =A07.74 =A0 =A0GiB > > Logical Total: =A0 =A08.00 =A0 =A0GiB > Logical Used: =A0 =A021.79% =A0 =A01.74 =A0 =A0GiB > Logical Free: =A0 =A078.21% =A0 =A06.26 =A0 =A0GiB > > Kernel Memory: =A0 =A01.18 =A0 =A0GiB > Data: =A0 =A099.05% =A0 =A01.17 =A0 =A0GiB > Text: =A0 =A00.95% =A0 =A011.50 =A0 =A0MiB > > Kernel Memory Map: =A0 =A04.39 =A0 =A0GiB > Size: =A0 =A023.32% =A0 =A01.02 =A0 =A0GiB > Free: =A0 =A076.68% =A0 =A03.37 =A0 =A0GiB > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > ZFS Subsystem Report =A0 =A0Wed Feb 15 10:53:03 2012 > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: =A0 =A0802516 (osreldate) > Hardware Platform: =A0 =A0amd64 > Processor Architecture: =A0 =A0amd64 > > ZFS Storage pool Version: =A0 =A028 > ZFS Filesystem Version: =A0 =A05 > > FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root > 10:53AM =A0up 56 mins, 6 users, load averages: 0.00, 0.00, 0.00 > > ------------------------------------------------------------------------ > > > > > Background: > we are using some tool that does indexing of some data and then pushes it > into =A0database (currently bdb-5.2). Instances of indexer are running > continuously one after another. Time of indexing for one instance of > indexer may vary between =A02 seconds and 30 minutes. But mostly it is > below one minute. There is nothing else running on the machine except > system stuff and daemons. After several hours of indexing i can see a lot > of =A0active memory, it's ok. Then i check the number of vnodes. and it's > really huge: 300k+ even tho nobody has so many opened files. Reading docs > and googling i figured that's because of cached pages that reside in > memory (unmounting of disk causes whole memory to be freed). =A0Also I > figured that happens only when I am accessing files via mmap(). > > Looks like pretty legit behaviour but the issue is: > This spectacle continues (approximately for 12 hours) unlit indexers > began to be killed out of swap. As I wrote above I observe a lot of used > vnodes and like 7GB of active memory. I made a tool that allocates memory > using malloc() to check what's the limit of available memory that can be > allocated. It is several megabytes, sometimes more. Unless that tool gets > killed out of swap as well. So how i can see the issue: for some reason > after some process had exited normally all mapped pages don't get freed. > I red about and I agree =A0that this is reasonable behaviour if we have > spare memory. But following this logic these pages can be flushed back to > file at any time when system is under stress conditions. So when I ask > for a piece of RAM, OS should do that trick and give me what I ask. But > that's never happens. Those pages are like frozen. Until I unmount disk. > Even after there is not a single instance of indexer running. > > I believe all this is caused by mmap() for sure : BDB uses mmap() for > accessing databases and we tested indexing with out pushing data to DB. > Worked shiny. You may suggest that that's something wrong with BDB. But > we have some more tools of ours that using mmap() as well and the > behaviour is exact. > > Thank you. Paul, Ukraine. > _______________________________________________ > 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" Hi Paul, Are you using dedup anywhere on that pool? Also, could you please post the full zfs-stats -a --=20 George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:28:18 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 E70EB1065673 for ; Wed, 15 Feb 2012 10:28:18 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe5.ukr.net (ffe5.ukr.net [195.214.192.21]) by mx1.freebsd.org (Postfix) with ESMTP id 053AE8FC0C for ; Wed, 15 Feb 2012 10:28:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=m7gWpOwn0RWGZFY0fA1X2TFQUK8jw6TxzXoJrBfna+k=; b=A5dgx3lr/1D3Wn9UEde9cH9dWbysllR2Wfdka4kMJHOJAa4e5c+2sL5VPZ1nVegLUg1HjqDaOtBgsadRXM1+fLhiM2HIsL2fHRy6N/dV/WIEPS5dLkwPODyShihuAiVNdrV0QtrSjTZOwk8EhSyzZfmj2swNI4qVxUvIeY3a5Vw=; Received: from mail by ffe5.ukr.net with local ID 1Rxc5w-000OZM-71 ; Wed, 15 Feb 2012 12:28:16 +0200 MIME-Version: 1.0 In-Reply-To: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <92617.1329301696.6338962447434776576@ffe5.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 12:28:16 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 10:28:19 -0000 Hey George, thanks for quick response. No, no dedup is used. zfs-stats -a : ------------------------------------------------------------------------ ZFS Subsystem Report Wed Feb 15 12:26:18 2012 ------------------------------------------------------------------------ System Information: Kernel Version: 802516 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 28 ZFS Filesystem Version: 5 FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root 12:26PM up 2:29, 7 users, load averages: 0.02, 0.16, 0.16 ------------------------------------------------------------------------ System Memory: 19.78% 1.53 GiB Active, 0.95% 75.21 MiB Inact 36.64% 2.84 GiB Wired, 0.06% 4.83 MiB Cache 42.56% 3.30 GiB Free, 0.01% 696.00 KiB Gap Real Installed: 8.00 GiB Real Available: 99.84% 7.99 GiB Real Managed: 96.96% 7.74 GiB Logical Total: 8.00 GiB Logical Used: 57.82% 4.63 GiB Logical Free: 42.18% 3.37 GiB Kernel Memory: 2.43 GiB Data: 99.54% 2.42 GiB Text: 0.46% 11.50 MiB Kernel Memory Map: 3.16 GiB Size: 69.69% 2.20 GiB Free: 30.31% 979.48 MiB ------------------------------------------------------------------------ ARC Summary: (THROTTLED) Memory Throttle Count: 3.82k ARC Misc: Deleted: 874.34k Recycle Misses: 376.12k Mutex Misses: 4.74k Evict Skips: 4.74k ARC Size: 68.53% 2.34 GiB Target Size: (Adaptive) 68.54% 2.34 GiB Min Size (Hard Limit): 12.50% 437.50 MiB Max Size (High Water): 8:1 3.42 GiB ARC Size Breakdown: Recently Used Cache Size: 92.95% 2.18 GiB Frequently Used Cache Size: 7.05% 169.01 MiB ARC Hash Breakdown: Elements Max: 229.96k Elements Current: 40.05% 92.10k Collisions: 705.52k Chain Max: 11 Chains: 20.64k ------------------------------------------------------------------------ ARC Efficiency: 7.96m Cache Hit Ratio: 84.92% 6.76m Cache Miss Ratio: 15.08% 1.20m Actual Hit Ratio: 76.29% 6.08m Data Demand Efficiency: 91.32% 4.99m Data Prefetch Efficiency: 19.57% 134.19k CACHE HITS BY CACHE LIST: Anonymously Used: 7.24% 489.41k Most Recently Used: 25.29% 1.71m Most Frequently Used: 64.54% 4.37m Most Recently Used Ghost: 1.42% 95.77k Most Frequently Used Ghost: 1.51% 102.33k CACHE HITS BY DATA TYPE: Demand Data: 67.42% 4.56m Prefetch Data: 0.39% 26.26k Demand Metadata: 22.41% 1.52m Prefetch Metadata: 9.78% 661.25k CACHE MISSES BY DATA TYPE: Demand Data: 36.11% 433.60k Prefetch Data: 8.99% 107.94k Demand Metadata: 32.00% 384.29k Prefetch Metadata: 22.91% 275.09k ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency: 26.49m Hit Ratio: 71.64% 18.98m Miss Ratio: 28.36% 7.51m Colinear: 7.51m Hit Ratio: 0.02% 1.42k Miss Ratio: 99.98% 7.51m Stride: 18.85m Hit Ratio: 99.97% 18.85m Miss Ratio: 0.03% 5.73k DMU Misc: Reclaim: 7.51m Successes: 0.29% 21.58k Failures: 99.71% 7.49m Streams: 130.46k +Resets: 0.35% 461 -Resets: 99.65% 130.00k Bogus: 0 ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 384 vm.kmem_size 4718592000 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 329853485875 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 2705408 vfs.zfs.mfu_ghost_metadata_lsize 332861440 vfs.zfs.mfu_ghost_size 335566848 vfs.zfs.mfu_data_lsize 1641984 vfs.zfs.mfu_metadata_lsize 3048448 vfs.zfs.mfu_size 28561920 vfs.zfs.mru_ghost_data_lsize 68477440 vfs.zfs.mru_ghost_metadata_lsize 62875648 vfs.zfs.mru_ghost_size 131353088 vfs.zfs.mru_data_lsize 1651216384 vfs.zfs.mru_metadata_lsize 278577152 vfs.zfs.mru_size 2306510848 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 12968960 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.arc_meta_limit 917504000 vfs.zfs.arc_meta_used 851157616 vfs.zfs.arc_min 458752000 vfs.zfs.arc_max 3670016000 vfs.zfs.dedup.prefetch 1 vfs.zfs.mdcomp_disable 0 vfs.zfs.write_limit_override 1048576000 vfs.zfs.write_limit_inflated 25728073728 vfs.zfs.write_limit_max 1072003072 vfs.zfs.write_limit_min 33554432 vfs.zfs.write_limit_shift 3 vfs.zfs.no_write_throttle 0 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 0 vfs.zfs.mg_alloc_failures 8 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.txg.synctime_ms 1000 vfs.zfs.txg.timeout 10 vfs.zfs.scrub_limit 10 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 0 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.ramp_rate 2 vfs.zfs.vdev.time_shift 6 vfs.zfs.vdev.min_pending 4 vfs.zfs.vdev.max_pending 10 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_replay_disable 0 vfs.zfs.zio.use_uma 0 vfs.zfs.version.zpl 5 vfs.zfs.version.spa 28 vfs.zfs.version.acl 1 vfs.zfs.debug 0 vfs.zfs.super_owner 0 ------------------------------------------------------------------------ > 2012/2/15 Pavlo : > > > > Hello. > > We have an issue with memory management on FreeBSD and i suspect it is > related to FS. > We are using ZFS, here quick stats: > > > zpool status > pool: disk1 > state: ONLINE > scan: resilvered 657G in 8h30m with 0 errors on Tue Feb 14 21:17:37 2012 > config: > > NAME STATE READ WRITE CKSUM > disk1 ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > gpt/disk2 ONLINE 0 0 0 > gpt/disk4 ONLINE 0 0 0 > gpt/disk6 ONLINE 0 0 0 > gpt/disk8 ONLINE 0 0 0 > gpt/disk10 ONLINE 0 0 0 > gpt/disk12 ONLINE 0 0 0 > mirror-7 ONLINE 0 0 0 > gpt/disk14 ONLINE 0 0 0 > gpt/disk15 ONLINE 0 0 0 > > errors: No known data errors > > pool: zroot > state: ONLINE > scan: resilvered 34.9G in 0h11m with 0 errors on Tue Feb 14 12:57:52 2012 > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/sys0 ONLINE 0 0 0 > gpt/sys1 ONLINE 0 0 0 > > errors: No known data errors > > ------------------------------------------------------------------------ > > System Memory: > > 0.95% 75.61 MiB Active, 0.24% 19.02 MiB Inact > 18.25% 1.41 GiB Wired, 0.01% 480.00 KiB Cache > 80.54% 6.24 GiB Free, 0.01% 604.00 KiB Gap > > Real Installed: 8.00 GiB > Real Available: 99.84% 7.99 GiB > Real Managed: 96.96% 7.74 GiB > > Logical Total: 8.00 GiB > Logical Used: 21.79% 1.74 GiB > Logical Free: 78.21% 6.26 GiB > > Kernel Memory: 1.18 GiB > Data: 99.05% 1.17 GiB > Text: 0.95% 11.50 MiB > > Kernel Memory Map: 4.39 GiB > Size: 23.32% 1.02 GiB > Free: 76.68% 3.37 GiB > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > ZFS Subsystem Report Wed Feb 15 10:53:03 2012 > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: 802516 (osreldate) > Hardware Platform: amd64 > Processor Architecture: amd64 > > ZFS Storage pool Version: 28 > ZFS Filesystem Version: 5 > > FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root > 10:53AM up 56 mins, 6 users, load averages: 0.00, 0.00, 0.00 > > ------------------------------------------------------------------------ > > > > > Background: > we are using some tool that does indexing of some data and then pushes it > into database (currently bdb-5.2). Instances of indexer are running > continuously one after another. Time of indexing for one instance of > indexer may vary between 2 seconds and 30 minutes. But mostly it is > below one minute. There is nothing else running on the machine except > system stuff and daemons. After several hours of indexing i can see a lot > of active memory, it's ok. Then i check the number of vnodes. and it's > really huge: 300k+ even tho nobody has so many opened files. Reading docs > and googling i figured that's because of cached pages that reside in > memory (unmounting of disk causes whole memory to be freed). Also I > figured that happens only when I am accessing files via mmap(). > > Looks like pretty legit behaviour but the issue is: > This spectacle continues (approximately for 12 hours) unlit indexers > began to be killed out of swap. As I wrote above I observe a lot of used > vnodes and like 7GB of active memory. I made a tool that allocates memory > using malloc() to check what's the limit of available memory that can be > allocated. It is several megabytes, sometimes more. Unless that tool gets > killed out of swap as well. So how i can see the issue: for some reason > after some process had exited normally all mapped pages don't get freed. > I red about and I agree that this is reasonable behaviour if we have > spare memory. But following this logic these pages can be flushed back to > file at any time when system is under stress conditions. So when I ask > for a piece of RAM, OS should do that trick and give me what I ask. But > that's never happens. Those pages are like frozen. Until I unmount disk. > Even after there is not a single instance of indexer running. > > I believe all this is caused by mmap() for sure : BDB uses mmap() for > accessing databases and we tested indexing with out pushing data to DB. > Worked shiny. You may suggest that that's something wrong with BDB. But > we have some more tools of ours that using mmap() as well and the > behaviour is exact. > > Thank you. Paul, Ukraine. > _______________________________________________ > 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" Hi Paul, Are you using dedup anywhere on that pool? Also, could you please post the full zfs-stats -a -- George Kontostanos Aicom telecoms ltdhttp://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:45: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 29F381065670 for ; Wed, 15 Feb 2012 10:45:47 +0000 (UTC) (envelope-from gkontos.mail@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 E6B428FC17 for ; Wed, 15 Feb 2012 10:45:46 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1658772iae.13 for ; Wed, 15 Feb 2012 02:45:46 -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=czO1baDlLHyTCHt85a2jJS09t1M2mon9Iq1r4EKxSJ0=; b=Cw5oBJLLwtS1wW4WuMTrzhyGi/GCDUbtBBPYOnofqB493T1l0Y5uNj6+noPZmcgpXw nP6YXzldBuKuQm2PoObw2t3q4S2e9PNCxqsBNyc/XKVUNONxlqcjgGXET18RdsImNR7a w5M637pq/eI2O3fYYEgboAS0EuFcF3LLxIq4U= MIME-Version: 1.0 Received: by 10.42.151.72 with SMTP id d8mr32201219icw.50.1329302746608; Wed, 15 Feb 2012 02:45:46 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 02:45:46 -0800 (PST) In-Reply-To: <92617.1329301696.6338962447434776576@ffe5.ukr.net> References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> Date: Wed, 15 Feb 2012 12:45:46 +0200 Message-ID: From: George Kontostanos To: Pavlo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 10:45:47 -0000 MjAxMi8yLzE1IFBhdmxvIDxkZXZnc0B1a3IubmV0PjoKPgo+IEhleSBHZW9yZ2UsCj4KPiB0aGFu a3MgZm9yIHF1aWNrIHJlc3BvbnNlLgo+Cj4gTm8sIG5vIGRlZHVwIGlzIHVzZWQuCj4KPiB6ZnMt c3RhdHMgLWEgOgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gWkZTIFN1YnN5c3RlbSBSZXBvcnSgoKAg oKCgIKCgoCCgoKAgV2VkIEZlYiAxNSAxMjoyNjoxOCAyMDEyCj4KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pgo+IFN5c3RlbSBJbmZvcm1hdGlvbjoKPgo+IKCgoCBLZXJuZWwgVmVyc2lvbjqgoKAgoKCgIKCg oCCgoKAgODAyNTE2IChvc3JlbGRhdGUpCj4goKCgIEhhcmR3YXJlIFBsYXRmb3JtOqCgoCCgoKAg oKCgIGFtZDY0Cj4goKCgIFByb2Nlc3NvciBBcmNoaXRlY3R1cmU6oKCgIKCgoCCgoKAgYW1kNjQK Pgo+IKCgoCBaRlMgU3RvcmFnZSBwb29sIFZlcnNpb246oKCgIKCgoCAyOAo+IKCgoCBaRlMgRmls ZXN5c3RlbSBWZXJzaW9uOqCgoCCgoKAgoKCgIDUKPgo+IEZyZWVCU0QgOC4yLVNUQUJMRSAjMTI6 IFRodSBGZWIgOSAxMTozNToyMyBFRVQgMjAxMiByb290Cj4gMTI6MjZQTaAgdXCgIDI6MjksIDcg dXNlcnMsIGxvYWQgYXZlcmFnZXM6IDAuMDIsIDAuMTYsIDAuMTYKPgo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4gU3lzdGVtIE1lbW9yeToKPgo+IKCgoCAxOS43OCWgoKAgMS41M6CgoCBHaUIgQWN0aXZl LKCgoCAwLjk1JaCgoCA3NS4yMaCgoCBNaUIgSW5hY3QKPiCgoKAgMzYuNjQloKCgIDIuODSgoKAg R2lCIFdpcmVkLKCgoCAwLjA2JaCgoCA0LjgzoKCgIE1pQiBDYWNoZQo+IKCgoCA0Mi41NiWgoKAg My4zMKCgoCBHaUIgRnJlZSygoKAgMC4wMSWgoKAgNjk2LjAwoKCgIEtpQiBHYXAKPgo+Cj4goKCg IFJlYWwgSW5zdGFsbGVkOqCgoCCgoKAgoKCgIKCgoCA4LjAwoKCgIEdpQgo+IKCgoCBSZWFsIEF2 YWlsYWJsZTqgoKAgoKCgIKCgoCA5OS44NCWgoKAgNy45OaCgoCBHaUIKPiCgoKAgUmVhbCBNYW5h Z2VkOqCgoCCgoKAgoKCgIDk2Ljk2JaCgoCA3Ljc0oKCgIEdpQgo+Cj4goKCgIExvZ2ljYWwgVG90 YWw6oKCgIKCgoCCgoKAgoKCgIDguMDCgoKAgR2lCCj4goKCgIExvZ2ljYWwgVXNlZDqgoKAgoKCg IKCgoCA1Ny44MiWgoKAgNC42M6CgoCBHaUIKPiCgoKAgTG9naWNhbCBGcmVlOqCgoCCgoKAgoKCg IDQyLjE4JaCgoCAzLjM3oKCgIEdpQgo+Cj4gS2VybmVsIE1lbW9yeTqgoKAgoKCgIKCgoCCgoKAg oKCgIDIuNDOgoKAgR2lCCj4goKCgIERhdGE6oKCgIKCgoCCgoKAgoKCgIDk5LjU0JaCgoCAyLjQy oKCgIEdpQgo+IKCgoCBUZXh0OqCgoCCgoKAgoKCgIKCgoCAwLjQ2JaCgoCAxMS41MKCgoCBNaUIK Pgo+IEtlcm5lbCBNZW1vcnkgTWFwOqCgoCCgoKAgoKCgIKCgoCAzLjE2oKCgIEdpQgo+IKCgoCBT aXplOqCgoCCgoKAgoKCgIKCgoCA2OS42OSWgoKAgMi4yMKCgoCBHaUIKPiCgoKAgRnJlZTqgoKAg oKCgIKCgoCCgoKAgMzAuMzEloKCgIDk3OS40OKCgoCBNaUIKPgo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ Cj4gQVJDIFN1bW1hcnk6IChUSFJPVFRMRUQpCj4goKCgIE1lbW9yeSBUaHJvdHRsZSBDb3VudDqg oKAgoKCgIKCgoCAzLjgyawo+Cj4gQVJDIE1pc2M6Cj4goKCgIERlbGV0ZWQ6oKCgIKCgoCCgoKAg oKCgIDg3NC4zNGsKPiCgoKAgUmVjeWNsZSBNaXNzZXM6oKCgIKCgoCCgoKAgoKCgIDM3Ni4xMmsK PiCgoKAgTXV0ZXggTWlzc2VzOqCgoCCgoKAgoKCgIKCgoCA0Ljc0awo+IKCgoCBFdmljdCBTa2lw czqgoKAgoKCgIKCgoCCgoKAgNC43NGsKPgo+IEFSQyBTaXplOqCgoCCgoKAgoKCgIKCgoCA2OC41 MyWgoKAgMi4zNKCgoCBHaUIKPiCgoKAgVGFyZ2V0IFNpemU6IChBZGFwdGl2ZSmgoKAgoKCgIDY4 LjU0JaCgoCAyLjM0oKCgIEdpQgo+IKCgoCBNaW4gU2l6ZSAoSGFyZCBMaW1pdCk6oKCgIKCgoCAx Mi41MCWgoKAgNDM3LjUwoKCgIE1pQgo+IKCgoCBNYXggU2l6ZSAoSGlnaCBXYXRlcik6oKCgIKCg oCA4OjGgoKAgMy40MqCgoCBHaUIKPgo+IEFSQyBTaXplIEJyZWFrZG93bjoKPiCgoKAgUmVjZW50 bHkgVXNlZCBDYWNoZSBTaXplOqCgoCA5Mi45NSWgoKAgMi4xOKCgoCBHaUIKPiCgoKAgRnJlcXVl bnRseSBVc2VkIENhY2hlIFNpemU6oKCgIDcuMDUloKCgIDE2OS4wMaCgoCBNaUIKPgo+IEFSQyBI YXNoIEJyZWFrZG93bjoKPiCgoKAgRWxlbWVudHMgTWF4OqCgoCCgoKAgoKCgIKCgoCAyMjkuOTZr Cj4goKCgIEVsZW1lbnRzIEN1cnJlbnQ6oKCgIKCgoCA0MC4wNSWgoKAgOTIuMTBrCj4goKCgIENv bGxpc2lvbnM6oKCgIKCgoCCgoKAgoKCgIDcwNS41MmsKPiCgoKAgQ2hhaW4gTWF4OqCgoCCgoKAg oKCgIKCgoCAxMQo+IKCgoCBDaGFpbnM6oKCgIKCgoCCgoKAgoKCgIKCgoCAyMC42NGsKPgo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+Cj4gQVJDIEVmZmljaWVuY3k6oKCgIKCgoCCgoKAgoKCgIKCgoCA3Ljk2 bQo+IKCgoCBDYWNoZSBIaXQgUmF0aW86oKCgIKCgoCA4NC45MiWgoKAgNi43Nm0KPiCgoKAgQ2Fj aGUgTWlzcyBSYXRpbzqgoKAgoKCgIDE1LjA4JaCgoCAxLjIwbQo+IKCgoCBBY3R1YWwgSGl0IFJh dGlvOqCgoCCgoKAgNzYuMjkloKCgIDYuMDhtCj4KPiCgoKAgRGF0YSBEZW1hbmQgRWZmaWNpZW5j eTqgoKAgoKCgIDkxLjMyJaCgoCA0Ljk5bQo+IKCgoCBEYXRhIFByZWZldGNoIEVmZmljaWVuY3k6 oKCgIDE5LjU3JaCgoCAxMzQuMTlrCj4KPiCgoKAgQ0FDSEUgSElUUyBCWSBDQUNIRSBMSVNUOgo+ IKCgoCCgIEFub255bW91c2x5IFVzZWQ6oKCgIKCgoCA3LjI0JaCgoCA0ODkuNDFrCj4goKCgIKAg TW9zdCBSZWNlbnRseSBVc2VkOqCgoCCgoKAgMjUuMjkloKCgIDEuNzFtCj4goKCgIKAgTW9zdCBG cmVxdWVudGx5IFVzZWQ6oKCgIKCgoCA2NC41NCWgoKAgNC4zN20KPiCgoKAgoCBNb3N0IFJlY2Vu dGx5IFVzZWQgR2hvc3Q6oKCgIDEuNDIloKCgIDk1Ljc3awo+IKCgoCCgIE1vc3QgRnJlcXVlbnRs eSBVc2VkIEdob3N0OqCgoCAxLjUxJaCgoCAxMDIuMzNrCj4KPiCgoKAgQ0FDSEUgSElUUyBCWSBE QVRBIFRZUEU6Cj4goKCgIKAgRGVtYW5kIERhdGE6oKCgIKCgoCCgoKAgNjcuNDIloKCgIDQuNTZt Cj4goKCgIKAgUHJlZmV0Y2ggRGF0YTqgoKAgoKCgIDAuMzkloKCgIDI2LjI2awo+IKCgoCCgIERl bWFuZCBNZXRhZGF0YTqgoKAgoKCgIDIyLjQxJaCgoCAxLjUybQo+IKCgoCCgIFByZWZldGNoIE1l dGFkYXRhOqCgoCCgoKAgOS43OCWgoKAgNjYxLjI1awo+Cj4goKCgIENBQ0hFIE1JU1NFUyBCWSBE QVRBIFRZUEU6Cj4goKCgIKAgRGVtYW5kIERhdGE6oKCgIKCgoCCgoKAgMzYuMTEloKCgIDQzMy42 MGsKPiCgoKAgoCBQcmVmZXRjaCBEYXRhOqCgoCCgoKAgOC45OSWgoKAgMTA3Ljk0awo+IKCgoCCg IERlbWFuZCBNZXRhZGF0YTqgoKAgoKCgIDMyLjAwJaCgoCAzODQuMjlrCj4goKCgIKAgUHJlZmV0 Y2ggTWV0YWRhdGE6oKCgIKCgoCAyMi45MSWgoKAgMjc1LjA5awo+Cj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4KPiBMMkFSQyBpcyBkaXNhYmxlZAo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBGaWxlLUxldmVs IFByZWZldGNoOiAoSEVBTFRIWSkKPgo+IERNVSBFZmZpY2llbmN5OqCgoCCgoKAgoKCgIKCgoCCg oKAgMjYuNDltCj4goKCgIEhpdCBSYXRpbzqgoKAgoKCgIKCgoCA3MS42NCWgoKAgMTguOThtCj4g oKCgIE1pc3MgUmF0aW86oKCgIKCgoCCgoKAgMjguMzYloKCgIDcuNTFtCj4KPiCgoKAgQ29saW5l YXI6oKCgIKCgoCCgoKAgoKCgIDcuNTFtCj4goKCgIKAgSGl0IFJhdGlvOqCgoCCgoKAgoKCgIDAu MDIloKCgIDEuNDJrCj4goKCgIKAgTWlzcyBSYXRpbzqgoKAgoKCgIKCgoCA5OS45OCWgoKAgNy41 MW0KPgo+IKCgoCBTdHJpZGU6oKCgIKCgoCCgoKAgoKCgIKCgoCAxOC44NW0KPiCgoKAgoCBIaXQg UmF0aW86oKCgIKCgoCCgoKAgOTkuOTcloKCgIDE4Ljg1bQo+IKCgoCCgIE1pc3MgUmF0aW86oKCg IKCgoCCgoKAgMC4wMyWgoKAgNS43M2sKPgo+IERNVSBNaXNjOgo+IKCgoCBSZWNsYWltOqCgoCCg oKAgoKCgIKCgoCA3LjUxbQo+IKCgoCCgIFN1Y2Nlc3NlczqgoKAgoKCgIKCgoCAwLjI5JaCgoCAy MS41OGsKPiCgoKAgoCBGYWlsdXJlczqgoKAgoKCgIKCgoCA5OS43MSWgoKAgNy40OW0KPgo+IKCg oCBTdHJlYW1zOqCgoCCgoKAgoKCgIKCgoCAxMzAuNDZrCj4goKCgIKAgK1Jlc2V0czqgoKAgoKCg IKCgoCAwLjM1JaCgoCA0NjEKPiCgoKAgoCAtUmVzZXRzOqCgoCCgoKAgoKCgIDk5LjY1JaCgoCAx MzAuMDBrCj4goKCgIKAgQm9ndXM6oKCgIKCgoCCgoKAgoKCgIDAKPgo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4gVkRFViBjYWNoZSBpcyBkaXNhYmxlZAo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiBaRlMg VHVuYWJsZXMgKHN5c2N0bCk6Cj4goKCgIGtlcm4ubWF4dXNlcnOgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCAzODQKPiCgoKAgdm0ua21lbV9zaXploKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg IDQ3MTg1OTIwMDAKPiCgoKAgdm0ua21lbV9zaXplX3NjYWxloKCgoKCgoKCgoKCgoKCgoKCgoKCg IDEKPiCgoKAgdm0ua21lbV9zaXplX21pbqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDAKPiCgoKAg dm0ua21lbV9zaXplX21heKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIDMyOTg1MzQ4NTg3NQo+IKCg oCB2ZnMuemZzLmwyY19vbmx5X3NpemWgoKCgoKCgoKCgoKCgoKCgoKAgMAo+IKCgoCB2ZnMuemZz Lm1mdV9naG9zdF9kYXRhX2xzaXploKCgoKCgoKCgoKAgMjcwNTQwOAo+IKCgoCB2ZnMuemZzLm1m dV9naG9zdF9tZXRhZGF0YV9sc2l6ZaCgoKCgoKAgMzMyODYxNDQwCj4goKCgIHZmcy56ZnMubWZ1 X2dob3N0X3NpemWgoKCgoKCgoKCgoKCgoKCgoCAzMzU1NjY4NDgKPiCgoKAgdmZzLnpmcy5tZnVf ZGF0YV9sc2l6ZaCgoKCgoKCgoKCgoKCgoKCgIDE2NDE5ODQKPiCgoKAgdmZzLnpmcy5tZnVfbWV0 YWRhdGFfbHNpemWgoKCgoKCgoKCgoKCgIDMwNDg0NDgKPiCgoKAgdmZzLnpmcy5tZnVfc2l6ZaCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgIDI4NTYxOTIwCj4goKCgIHZmcy56ZnMubXJ1X2dob3N0X2Rh dGFfbHNpemWgoKCgoKCgoKCgoCA2ODQ3NzQ0MAo+IKCgoCB2ZnMuemZzLm1ydV9naG9zdF9tZXRh ZGF0YV9sc2l6ZaCgoKCgoKAgNjI4NzU2NDgKPiCgoKAgdmZzLnpmcy5tcnVfZ2hvc3Rfc2l6ZaCg oKCgoKCgoKCgoKCgoKCgIDEzMTM1MzA4OAo+IKCgoCB2ZnMuemZzLm1ydV9kYXRhX2xzaXploKCg oKCgoKCgoKCgoKCgoKAgMTY1MTIxNjM4NAo+IKCgoCB2ZnMuemZzLm1ydV9tZXRhZGF0YV9sc2l6 ZaCgoKCgoKCgoKCgoKAgMjc4NTc3MTUyCj4goKCgIHZmcy56ZnMubXJ1X3NpemWgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoCAyMzA2NTEwODQ4Cj4goKCgIHZmcy56ZnMuYW5vbl9kYXRhX2xzaXploKCg oKCgoKCgoKCgoKCgoCAwCj4goKCgIHZmcy56ZnMuYW5vbl9tZXRhZGF0YV9sc2l6ZaCgoKCgoKCg oKCgoCAwCj4goKCgIHZmcy56ZnMuYW5vbl9zaXploKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAxMjk2 ODk2MAo+IKCgoCB2ZnMuemZzLmwyYXJjX25vcnegoKCgoKCgoKCgoKCgoKCgoKCgoKAgMQo+IKCg oCB2ZnMuemZzLmwyYXJjX2ZlZWRfYWdhaW6goKCgoKCgoKCgoKCgoKAgMQo+IKCgoCB2ZnMuemZz LmwyYXJjX25vcHJlZmV0Y2igoKCgoKCgoKCgoKCgoKAgMQo+IKCgoCB2ZnMuemZzLmwyYXJjX2Zl ZWRfbWluX21zoKCgoKCgoKCgoKCgoKAgMjAwCj4goKCgIHZmcy56ZnMubDJhcmNfZmVlZF9zZWNz oKCgoKCgoKCgoKCgoKCgoCAxCj4goKCgIHZmcy56ZnMubDJhcmNfaGVhZHJvb22goKCgoKCgoKCg oKCgoKCgoCAyCj4goKCgIHZmcy56ZnMubDJhcmNfd3JpdGVfYm9vc3SgoKCgoKCgoKCgoKCgoCA4 Mzg4NjA4Cj4goKCgIHZmcy56ZnMubDJhcmNfd3JpdGVfbWF4oKCgoKCgoKCgoKCgoKCgoCA4Mzg4 NjA4Cj4goKCgIHZmcy56ZnMuYXJjX21ldGFfbGltaXSgoKCgoKCgoKCgoKCgoKCgoCA5MTc1MDQw MDAKPiCgoKAgdmZzLnpmcy5hcmNfbWV0YV91c2VkoKCgoKCgoKCgoKCgoKCgoKCgIDg1MTE1NzYx Ngo+IKCgoCB2ZnMuemZzLmFyY19taW6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgNDU4NzUyMDAw Cj4goKCgIHZmcy56ZnMuYXJjX21heKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAzNjcwMDE2MDAw Cj4goKCgIHZmcy56ZnMuZGVkdXAucHJlZmV0Y2igoKCgoKCgoKCgoKCgoKCgoCAxCj4goKCgIHZm cy56ZnMubWRjb21wX2Rpc2FibGWgoKCgoKCgoKCgoKCgoKCgoCAwCj4goKCgIHZmcy56ZnMud3Jp dGVfbGltaXRfb3ZlcnJpZGWgoKCgoKCgoKCgoCAxMDQ4NTc2MDAwCj4goKCgIHZmcy56ZnMud3Jp dGVfbGltaXRfaW5mbGF0ZWSgoKCgoKCgoKCgoCAyNTcyODA3MzcyOAo+IKCgoCB2ZnMuemZzLndy aXRlX2xpbWl0X21heKCgoKCgoKCgoKCgoKCgoKAgMTA3MjAwMzA3Mgo+IKCgoCB2ZnMuemZzLndy aXRlX2xpbWl0X21pbqCgoKCgoKCgoKCgoKCgoKAgMzM1NTQ0MzIKPiCgoKAgdmZzLnpmcy53cml0 ZV9saW1pdF9zaGlmdKCgoKCgoKCgoKCgoKCgIDMKPiCgoKAgdmZzLnpmcy5ub193cml0ZV90aHJv dHRsZaCgoKCgoKCgoKCgoKCgIDAKPiCgoKAgdmZzLnpmcy56ZmV0Y2guYXJyYXlfcmRfc3qgoKCg oKCgoKCgoKCgIDEwNDg1NzYKPiCgoKAgdmZzLnpmcy56ZmV0Y2guYmxvY2tfY2FwoKCgoKCgoKCg oKCgoKCgIDI1Ngo+IKCgoCB2ZnMuemZzLnpmZXRjaC5taW5fc2VjX3JlYXCgoKCgoKCgoKCgoKAg Mgo+IKCgoCB2ZnMuemZzLnpmZXRjaC5tYXhfc3RyZWFtc6CgoKCgoKCgoKCgoKAgOAo+IKCgoCB2 ZnMuemZzLnByZWZldGNoX2Rpc2FibGWgoKCgoKCgoKCgoKCgoKAgMAo+IKCgoCB2ZnMuemZzLm1n X2FsbG9jX2ZhaWx1cmVzoKCgoKCgoKCgoKCgoKAgOAo+IKCgoCB2ZnMuemZzLmNoZWNrX2hvc3Rp ZKCgoKCgoKCgoKCgoKCgoKCgoKAgMQo+IKCgoCB2ZnMuemZzLnJlY292ZXKgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKAgMAo+IKCgoCB2ZnMuemZzLnR4Zy5zeW5jdGltZV9tc6CgoKCgoKCgoKCgoKCg oKAgMTAwMAo+IKCgoCB2ZnMuemZzLnR4Zy50aW1lb3V0oKCgoKCgoKCgoKCgoKCgoKCgoKAgMTAK PiCgoKAgdmZzLnpmcy5zY3J1Yl9saW1pdKCgoKCgoKCgoKCgoKCgoKCgoKCgIDEwCj4goKCgIHZm cy56ZnMudmRldi5jYWNoZS5ic2hpZnSgoKCgoKCgoKCgoKCgoCAxNgo+IKCgoCB2ZnMuemZzLnZk ZXYuY2FjaGUuc2l6ZaCgoKCgoKCgoKCgoKCgoKAgMAo+IKCgoCB2ZnMuemZzLnZkZXYuY2FjaGUu bWF4oKCgoKCgoKCgoKCgoKCgoKAgMTYzODQKPiCgoKAgdmZzLnpmcy52ZGV2LndyaXRlX2dhcF9s aW1pdKCgoKCgoKCgoKCgIDQwOTYKPiCgoKAgdmZzLnpmcy52ZGV2LnJlYWRfZ2FwX2xpbWl0oKCg oKCgoKCgoKCgIDMyNzY4Cj4goKCgIHZmcy56ZnMudmRldi5hZ2dyZWdhdGlvbl9saW1pdKCgoKCg oKCgoCAxMzEwNzIKPiCgoKAgdmZzLnpmcy52ZGV2LnJhbXBfcmF0ZaCgoKCgoKCgoKCgoKCgoKCg IDIKPiCgoKAgdmZzLnpmcy52ZGV2LnRpbWVfc2hpZnSgoKCgoKCgoKCgoKCgoKCgIDYKPiCgoKAg dmZzLnpmcy52ZGV2Lm1pbl9wZW5kaW5noKCgoKCgoKCgoKCgoKCgIDQKPiCgoKAgdmZzLnpmcy52 ZGV2Lm1heF9wZW5kaW5noKCgoKCgoKCgoKCgoKCgIDEwCj4goKCgIHZmcy56ZnMudmRldi5iaW9f Zmx1c2hfZGlzYWJsZaCgoKCgoKCgoCAwCj4goKCgIHZmcy56ZnMuY2FjaGVfZmx1c2hfZGlzYWJs ZaCgoKCgoKCgoKCgoCAwCj4goKCgIHZmcy56ZnMuemlsX3JlcGxheV9kaXNhYmxloKCgoKCgoKCg oKCgoCAwCj4goKCgIHZmcy56ZnMuemlvLnVzZV91bWGgoKCgoKCgoKCgoKCgoKCgoKCgoCAwCj4g oKCgIHZmcy56ZnMudmVyc2lvbi56cGygoKCgoKCgoKCgoKCgoKCgoKCgoCA1Cj4goKCgIHZmcy56 ZnMudmVyc2lvbi5zcGGgoKCgoKCgoKCgoKCgoKCgoKCgoCAyOAo+IKCgoCB2ZnMuemZzLnZlcnNp b24uYWNsoKCgoKCgoKCgoKCgoKCgoKCgoKAgMQo+IKCgoCB2ZnMuemZzLmRlYnVnoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKAgMAo+IKCgoCB2ZnMuemZzLnN1cGVyX293bmVyoKCgoKCgoKCgoKCg oKCgoKCgoKAgMAo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpJIHNlZSB0aGF0IHlvdSBhcmUgbGltaXRp bmcgeW91ciBhcmMubWF4IHRvIDNHIGJ1dCB5b3UgaGF2ZSBwcmVmZXRjaCBlbmFibGVkLgoKWW91 IGNhbiB0cnkgZGlzYWJsaW5nIHRoaXM6Cgp2ZnMuemZzLnByZWZldGNoX2Rpc2FibGU9MQoKSWYg dGhpbmdzIHR1cm4gb3V0IGJldHRlciB5b3UgY2FuIGluY3JlYXNlIHlvdXIgYXJjLm1hYyB0byA0 RwoKUmVnYXJkcwotLSAKR2VvcmdlIEtvbnRvc3Rhbm9zCkFpY29tIHRlbGVjb21zIGx0ZApodHRw Oi8vd3d3LmFpc2VjdXJlLm5ldAo= From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 10:56: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 728AE106566B for ; Wed, 15 Feb 2012 10:56:27 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 976DA8FC1B for ; Wed, 15 Feb 2012 10:56:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=vWKWRYGFRsspGXzTSRtC/H9uTvJRm6tQeIZYgU3FR7U=; b=o/jJ1hIDOWl+pb8+NyT1+PlLNqJThJ5PlN/6zatJLScDjQhy9o4iLX7w09ppRdnl56dCU00F7QwngsUrh9SIA4tUFNdmTn5jDMRnU/dYjnJJNtMucNr6am1Xf/uYEHJFaU4dw1Z2XMX1du3JyroC/SSC2JHUvESellUK8SUCJpw=; Received: from mail by ffe16.ukr.net with local ID 1RxcXA-000E0F-Pm ; Wed, 15 Feb 2012 12:56:24 +0200 MIME-Version: 1.0 In-Reply-To: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <53119.1329303384.12448677870900346880@ffe16.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 12:56:24 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 10:56:27 -0000 Thanks George, I will try this and tell you if it helps. > 2012/2/15 Pavlo : > > Hey George, > > thanks for quick response. > > No, no dedup is used. > > zfs-stats -a : > > ------------------------------------------------------------------------ > ZFS Subsystem Report Wed Feb 15 12:26:18 2012 > > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: 802516 (osreldate) > Hardware Platform: amd64 > Processor Architecture: amd64 > > ZFS Storage pool Version: 28 > ZFS Filesystem Version: 5 > > FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root > 12:26PM up 2:29, 7 users, load averages: 0.02, 0.16, 0.16 > > ------------------------------------------------------------------------ > > System Memory: > > 19.78% 1.53 GiB Active, 0.95% 75.21 MiB Inact > 36.64% 2.84 GiB Wired, 0.06% 4.83 MiB Cache > 42.56% 3.30 GiB Free, 0.01% 696.00 KiB Gap > > > Real Installed: 8.00 GiB > Real Available: 99.84% 7.99 GiB > Real Managed: 96.96% 7.74 GiB > > Logical Total: 8.00 GiB > Logical Used: 57.82% 4.63 GiB > Logical Free: 42.18% 3.37 GiB > > Kernel Memory: 2.43 GiB > Data: 99.54% 2.42 GiB > Text: 0.46% 11.50 MiB > > Kernel Memory Map: 3.16 GiB > Size: 69.69% 2.20 GiB > Free: 30.31% 979.48 MiB > > ------------------------------------------------------------------------ > > ARC Summary: (THROTTLED) > Memory Throttle Count: 3.82k > > ARC Misc: > Deleted: 874.34k > Recycle Misses: 376.12k > Mutex Misses: 4.74k > Evict Skips: 4.74k > > ARC Size: 68.53% 2.34 GiB > Target Size: (Adaptive) 68.54% 2.34 GiB > Min Size (Hard Limit): 12.50% 437.50 MiB > Max Size (High Water): 8:1 3.42 GiB > > ARC Size Breakdown: > Recently Used Cache Size: 92.95% 2.18 GiB > Frequently Used Cache Size: 7.05% 169.01 MiB > > ARC Hash Breakdown: > Elements Max: 229.96k > Elements Current: 40.05% 92.10k > Collisions: 705.52k > Chain Max: 11 > Chains: 20.64k > > ------------------------------------------------------------------------ > > ARC Efficiency: 7.96m > Cache Hit Ratio: 84.92% 6.76m > Cache Miss Ratio: 15.08% 1.20m > Actual Hit Ratio: 76.29% 6.08m > > Data Demand Efficiency: 91.32% 4.99m > Data Prefetch Efficiency: 19.57% 134.19k > > CACHE HITS BY CACHE LIST: > Anonymously Used: 7.24% 489.41k > Most Recently Used: 25.29% 1.71m > Most Frequently Used: 64.54% 4.37m > Most Recently Used Ghost: 1.42% 95.77k > Most Frequently Used Ghost: 1.51% 102.33k > > CACHE HITS BY DATA TYPE: > Demand Data: 67.42% 4.56m > Prefetch Data: 0.39% 26.26k > Demand Metadata: 22.41% 1.52m > Prefetch Metadata: 9.78% 661.25k > > CACHE MISSES BY DATA TYPE: > Demand Data: 36.11% 433.60k > Prefetch Data: 8.99% 107.94k > Demand Metadata: 32.00% 384.29k > Prefetch Metadata: 22.91% 275.09k > > ------------------------------------------------------------------------ > > L2ARC is disabled > > ------------------------------------------------------------------------ > > File-Level Prefetch: (HEALTHY) > > DMU Efficiency: 26.49m > Hit Ratio: 71.64% 18.98m > Miss Ratio: 28.36% 7.51m > > Colinear: 7.51m > Hit Ratio: 0.02% 1.42k > Miss Ratio: 99.98% 7.51m > > Stride: 18.85m > Hit Ratio: 99.97% 18.85m > Miss Ratio: 0.03% 5.73k > > DMU Misc: > Reclaim: 7.51m > Successes: 0.29% 21.58k > Failures: 99.71% 7.49m > > Streams: 130.46k > +Resets: 0.35% 461 > -Resets: 99.65% 130.00k > Bogus: 0 > > ------------------------------------------------------------------------ > > VDEV cache is disabled > > ------------------------------------------------------------------------ > > ZFS Tunables (sysctl): > kern.maxusers 384 > vm.kmem_size 4718592000 > vm.kmem_size_scale 1 > vm.kmem_size_min 0 > vm.kmem_size_max 329853485875 > vfs.zfs.l2c_only_size 0 > vfs.zfs.mfu_ghost_data_lsize 2705408 > vfs.zfs.mfu_ghost_metadata_lsize 332861440 > vfs.zfs.mfu_ghost_size 335566848 > vfs.zfs.mfu_data_lsize 1641984 > vfs.zfs.mfu_metadata_lsize 3048448 > vfs.zfs.mfu_size 28561920 > vfs.zfs.mru_ghost_data_lsize 68477440 > vfs.zfs.mru_ghost_metadata_lsize 62875648 > vfs.zfs.mru_ghost_size 131353088 > vfs.zfs.mru_data_lsize 1651216384 > vfs.zfs.mru_metadata_lsize 278577152 > vfs.zfs.mru_size 2306510848 > vfs.zfs.anon_data_lsize 0 > vfs.zfs.anon_metadata_lsize 0 > vfs.zfs.anon_size 12968960 > vfs.zfs.l2arc_norw 1 > vfs.zfs.l2arc_feed_again 1 > vfs.zfs.l2arc_noprefetch 1 > vfs.zfs.l2arc_feed_min_ms 200 > vfs.zfs.l2arc_feed_secs 1 > vfs.zfs.l2arc_headroom 2 > vfs.zfs.l2arc_write_boost 8388608 > vfs.zfs.l2arc_write_max 8388608 > vfs.zfs.arc_meta_limit 917504000 > vfs.zfs.arc_meta_used 851157616 > vfs.zfs.arc_min 458752000 > vfs.zfs.arc_max 3670016000 > vfs.zfs.dedup.prefetch 1 > vfs.zfs.mdcomp_disable 0 > vfs.zfs.write_limit_override 1048576000 > vfs.zfs.write_limit_inflated 25728073728 > vfs.zfs.write_limit_max 1072003072 > vfs.zfs.write_limit_min 33554432 > vfs.zfs.write_limit_shift 3 > vfs.zfs.no_write_throttle 0 > vfs.zfs.zfetch.array_rd_sz 1048576 > vfs.zfs.zfetch.block_cap 256 > vfs.zfs.zfetch.min_sec_reap 2 > vfs.zfs.zfetch.max_streams 8 > vfs.zfs.prefetch_disable 0 > vfs.zfs.mg_alloc_failures 8 > vfs.zfs.check_hostid 1 > vfs.zfs.recover 0 > vfs.zfs.txg.synctime_ms 1000 > vfs.zfs.txg.timeout 10 > vfs.zfs.scrub_limit 10 > vfs.zfs.vdev.cache.bshift 16 > vfs.zfs.vdev.cache.size 0 > vfs.zfs.vdev.cache.max 16384 > vfs.zfs.vdev.write_gap_limit 4096 > vfs.zfs.vdev.read_gap_limit 32768 > vfs.zfs.vdev.aggregation_limit 131072 > vfs.zfs.vdev.ramp_rate 2 > vfs.zfs.vdev.time_shift 6 > vfs.zfs.vdev.min_pending 4 > vfs.zfs.vdev.max_pending 10 > vfs.zfs.vdev.bio_flush_disable 0 > vfs.zfs.cache_flush_disable 0 > vfs.zfs.zil_replay_disable 0 > vfs.zfs.zio.use_uma 0 > vfs.zfs.version.zpl 5 > vfs.zfs.version.spa 28 > vfs.zfs.version.acl 1 > vfs.zfs.debug 0 > vfs.zfs.super_owner 0 > > ------------------------------------------------------------------------ I see that you are limiting your arc.max to 3G but you have prefetch enabled. You can try disabling this: vfs.zfs.prefetch_disable=1 If things turn out better you can increase your arc.mac to 4G Regards -- George Kontostanos Aicom telecoms ltdhttp://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 11:36:46 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 145CC1065673 for ; Wed, 15 Feb 2012 11:36:46 +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 82C6B8FC08 for ; Wed, 15 Feb 2012 11:36:43 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MGV7M-1RkRtS1Lai-00DKkk; Wed, 15 Feb 2012 12:36:42 +0100 Message-ID: <4F3B98C9.1090400@brockmann-consult.de> Date: Wed, 15 Feb 2012 12:36:41 +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: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> In-Reply-To: <92617.1329301696.6338962447434776576@ffe5.ukr.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:RKj1iaSv8QH+2PDhsC1zvJbPO4pmJ8IUfZlfuoGsRTS mnkyFONdBwdsPLis0FQQMsu5sA3ebiPUOViRe+RDTg4yr5VhO6 a8H3/bQoxmrSeAeLS4ALyg8yGff1IR6ZmYIfAyOI3losBE4sei di2jEtCGPLeBIXrDFsVee3tlxNZmLlgIswcfEtRQUgykV2qLUv fY8BdIeaWFnKm1N/W3l6hrjRvKLYKBT0PEOjesj3GNwS0A16MZ 1kManC94/as762TmcC3vGqZNHc5C64opI2Nhz4FF35bIdac0+/ AWaVd+GpzAzjSMVOloOcBaBOSeVLy9vjytB+P8ibWLHGcdk4Ce y7mbt/aN+oRJdOIcy00FpqpaWqP198nhHWMb+I0Ni Subject: Re: ZFS and mem management 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, 15 Feb 2012 11:36:46 -0000 Can you also post: zpool get all And does your indexing scan through the .zfs/snapshot directory? If so, this is a known issue that totally eats your memory, resulting in swap space errors. On 02/15/2012 11:28 AM, Pavlo wrote: > > > Hey George, > > thanks for quick response. > > No, no dedup is used. > > zfs-stats -a : > > ------------------------------------------------------------------------ > ZFS Subsystem Report Wed Feb 15 12:26:18 2012 > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: 802516 (osreldate) > Hardware Platform: amd64 > Processor Architecture: amd64 > > ZFS Storage pool Version: 28 > ZFS Filesystem Version: 5 > > FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root > 12:26PM up 2:29, 7 users, load averages: 0.02, 0.16, 0.16 > > ------------------------------------------------------------------------ > > System Memory: > > 19.78% 1.53 GiB Active, 0.95% 75.21 MiB Inact > 36.64% 2.84 GiB Wired, 0.06% 4.83 MiB Cache > 42.56% 3.30 GiB Free, 0.01% 696.00 KiB Gap > > Real Installed: 8.00 GiB > Real Available: 99.84% 7.99 GiB > Real Managed: 96.96% 7.74 GiB > > Logical Total: 8.00 GiB > Logical Used: 57.82% 4.63 GiB > Logical Free: 42.18% 3.37 GiB > > Kernel Memory: 2.43 GiB > Data: 99.54% 2.42 GiB > Text: 0.46% 11.50 MiB > > Kernel Memory Map: 3.16 GiB > Size: 69.69% 2.20 GiB > Free: 30.31% 979.48 MiB > > ------------------------------------------------------------------------ > > ARC Summary: (THROTTLED) > Memory Throttle Count: 3.82k > > ARC Misc: > Deleted: 874.34k > Recycle Misses: 376.12k > Mutex Misses: 4.74k > Evict Skips: 4.74k > > ARC Size: 68.53% 2.34 GiB > Target Size: (Adaptive) 68.54% 2.34 GiB > Min Size (Hard Limit): 12.50% 437.50 MiB > Max Size (High Water): 8:1 3.42 GiB > > ARC Size Breakdown: > Recently Used Cache Size: 92.95% 2.18 GiB > Frequently Used Cache Size: 7.05% 169.01 MiB > > ARC Hash Breakdown: > Elements Max: 229.96k > Elements Current: 40.05% 92.10k > Collisions: 705.52k > Chain Max: 11 > Chains: 20.64k > > ------------------------------------------------------------------------ > > ARC Efficiency: 7.96m > Cache Hit Ratio: 84.92% 6.76m > Cache Miss Ratio: 15.08% 1.20m > Actual Hit Ratio: 76.29% 6.08m > > Data Demand Efficiency: 91.32% 4.99m > Data Prefetch Efficiency: 19.57% 134.19k > > CACHE HITS BY CACHE LIST: > Anonymously Used: 7.24% 489.41k > Most Recently Used: 25.29% 1.71m > Most Frequently Used: 64.54% 4.37m > Most Recently Used Ghost: 1.42% 95.77k > Most Frequently Used Ghost: 1.51% 102.33k > > CACHE HITS BY DATA TYPE: > Demand Data: 67.42% 4.56m > Prefetch Data: 0.39% 26.26k > Demand Metadata: 22.41% 1.52m > Prefetch Metadata: 9.78% 661.25k > > CACHE MISSES BY DATA TYPE: > Demand Data: 36.11% 433.60k > Prefetch Data: 8.99% 107.94k > Demand Metadata: 32.00% 384.29k > Prefetch Metadata: 22.91% 275.09k > > ------------------------------------------------------------------------ > > L2ARC is disabled > > ------------------------------------------------------------------------ > > File-Level Prefetch: (HEALTHY) > > DMU Efficiency: 26.49m > Hit Ratio: 71.64% 18.98m > Miss Ratio: 28.36% 7.51m > > Colinear: 7.51m > Hit Ratio: 0.02% 1.42k > Miss Ratio: 99.98% 7.51m > > Stride: 18.85m > Hit Ratio: 99.97% 18.85m > Miss Ratio: 0.03% 5.73k > > DMU Misc: > Reclaim: 7.51m > Successes: 0.29% 21.58k > Failures: 99.71% 7.49m > > Streams: 130.46k > +Resets: 0.35% 461 > -Resets: 99.65% 130.00k > Bogus: 0 > > ------------------------------------------------------------------------ > > VDEV cache is disabled > > ------------------------------------------------------------------------ > > ZFS Tunables (sysctl): > kern.maxusers 384 > vm.kmem_size 4718592000 > vm.kmem_size_scale 1 > vm.kmem_size_min 0 > vm.kmem_size_max 329853485875 > vfs.zfs.l2c_only_size 0 > vfs.zfs.mfu_ghost_data_lsize 2705408 > vfs.zfs.mfu_ghost_metadata_lsize 332861440 > vfs.zfs.mfu_ghost_size 335566848 > vfs.zfs.mfu_data_lsize 1641984 > vfs.zfs.mfu_metadata_lsize 3048448 > vfs.zfs.mfu_size 28561920 > vfs.zfs.mru_ghost_data_lsize 68477440 > vfs.zfs.mru_ghost_metadata_lsize 62875648 > vfs.zfs.mru_ghost_size 131353088 > vfs.zfs.mru_data_lsize 1651216384 > vfs.zfs.mru_metadata_lsize 278577152 > vfs.zfs.mru_size 2306510848 > vfs.zfs.anon_data_lsize 0 > vfs.zfs.anon_metadata_lsize 0 > vfs.zfs.anon_size 12968960 > vfs.zfs.l2arc_norw 1 > vfs.zfs.l2arc_feed_again 1 > vfs.zfs.l2arc_noprefetch 1 > vfs.zfs.l2arc_feed_min_ms 200 > vfs.zfs.l2arc_feed_secs 1 > vfs.zfs.l2arc_headroom 2 > vfs.zfs.l2arc_write_boost 8388608 > vfs.zfs.l2arc_write_max 8388608 > vfs.zfs.arc_meta_limit 917504000 > vfs.zfs.arc_meta_used 851157616 > vfs.zfs.arc_min 458752000 > vfs.zfs.arc_max 3670016000 > vfs.zfs.dedup.prefetch 1 > vfs.zfs.mdcomp_disable 0 > vfs.zfs.write_limit_override 1048576000 > vfs.zfs.write_limit_inflated 25728073728 > vfs.zfs.write_limit_max 1072003072 > vfs.zfs.write_limit_min 33554432 > vfs.zfs.write_limit_shift 3 > vfs.zfs.no_write_throttle 0 > vfs.zfs.zfetch.array_rd_sz 1048576 > vfs.zfs.zfetch.block_cap 256 > vfs.zfs.zfetch.min_sec_reap 2 > vfs.zfs.zfetch.max_streams 8 > vfs.zfs.prefetch_disable 0 > vfs.zfs.mg_alloc_failures 8 > vfs.zfs.check_hostid 1 > vfs.zfs.recover 0 > vfs.zfs.txg.synctime_ms 1000 > vfs.zfs.txg.timeout 10 > vfs.zfs.scrub_limit 10 > vfs.zfs.vdev.cache.bshift 16 > vfs.zfs.vdev.cache.size 0 > vfs.zfs.vdev.cache.max 16384 > vfs.zfs.vdev.write_gap_limit 4096 > vfs.zfs.vdev.read_gap_limit 32768 > vfs.zfs.vdev.aggregation_limit 131072 > vfs.zfs.vdev.ramp_rate 2 > vfs.zfs.vdev.time_shift 6 > vfs.zfs.vdev.min_pending 4 > vfs.zfs.vdev.max_pending 10 > vfs.zfs.vdev.bio_flush_disable 0 > vfs.zfs.cache_flush_disable 0 > vfs.zfs.zil_replay_disable 0 > vfs.zfs.zio.use_uma 0 > vfs.zfs.version.zpl 5 > vfs.zfs.version.spa 28 > vfs.zfs.version.acl 1 > vfs.zfs.debug 0 > vfs.zfs.super_owner 0 > > ------------------------------------------------------------------------ > > > > > > 2012/2/15 Pavlo : >> >> >> Hello. >> >> We have an issue with memory management on FreeBSD and i suspect it is >> related to FS. >> We are using ZFS, here quick stats: >> >> >> zpool status >> pool: disk1 >> state: ONLINE >> scan: resilvered 657G in 8h30m with 0 errors on Tue Feb 14 21:17:37 2012 >> config: >> >> NAME STATE READ WRITE CKSUM >> disk1 ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/disk0 ONLINE 0 0 0 >> gpt/disk1 ONLINE 0 0 0 >> gpt/disk2 ONLINE 0 0 0 >> gpt/disk4 ONLINE 0 0 0 >> gpt/disk6 ONLINE 0 0 0 >> gpt/disk8 ONLINE 0 0 0 >> gpt/disk10 ONLINE 0 0 0 >> gpt/disk12 ONLINE 0 0 0 >> mirror-7 ONLINE 0 0 0 >> gpt/disk14 ONLINE 0 0 0 >> gpt/disk15 ONLINE 0 0 0 >> >> errors: No known data errors >> >> pool: zroot >> state: ONLINE >> scan: resilvered 34.9G in 0h11m with 0 errors on Tue Feb 14 12:57:52 2012 >> config: >> >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> mirror-0 ONLINE 0 0 0 >> gpt/sys0 ONLINE 0 0 0 >> gpt/sys1 ONLINE 0 0 0 >> >> errors: No known data errors >> >> ------------------------------------------------------------------------ >> >> System Memory: >> >> 0.95% 75.61 MiB Active, 0.24% 19.02 MiB Inact >> 18.25% 1.41 GiB Wired, 0.01% 480.00 KiB Cache >> 80.54% 6.24 GiB Free, 0.01% 604.00 KiB Gap >> >> Real Installed: 8.00 GiB >> Real Available: 99.84% 7.99 GiB >> Real Managed: 96.96% 7.74 GiB >> >> Logical Total: 8.00 GiB >> Logical Used: 21.79% 1.74 GiB >> Logical Free: 78.21% 6.26 GiB >> >> Kernel Memory: 1.18 GiB >> Data: 99.05% 1.17 GiB >> Text: 0.95% 11.50 MiB >> >> Kernel Memory Map: 4.39 GiB >> Size: 23.32% 1.02 GiB >> Free: 76.68% 3.37 GiB >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> ZFS Subsystem Report Wed Feb 15 10:53:03 2012 >> ------------------------------------------------------------------------ >> >> System Information: >> >> Kernel Version: 802516 (osreldate) >> Hardware Platform: amd64 >> Processor Architecture: amd64 >> >> ZFS Storage pool Version: 28 >> ZFS Filesystem Version: 5 >> >> FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root >> 10:53AM up 56 mins, 6 users, load averages: 0.00, 0.00, 0.00 >> >> ------------------------------------------------------------------------ >> >> >> >> >> Background: >> we are using some tool that does indexing of some data and then pushes it >> into database (currently bdb-5.2). Instances of indexer are running >> continuously one after another. Time of indexing for one instance of >> indexer may vary between 2 seconds and 30 minutes. But mostly it is >> below one minute. There is nothing else running on the machine except >> system stuff and daemons. After several hours of indexing i can see a lot >> of active memory, it's ok. Then i check the number of vnodes. and it's >> really huge: 300k+ even tho nobody has so many opened files. Reading docs >> and googling i figured that's because of cached pages that reside in >> memory (unmounting of disk causes whole memory to be freed). Also I >> figured that happens only when I am accessing files via mmap(). >> >> Looks like pretty legit behaviour but the issue is: >> This spectacle continues (approximately for 12 hours) unlit indexers >> began to be killed out of swap. As I wrote above I observe a lot of used >> vnodes and like 7GB of active memory. I made a tool that allocates memory >> using malloc() to check what's the limit of available memory that can be >> allocated. It is several megabytes, sometimes more. Unless that tool gets >> killed out of swap as well. So how i can see the issue: for some reason >> after some process had exited normally all mapped pages don't get freed. >> I red about and I agree that this is reasonable behaviour if we have >> spare memory. But following this logic these pages can be flushed back to >> file at any time when system is under stress conditions. So when I ask >> for a piece of RAM, OS should do that trick and give me what I ask. But >> that's never happens. Those pages are like frozen. Until I unmount disk. >> Even after there is not a single instance of indexer running. >> >> I believe all this is caused by mmap() for sure : BDB uses mmap() for >> accessing databases and we tested indexing with out pushing data to DB. >> Worked shiny. You may suggest that that's something wrong with BDB. But >> we have some more tools of ours that using mmap() as well and the >> behaviour is exact. >> >> Thank you. Paul, Ukraine. >> _______________________________________________ >> 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" > Hi Paul, > > Are you using dedup anywhere on that pool? > > Also, could you please post the full zfs-stats -a > > -- -------------------------------------------- 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 Feb 15 12:28: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 12AAA106564A for ; Wed, 15 Feb 2012 12:28:01 +0000 (UTC) (envelope-from gkontos.mail@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 C96178FC15 for ; Wed, 15 Feb 2012 12:28:00 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1803231iae.13 for ; Wed, 15 Feb 2012 04:28:00 -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=zV2OjmwHXm3K+D/aFXxZY5LNH2rE9twn59GaQ01GQig=; b=tBZx0hswKM9TsAV601OMItER/kjVD5kv2qSbp2U2ZH1UoHzPubjBV+nXYKo+pOD0b1 AryDtqhc0PmFC4xvaUfYIrx7wb1zXCAb5cRugoHptzcgi5+5xIIiKCjclmr+zgzuanRH ghS6I/IrgYgJMEDN+9jg6/R0VmFTkF8o4ZY5I= MIME-Version: 1.0 Received: by 10.43.126.67 with SMTP id gv3mr469191icc.50.1329308880464; Wed, 15 Feb 2012 04:28:00 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 04:28:00 -0800 (PST) In-Reply-To: <1329287228940-5485041.post@n5.nabble.com> References: <20101213143030.GE1740@garage.freebsd.pl> <1329243132007-5483280.post@n5.nabble.com> <861upxmdiz.fsf@kopusha.home.net> <1329287228940-5485041.post@n5.nabble.com> Date: Wed, 15 Feb 2012 14:28:00 +0200 Message-ID: From: George Kontostanos To: fannyfauzi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: HAST role failure 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, 15 Feb 2012 12:28:01 -0000 On Wed, Feb 15, 2012 at 8:27 AM, fannyfauzi wrote: > Hi, > > And does /dev/ada0p4 device exist? > yeah.. the previous i did 'umount /dev/ada0p4'.. and i returned to 'mount > /dev/ada0p4' > > xiaoxi# df -h > Filesystem =A0 =A0 Size =A0 =A0Used =A0 Avail Capacity =A0Mounted on > /dev/ada0p2 =A0 =A09.9G =A0 =A06.2G =A0 =A02.9G =A0 =A068% =A0 =A0/ > devfs =A0 =A0 =A0 =A0 =A01.0k =A0 =A01.0k =A0 =A0 =A00B =A0 100% =A0 =A0/= dev > /dev/ada0p3 =A0 =A0 =A04G =A0 =A0 32M =A0 =A03.6G =A0 =A0 1% =A0 =A0/home > /dev/ada0p4 =A0 =A0 =A04G =A0 =A0 32M =A0 =A03.6G =A0 =A0 1% =A0 =A0/shar= ed > > xiaoxi# hastctl role primary shared > xiaoxi# hastctl status shared > shared: > =A0role: init > =A0provname: shared > =A0localpath: /dev/ada0p4 > =A0extentsize: 0 (0B) > =A0keepdirty: 0 > =A0remoteaddr: tcp4://192.168.208.132 > =A0replication: fullsync > =A0dirty: 0 (0B) > =A0statistics: > =A0 =A0reads: 0 > =A0 =A0writes: 0 > =A0 =A0deletes: 0 > =A0 =A0flushes: 0 > =A0 =A0activemap updates: 0 > > Feb 15 14:17:18 xiaoxi hastd[66931]: [shared] (primary) Unable to open > /dev/ada0p4: Operation not permitted. > > I have ufs partition on /dev/ada0p4 > /dev/ada0p4 =A0 =A0 /shared =A0 =A0 =A0 =A0 ufs =A0 =A0 rw =A0 =A0 =A02 = =A0 =A0 =A0 2 > > should i delete ufs partition on /dev/ada0p4 or any other advices? > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/HAST-r= ole-failure-tp4033049p5485041.html > Sent from the freebsd-fs mailing list archive at Nabble.com. > _______________________________________________ > 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" Once your resource has been created you should be able to access it via /dev/hast/shared newfs -U /dev/hast/shared mount /dev/hast/shared /mnt Don't try to mount ada0p4. --=20 George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 12:39: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 9DE47106567B for ; Wed, 15 Feb 2012 12:39:45 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe5.ukr.net (ffe5.ukr.net [195.214.192.21]) by mx1.freebsd.org (Postfix) with ESMTP id 892878FC0A for ; Wed, 15 Feb 2012 12:39:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=aZdhtwznpvldMPlym3Lau9NHyuKkeZS1U0Li3b0O6+c=; b=QvX/B9UJJ/b7uED9QjqKk9ef8+DjXY97Z/U2C7dOFutWQLwXSQ2W8HKFQxOXlEbBxSLLYuMqA5SEjmuQrdTuiDsy/pqKTsJ5Ht0QsymymFvIWBoqB0thwzowO+nEeweHVtgXmWoDRnBIDvlXQeZU6mQvGPvgpIEAEtRQ9Ilypcw=; Received: from mail by ffe5.ukr.net with local ID 1Rxe98-000P3a-Bh ; Wed, 15 Feb 2012 14:39:43 +0200 MIME-Version: 1.0 In-Reply-To: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <96280.1329309582.18313701080496209920@ffe5.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 14:39:42 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 12:39:45 -0000 Unfortunately we can't afford disabling prefetch. It is too much of an overhead. Also I made some tests. I have process that maps file using mmap() and writes or reads first byte of each page of mapped file with some data. There is 8Gb Ram on machine. Test 1: Tool maps 1.5GB file, writes first byte of each page with some random data. Wired memory get filled (with file cache ?) virtual address size of a process is 1.5Gb while RES is ~20mb. Not closing this tool I ask it to write data to each page again: Now Active memory get filled while Wired still of same size. Now I ask my next tool to allocate 6Gb of memory. It gets 5.8Gb and hangs in pagefault, sleeps there for about 10 seconds and gets killed out of swap. After 'memory eater' is killed I see 900mb of memory still in Active and that matches the RES size of the first tool (it been reduced). I suppose 900mb is memory that had no time to be flushed to file and give out free pages when allocator killed 'memory eater', however it had time to squeeze 600mb RAM out of first tool. But mostly I see 1.5Gb of Active RAM afterwards. What means even though we have 1.5Gb of memory that can be easily flushed back to the file that didn't happens (it always happens for Linux for example), 'memory eater' just hangs in pfault and later gets killed. Sometime this happens even after first tool is done it's job and unmaped file. 'Frozen' 1.5 Gb of Active memory still here. I want to say it is actually reusable if I run first tool again i.e. pages got recalimed. Test 2: Assuming the possibility of busyness of FS I will try only reading operations using mmap(); Case 1: tool does 2 runs through mmaped memory reading first byte of each page. After second run RES size gets almost equal to virtual address size i.e. almost every page was mapped into RAM. I use my 'memory eating' tool and ask for 6Gb again. After short hang in pfault it gets what I asked. While first tool's RES size is dramatically reduced. That's what I wanted. Case 2: tool does 10+ runs through mmaped memory reading first byte of each page. First time I run 'memory eater' sometimes it gets killed as in test 1 and sometimes it shares some pages. I can't understand where to dig. When RAM contains pages that are being only red it is not a problem to free them but sometimes it doesn't happen. I repeat again, even though Linux is differ so much from FreeBSD it always does 'right' thing: flushes pages and provide memory. Well at least I believe that is right thing. Thanks. > 2012/2/15 Pavlo : > > Hey George, > > thanks for quick response. > > No, no dedup is used. > > zfs-stats -a : > > ------------------------------------------------------------------------ > ZFS Subsystem Report Wed Feb 15 12:26:18 2012 > > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: 802516 (osreldate) > Hardware Platform: amd64 > Processor Architecture: amd64 > > ZFS Storage pool Version: 28 > ZFS Filesystem Version: 5 > > FreeBSD 8.2-STABLE #12: Thu Feb 9 11:35:23 EET 2012 root > 12:26PM up 2:29, 7 users, load averages: 0.02, 0.16, 0.16 > > ------------------------------------------------------------------------ > > System Memory: > > 19.78% 1.53 GiB Active, 0.95% 75.21 MiB Inact > 36.64% 2.84 GiB Wired, 0.06% 4.83 MiB Cache > 42.56% 3.30 GiB Free, 0.01% 696.00 KiB Gap > > > Real Installed: 8.00 GiB > Real Available: 99.84% 7.99 GiB > Real Managed: 96.96% 7.74 GiB > > Logical Total: 8.00 GiB > Logical Used: 57.82% 4.63 GiB > Logical Free: 42.18% 3.37 GiB > > Kernel Memory: 2.43 GiB > Data: 99.54% 2.42 GiB > Text: 0.46% 11.50 MiB > > Kernel Memory Map: 3.16 GiB > Size: 69.69% 2.20 GiB > Free: 30.31% 979.48 MiB > > ------------------------------------------------------------------------ > > ARC Summary: (THROTTLED) > Memory Throttle Count: 3.82k > > ARC Misc: > Deleted: 874.34k > Recycle Misses: 376.12k > Mutex Misses: 4.74k > Evict Skips: 4.74k > > ARC Size: 68.53% 2.34 GiB > Target Size: (Adaptive) 68.54% 2.34 GiB > Min Size (Hard Limit): 12.50% 437.50 MiB > Max Size (High Water): 8:1 3.42 GiB > > ARC Size Breakdown: > Recently Used Cache Size: 92.95% 2.18 GiB > Frequently Used Cache Size: 7.05% 169.01 MiB > > ARC Hash Breakdown: > Elements Max: 229.96k > Elements Current: 40.05% 92.10k > Collisions: 705.52k > Chain Max: 11 > Chains: 20.64k > > ------------------------------------------------------------------------ > > ARC Efficiency: 7.96m > Cache Hit Ratio: 84.92% 6.76m > Cache Miss Ratio: 15.08% 1.20m > Actual Hit Ratio: 76.29% 6.08m > > Data Demand Efficiency: 91.32% 4.99m > Data Prefetch Efficiency: 19.57% 134.19k > > CACHE HITS BY CACHE LIST: > Anonymously Used: 7.24% 489.41k > Most Recently Used: 25.29% 1.71m > Most Frequently Used: 64.54% 4.37m > Most Recently Used Ghost: 1.42% 95.77k > Most Frequently Used Ghost: 1.51% 102.33k > > CACHE HITS BY DATA TYPE: > Demand Data: 67.42% 4.56m > Prefetch Data: 0.39% 26.26k > Demand Metadata: 22.41% 1.52m > Prefetch Metadata: 9.78% 661.25k > > CACHE MISSES BY DATA TYPE: > Demand Data: 36.11% 433.60k > Prefetch Data: 8.99% 107.94k > Demand Metadata: 32.00% 384.29k > Prefetch Metadata: 22.91% 275.09k > > ------------------------------------------------------------------------ > > L2ARC is disabled > > ------------------------------------------------------------------------ > > File-Level Prefetch: (HEALTHY) > > DMU Efficiency: 26.49m > Hit Ratio: 71.64% 18.98m > Miss Ratio: 28.36% 7.51m > > Colinear: 7.51m > Hit Ratio: 0.02% 1.42k > Miss Ratio: 99.98% 7.51m > > Stride: 18.85m > Hit Ratio: 99.97% 18.85m > Miss Ratio: 0.03% 5.73k > > DMU Misc: > Reclaim: 7.51m > Successes: 0.29% 21.58k > Failures: 99.71% 7.49m > > Streams: 130.46k > +Resets: 0.35% 461 > -Resets: 99.65% 130.00k > Bogus: 0 > > ------------------------------------------------------------------------ > > VDEV cache is disabled > > ------------------------------------------------------------------------ > > ZFS Tunables (sysctl): > kern.maxusers 384 > vm.kmem_size 4718592000 > vm.kmem_size_scale 1 > vm.kmem_size_min 0 > vm.kmem_size_max 329853485875 > vfs.zfs.l2c_only_size 0 > vfs.zfs.mfu_ghost_data_lsize 2705408 > vfs.zfs.mfu_ghost_metadata_lsize 332861440 > vfs.zfs.mfu_ghost_size 335566848 > vfs.zfs.mfu_data_lsize 1641984 > vfs.zfs.mfu_metadata_lsize 3048448 > vfs.zfs.mfu_size 28561920 > vfs.zfs.mru_ghost_data_lsize 68477440 > vfs.zfs.mru_ghost_metadata_lsize 62875648 > vfs.zfs.mru_ghost_size 131353088 > vfs.zfs.mru_data_lsize 1651216384 > vfs.zfs.mru_metadata_lsize 278577152 > vfs.zfs.mru_size 2306510848 > vfs.zfs.anon_data_lsize 0 > vfs.zfs.anon_metadata_lsize 0 > vfs.zfs.anon_size 12968960 > vfs.zfs.l2arc_norw 1 > vfs.zfs.l2arc_feed_again 1 > vfs.zfs.l2arc_noprefetch 1 > vfs.zfs.l2arc_feed_min_ms 200 > vfs.zfs.l2arc_feed_secs 1 > vfs.zfs.l2arc_headroom 2 > vfs.zfs.l2arc_write_boost 8388608 > vfs.zfs.l2arc_write_max 8388608 > vfs.zfs.arc_meta_limit 917504000 > vfs.zfs.arc_meta_used 851157616 > vfs.zfs.arc_min 458752000 > vfs.zfs.arc_max 3670016000 > vfs.zfs.dedup.prefetch 1 > vfs.zfs.mdcomp_disable 0 > vfs.zfs.write_limit_override 1048576000 > vfs.zfs.write_limit_inflated 25728073728 > vfs.zfs.write_limit_max 1072003072 > vfs.zfs.write_limit_min 33554432 > vfs.zfs.write_limit_shift 3 > vfs.zfs.no_write_throttle 0 > vfs.zfs.zfetch.array_rd_sz 1048576 > vfs.zfs.zfetch.block_cap 256 > vfs.zfs.zfetch.min_sec_reap 2 > vfs.zfs.zfetch.max_streams 8 > vfs.zfs.prefetch_disable 0 > vfs.zfs.mg_alloc_failures 8 > vfs.zfs.check_hostid 1 > vfs.zfs.recover 0 > vfs.zfs.txg.synctime_ms 1000 > vfs.zfs.txg.timeout 10 > vfs.zfs.scrub_limit 10 > vfs.zfs.vdev.cache.bshift 16 > vfs.zfs.vdev.cache.size 0 > vfs.zfs.vdev.cache.max 16384 > vfs.zfs.vdev.write_gap_limit 4096 > vfs.zfs.vdev.read_gap_limit 32768 > vfs.zfs.vdev.aggregation_limit 131072 > vfs.zfs.vdev.ramp_rate 2 > vfs.zfs.vdev.time_shift 6 > vfs.zfs.vdev.min_pending 4 > vfs.zfs.vdev.max_pending 10 > vfs.zfs.vdev.bio_flush_disable 0 > vfs.zfs.cache_flush_disable 0 > vfs.zfs.zil_replay_disable 0 > vfs.zfs.zio.use_uma 0 > vfs.zfs.version.zpl 5 > vfs.zfs.version.spa 28 > vfs.zfs.version.acl 1 > vfs.zfs.debug 0 > vfs.zfs.super_owner 0 > > ------------------------------------------------------------------------ I see that you are limiting your arc.max to 3G but you have prefetch enabled. You can try disabling this: vfs.zfs.prefetch_disable=1 If things turn out better you can increase your arc.mac to 4G Regards -- George Kontostanos Aicom telecoms ltdhttp://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 14:02: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 1CB59106564A for ; Wed, 15 Feb 2012 14:02:19 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id C12168FC1D for ; Wed, 15 Feb 2012 14:02:18 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RxfR2-0007NQ-F3 for freebsd-fs@freebsd.org; Wed, 15 Feb 2012 15:02:16 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Feb 2012 15:02:16 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Feb 2012 15:02:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Wed, 15 Feb 2012 15:02:06 +0100 Lines: 40 Message-ID: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> <96280.1329309582.18313701080496209920@ffe5.ukr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEFAF81B6357F075B35F57CCB" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <96280.1329309582.18313701080496209920@ffe5.ukr.net> X-Enigmail-Version: 1.3.5 Subject: Re: ZFS and mem management 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, 15 Feb 2012 14:02:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEFAF81B6357F075B35F57CCB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15/02/2012 13:39, Pavlo wrote: >=20 >=20 >=20 > Unfortunately we can't afford disabling prefetch. It is too much of an > overhead. >=20 > Also I made some tests. I have process that maps file using mmap() and > writes or reads first byte of each page of mapped file with some data. Note that ZFS is designed so that it interacts somewhat badly with mmap() and other kernel services which rely on coherency between VM and IO such as sendfile(). At the very best, you will have two in-kernel copies of all data buffers used with such interfaces, but there have been sporadic reports that there are other bugs with it. If you have a test server, I'd recommend you do the same test on UFS for comparison. --------------enigEFAF81B6357F075B35F57CCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk87ut4ACgkQldnAQVacBcjuBQCg1GDudjWQbtYC/SbAsepeYOnH gD4AnitS65MVKbGBkXGfjYb7ZpOSsKi9 =fEBM -----END PGP SIGNATURE----- --------------enigEFAF81B6357F075B35F57CCB-- From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 14:54: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 1EAFE1065670; Wed, 15 Feb 2012 14:54:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9D38E8FC14; Wed, 15 Feb 2012 14:54:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1FEsBCu051002 ; Wed, 15 Feb 2012 15:54:11 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1FErcnH094628; Wed, 15 Feb 2012 15:53:38 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1FErbN5094625; Wed, 15 Feb 2012 15:53:37 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Wed, 15 Feb 2012 15:53:37 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3BC713.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3BC713.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 15 Feb 2012 14:54:25 -0000 Hello, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? [root@cc ~]# dd if=/dev/ada0s3.eli of=/dev/null bs=4096 conv=noerror 103746635+0 records in 103746635+0 records out 424946216960 bytes transferred in 18773.796016 secs (22635072 bytes/sec) [root@cc ~]# > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? Looks like each scrub worsens the situation : [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 148K in 0h14m with 26 errors on Mon Feb 13 18:54:33 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 26 ada0s3.eli ONLINE 0 0 87 errors: Permanent errors have been detected in the following files: [ 11 files ] [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub in progress since Wed Feb 15 14:36:52 2012 17.7G scanned out of 28.7G at 72.1M/s, 0h2m to go 0 repaired, 61.56% done config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 54 ada0s3.eli ONLINE 0 0 143 errors: Permanent errors have been detected in the following files: [ 11 files ] # [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 4K in 0h7m with 70 errors on Wed Feb 15 14:43:57 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 96 ada0s3.eli ONLINE 0 0 228 errors: Permanent errors have been detected in the following files: [ 25 files (cannot quickly see iff it contains all old 11 files) ] [root@cc ~]# [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 0h6m with 70 errors on Wed Feb 15 15:19:28 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 166 ada0s3.eli ONLINE 0 0 368 errors: Permanent errors have been detected in the following files: [ 25 files ] [root@cc ~]# > 3) Can you try zfs without geli? > > 4) Is the slice/partition layout definitely correct? > > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 14:57:46 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 C216F1065670 for ; Wed, 15 Feb 2012 14:57:46 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe5.ukr.net (ffe5.ukr.net [195.214.192.21]) by mx1.freebsd.org (Postfix) with ESMTP id 690B18FC14 for ; Wed, 15 Feb 2012 14:57:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=mYFt9P/lk37+3aV/+grHu6KguNSLZxifhqNYnuXwumE=; b=tEpbug/rjwpnzs80PmsIIP+ccpe8ljQQtwgszZbgZxQiv2/lMtCxtp4E9wS3em6OwL6hrijaQCk7asl6ckHuJcJcA77X2dSm6dj1qYYylhyGcHZE9cEyM9/ZroUcHNb8uLg0zTBrP0x2+C9HZL1xlt1TbxRWWxvba5IgcmIuHvU=; Received: from mail by ffe5.ukr.net with local ID 1RxgIj-0001qH-2D ; Wed, 15 Feb 2012 16:57:45 +0200 MIME-Version: 1.0 In-Reply-To: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <6808.1329317865.13903133224449736704@ffe5.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 16:57:45 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 14:57:46 -0000 zpool get all disk1 NAME PROPERTY VALUE SOURCE disk1 size 7.21T - disk1 capacity 71% - disk1 altroot - default disk1 health DEGRADED - disk1 guid 4448512342659541304 default disk1 version 28 default disk1 bootfs - default disk1 delegation on default disk1 autoreplace off default disk1 cachefile - default disk1 failmode continue local disk1 listsnapshots off default disk1 autoexpand off default disk1 dedupditto 0 default disk1 dedupratio 1.00x - disk1 free 2.09T - disk1 allocated 5.12T - disk1 readonly off - disk1 comment - default Nope, it doesn't scan .zfs/snapshot directory. Please ignore health, that's just test machine. Also the problem seems to be not about reading/writing, rather about using mmap(). I just couldn't find better mailing list for my issue... From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 15:06:53 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 F2F661065678 for ; Wed, 15 Feb 2012 15:06:53 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1078FC08 for ; Wed, 15 Feb 2012 15:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=0Wi659HSVc0fvBPnwI90Y/FOzNyW6RJoY4mR7e1H9fc=; b=JsdkU0gOYLK5HZrVHS49PaS14ml4FGz6HNycPnU1PnhS2VmfaqxcVv/dy8LjJsX6m6vptShzwmKM+z2L4Lgkh1fQNimKd+LfFGIuKVeeSrGeIuqA/CsxvihCdgYpD0SJ1nY7bbJNoSuuOH1zamW+bFbQ/Kc9DpEbDH15eaRTWno=; Received: from mail by ffe16.ukr.net with local ID 1RxgRY-000Igh-50 for freebsd-fs@freebsd.org; Wed, 15 Feb 2012 17:06:52 +0200 MIME-Version: 1.0 To: freebsd-fs@freebsd.org From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <70229.1329318412.9319724204137054208@ffe16.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 17:06:52 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ZFS and mem management 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, 15 Feb 2012 15:06:54 -0000 >On 15/02/2012 13:39, Pavlo wrote: >> >> >> >> Unfortunately we can't afford disabling prefetch. It is too much of an>> overhead.>> >> Also I made some tests. I have process that maps file using mmap() and>> writes or reads first byte of each page of mapped file with some data.> >Note that ZFS is designed so that it interacts somewhat badly with >mmap() and other kernel services which rely on coherency between VM and >IO such as sendfile(). At the very best, you will have two in-kernel >copies of all data buffers used with such interfaces, but there have >been sporadic reports that there are other bugs with it. > >If you have a test server, I'd recommend you do the same test on UFS for >comparison. Was going to try this... Thanks for reply. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 15:27: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 58CBC106567E for ; Wed, 15 Feb 2012 15:27:52 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16CE38FC15 for ; Wed, 15 Feb 2012 15:27:52 +0000 (UTC) Received: by ggnk5 with SMTP id k5so800801ggn.13 for ; Wed, 15 Feb 2012 07:27:51 -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=L6m3hKsX4wVT36SfOUhGYbTWt9h/T//Obe8fOGtQ4KA=; b=ggdG9mLVoskUKl4SLgyWHatrO0/vpTSoGh7DSXuwaiTVacvXUzk5NMqzkqDPTWqwiY rUSDbcNuUYPA/ga25juIG53QkgShzMoxQnsJAK+By3J7j5UXNiYpqWW8pggIKXpq7sYQ +Odhu9yTejHdQWTWFWJqMaby0NfKhuEaYWv6Y= MIME-Version: 1.0 Received: by 10.50.216.231 with SMTP id ot7mr42460973igc.8.1329319671296; Wed, 15 Feb 2012 07:27:51 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 07:27:51 -0800 (PST) In-Reply-To: <70229.1329318412.9319724204137054208@ffe16.ukr.net> References: <70229.1329318412.9319724204137054208@ffe16.ukr.net> Date: Wed, 15 Feb 2012 17:27:51 +0200 Message-ID: From: George Kontostanos To: Pavlo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 15:27:52 -0000 2012/2/15 Pavlo : > > > >>On 15/02/2012 13:39, Pavlo wrote: >>> > >>> >> >> Unfortunately we can't afford disabling prefetch. It is too much of an>> overhead.>> >> Also I made some tests. I have process that maps file using mmap() and>> writes or reads first byte of each page of mapped file with some data.> >>Note that ZFS is designed so that it interacts somewhat badly with >>mmap() and other kernel services which rely on coherency between VM and >>IO such as sendfile(). At the very best, you will have two in-kernel >>copies of all data buffers used with such interfaces, but there have >>been sporadic reports that there are other bugs with it. >> >>If you have a test server, I'd recommend you do the same test on UFS for >>comparison. > > Was going to try this... Thanks for reply. > _______________________________________________ > 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" Why do you think that disabling prefetch is an overhead? -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 15:35: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 B7395106564A for ; Wed, 15 Feb 2012 15:35:16 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe1.ukr.net (ffe1.ukr.net [195.214.192.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0BB8FC0A for ; Wed, 15 Feb 2012 15:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=TKFYtQtc7yiL5F5mwYWwz+JDK9MQSmYNHz0TvdkuP6M=; b=P4aYJjCXfeoFZLUgwGe8zfZztPr7MFk8nYJATK52FrWlByFWFZgL55P9sUttI54/sNxLve9Rg9XUKt8WOYyKs4JUasf+GaBdHLcsJDZZ6Sz/sK6FdzkJSSujiaDL2xk48h326/Gsh/GbQZqRemiGq9m2Yk1ekyzjjcEnw5ds1OE=; Received: from mail by ffe1.ukr.net with local ID 1Rxgt0-000Anl-L5 ; Wed, 15 Feb 2012 17:35:14 +0200 MIME-Version: 1.0 In-Reply-To: References: <70229.1329318412.9319724204137054208@ffe16.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <41082.1329320114.6955040073494560768@ffe1.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 17:35:14 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 15:35:16 -0000 > 2012/2/15 Pavlo : > > > >>On 15/02/2012 13:39, Pavlo wrote: >>> > >>> >> >> Unfortunately we can't afford disabling prefetch. It is too much of an>> overhead.>> >> Also I made some tests. I have process that maps file using mmap() and>> writes or reads first byte of each page of mapped file with some data.> >>Note that ZFS is designed so that it interacts somewhat badly with >>mmap() and other kernel services which rely on coherency between VM and >>IO such as sendfile(). At the very best, you will have two in-kernel >>copies of all data buffers used with such interfaces, but there have >>been sporadic reports that there are other bugs with it. >> >>If you have a test server, I'd recommend you do the same test on UFS for >>comparison. > > Was going to try this... Thanks for reply. > _______________________________________________ > 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" Why do you think that disabling prefetch is an overhead? -- George Kontostanos Aicom telecoms ltdhttp://www.aisecure.net > Well... not me though. System administrator >_> . I suppose because we have a big IO traffic. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 15: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 23E54106564A for ; Wed, 15 Feb 2012 15:39:47 +0000 (UTC) (envelope-from gkontos.mail@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 E13228FC16 for ; Wed, 15 Feb 2012 15:39:46 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2073641iae.13 for ; Wed, 15 Feb 2012 07:39:45 -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=hqkRYkUmO3CPFWofk0zwuNPCxqdshEGoqCi6FiP7Mcs=; b=OoinEsVPk/q1sOjJ81zzKGayN5fH9MXkSVbuPGc7IjTs3sP5z5rlFGji8id7jBazqL nq6ayTp4T4U5SssFu/GTiiUnE+z3mo3ZK/OS5IQpvXK0HmtEAxOX057S8uoEFYv1kAmA l2vVZHLLyIQ+YFWhwbP6KU1PzxGw+L06PDFh8= MIME-Version: 1.0 Received: by 10.43.126.67 with SMTP id gv3mr1559964icc.50.1329320385730; Wed, 15 Feb 2012 07:39:45 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 07:39:45 -0800 (PST) In-Reply-To: <41082.1329320114.6955040073494560768@ffe1.ukr.net> References: <70229.1329318412.9319724204137054208@ffe16.ukr.net> <41082.1329320114.6955040073494560768@ffe1.ukr.net> Date: Wed, 15 Feb 2012 17:39:45 +0200 Message-ID: From: George Kontostanos To: Pavlo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 15:39:47 -0000 2012/2/15 Pavlo : > > > 2012/2/15 Pavlo : >> >> >> >>>On 15/02/2012 13:39, Pavlo wrote: >>>> >> >>>> >> >> Unfortunately we can't afford disabling prefetch. It is too much >>>> >> >> of an>> overhead.>> >> Also I made some tests. I have process that maps file >>>> >> >> using mmap() and>> writes or reads first byte of each page of mapped file >>>> >> >> with some data.> >>>Note that ZFS is designed so that it interacts somewhat badly with >>>mmap() and other kernel services which rely on coherency between VM and >>>IO such as sendfile(). At the very best, you will have two in-kernel >>>copies of all data buffers used with such interfaces, but there have >>>been sporadic reports that there are other bugs with it. >>> >>>If you have a test server, I'd recommend you do the same test on UFS for >>>comparison. >> >> Was going to try this... Thanks for reply. >> _______________________________________________ >> 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" > > Why do you think that disabling prefetch is an overhead? > > > -- > George Kontostanos > Aicom telecoms ltd > http://www.aisecure.net > > > > Well... not me though. System administrator >_> . I suppose because we have > a big IO traffic. Not for a highly random I/O environment. -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 15:44: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 B91C01065679 for ; Wed, 15 Feb 2012 15:44:19 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 46FA18FC14 for ; Wed, 15 Feb 2012 15:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=5XPzh5pRot8Rh7B0OHK9x6pnz/2UeL8q6UksFyAIfsY=; b=FCdkzkuSGn5mSqSbZJF1giLSaWAGHKGYpHbWPkj/Bi5fwOqlja4WlZdF/AlCJ2gAR4yuJzaeWMkTyx+gKJWwbUu1pvm0aCR4BGyXb8si2D5YwTRDuo1lvaZ4efdRyzIhqrM25VggT/YiDZhVJ5ocRy41Y+2MxPCvk7PLoBGy91I=; Received: from mail by ffe16.ukr.net with local ID 1Rxh1m-0001IR-5m ; Wed, 15 Feb 2012 17:44:18 +0200 MIME-Version: 1.0 In-Reply-To: References: <41082.1329320114.6955040073494560768@ffe1.ukr.net> <70229.1329318412.9319724204137054208@ffe16.ukr.net> To: "George Kontostanos" From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <4633.1329320658.10597993752278204416@ffe16.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Wed, 15 Feb 2012 17:44:18 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 15:44:19 -0000 --- Original message --- From: "George Kontostanos" To: "Pavlo" Date: 15 February 2012, 17:39:46 Subject: Re: ZFS and mem management > 2012/2/15 Pavlo : > > > 2012/2/15 Pavlo : >> >> >> >>>On 15/02/2012 13:39, Pavlo wrote: >>>> >> >>>> >> >> Unfortunately we can't afford disabling prefetch. It is too much >>>> >> >> of an>> overhead.>> >> Also I made some tests. I have process that maps file >>>> >> >> using mmap() and>> writes or reads first byte of each page of mapped file >>>> >> >> with some data.> >>>Note that ZFS is designed so that it interacts somewhat badly with >>>mmap() and other kernel services which rely on coherency between VM and >>>IO such as sendfile(). At the very best, you will have two in-kernel >>>copies of all data buffers used with such interfaces, but there have >>>been sporadic reports that there are other bugs with it. >>> >>>If you have a test server, I'd recommend you do the same test on UFS for >>>comparison. >> >> Was going to try this... Thanks for reply. >> _______________________________________________ >> 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" > > Why do you think that disabling prefetch is an overhead? > > > -- > George Kontostanos > Aicom telecoms ltd > http://www.aisecure.net> > > > Well... not me though. System administrator >_> . I suppose because we have > a big IO traffic. Not for a highly random I/O environment. -- George Kontostanos Aicom telecoms ltdhttp://www.aisecure.net > That's is a reason we don't disable. Our reads and writes mostly contiguous. And that problem arises on machines with low RAM (8Gb and less). Also for obvious reasons swap is disabled. From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 16:06:35 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 510C71065670 for ; Wed, 15 Feb 2012 16:06:35 +0000 (UTC) (envelope-from gkontos.mail@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 1C32E8FC0A for ; Wed, 15 Feb 2012 16:06:34 +0000 (UTC) Received: by iaeo4 with SMTP id o4so2109159iae.13 for ; Wed, 15 Feb 2012 08:06:34 -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=Y8M6FJjZz2kGsf0IY3gi0l5F/irHIFjd7j/sooxiYd4=; b=Dr3O9OQBrPr6oCOUvzCRCCX3NBIM8S/1ByUjyxPxgb7TaFtXXFd4/s18/ChgX1nDCq 8k6bmosvtJhgt47Q9NP6V50LQAIXP+S44DvYLT4xB+M1u4JECT2MNXttzTg3iJA+dGlg eEusBY33DZir2XK1f6UOK2rny6PQNBQc6K+G0= MIME-Version: 1.0 Received: by 10.42.138.193 with SMTP id d1mr34537549icu.0.1329321994522; Wed, 15 Feb 2012 08:06:34 -0800 (PST) Received: by 10.231.231.17 with HTTP; Wed, 15 Feb 2012 08:06:34 -0800 (PST) In-Reply-To: <4633.1329320658.10597993752278204416@ffe16.ukr.net> References: <41082.1329320114.6955040073494560768@ffe1.ukr.net> <70229.1329318412.9319724204137054208@ffe16.ukr.net> <4633.1329320658.10597993752278204416@ffe16.ukr.net> Date: Wed, 15 Feb 2012 18:06:34 +0200 Message-ID: From: George Kontostanos To: Pavlo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and mem management 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, 15 Feb 2012 16:06:35 -0000 2012/2/15 Pavlo : > > > --- Original message --- > From: "George Kontostanos" > To: "Pavlo" > Date: 15 February 2012, 17:39:46 > Subject: Re: ZFS and mem management > > > > 2012/2/15 Pavlo : >> >> >> 2012/2/15 Pavlo : >>> >>> >>> >>>>On 15/02/2012 13:39, Pavlo wrote: >>>>> >>> >>>>> >> >> Unfortunately we can't afford disabling prefetch. It is too much >>>>> >> >> of an>> overhead.>> >> Also I made some tests. I have process >>>>> >> >> that maps file >>>>> >> >> using mmap() and>> writes or reads first byte of each page of >>>>> >> >> mapped file >>>>> >> >> with some data.> >>>>Note that ZFS is designed so that it interacts somewhat badly with >>>>mmap() and other kernel services which rely on coherency between VM and >>>>IO such as sendfile(). At the very best, you will have two in-kernel >>>>copies of all data buffers used with such interfaces, but there have >>>>been sporadic reports that there are other bugs with it. >>>> >>>>If you have a test server, I'd recommend you do the same test on UFS for >>>>comparison. >>> >>> Was going to try this... Thanks for reply. >>> _______________________________________________ >>> 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" >> >> Why do you think that disabling prefetch is an overhead? >> >> >> -- >> George Kontostanos >> Aicom telecoms ltd >> http://www.aisecure.net >> >> >> >> Well... not me though. System administrator >_> . I suppose because we >> have >> a big IO traffic. > > Not for a highly random I/O environment. > > -- > George Kontostanos > Aicom telecoms ltd > http://www.aisecure.net > > > That's is a reason we don't disable. Our reads and writes mostly contiguous. > And that problem arises on machines with low RAM (8Gb and less). Also for > obvious reasons swap is disabled. > I guess then that a memory upgrade should be scheduled. -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 16:35:13 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 DAA59106564A for ; Wed, 15 Feb 2012 16:35:13 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7798FC08 for ; Wed, 15 Feb 2012 16:35:12 +0000 (UTC) Received: (qmail 21794 invoked from network); 15 Feb 2012 17:07:25 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 15 Feb 2012 17:07:25 +0100 References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> <96280.1329309582.18313701080496209920@ffe5.ukr.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Kai Gallasch Date: Wed, 15 Feb 2012 17:07:24 +0100 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1084) Subject: Re: ZFS and mem management 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, 15 Feb 2012 16:35:13 -0000 Am 15.02.2012 um 15:02 schrieb Ivan Voras: > On 15/02/2012 13:39, Pavlo wrote: >>=20 >>=20 >>=20 >> Unfortunately we can't afford disabling prefetch. It is too much of = an >> overhead. >>=20 >> Also I made some tests. I have process that maps file using mmap() = and >> writes or reads first byte of each page of mapped file with some = data. >=20 > Note that ZFS is designed so that it interacts somewhat badly with > mmap() and other kernel services which rely on coherency between VM = and > IO such as sendfile(). At the very best, you will have two in-kernel > copies of all data buffers used with such interfaces, but there have > been sporadic reports that there are other bugs with it. So best practice for running apache2 on FreeBSD ZFS is making sure = EnableMMAP and EnableSendfile are disabled in httpd.conf, right? (both are turned off by default) [httpd.conf] # EnableMMAP and EnableSendfile: On systems that support it,=20 # memory-mapping or the sendfile syscall is used to deliver # files. This usually improves server performance, but must # be turned off when serving from networked-mounted=20 # filesystems or if support for these functions is otherwise # broken on your system. # EnableMMAP off EnableSendfile off Kai.= From owner-freebsd-fs@FreeBSD.ORG Wed Feb 15 18:33:33 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3738106566C for ; Wed, 15 Feb 2012 18:33:33 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 90D0C8FC14 for ; Wed, 15 Feb 2012 18:33:33 +0000 (UTC) Received: (qmail 82041 invoked by uid 99); 15 Feb 2012 18:06:53 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 18:06:53 +0000 Received: from localhost (HELO daniel3.local) (127.0.0.1) (smtp-auth username danielsh, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2012 18:06:53 +0000 Date: Wed, 15 Feb 2012 20:06:35 +0200 From: Daniel Shahaf To: fs@freebsd.org Message-ID: <20120215180635.GA15435@daniel3.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: infrastructure-private@apache.org Subject: Fwd: [Daniel Shahaf: Re: zroot won't mount after 9.0-RC2 -> 9.0-RELEASE upgrade] 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, 15 Feb 2012 18:33:33 -0000 Forwarding to fs@ per a colleague's suggestion. tldr: amd64 host running 9.0-RC2 with zfs root won't boot 9.0-RELEASE's self-compiled GENERIC kernel, hanging at mountfrom>. Details below. The previous thread is here: http://thread.gmane.org/gmane.os.freebsd.questions/285708 Thanks. ----- Forwarded message from Daniel Shahaf ----- > Date: Wed, 15 Feb 2012 19:48:11 +0200 > From: Daniel Shahaf > To: questions@freebsd.org > Cc: "Philip M. Gollucci" , > infrastructure-private@apache.org > Subject: Re: zroot won't mount after 9.0-RC2 -> 9.0-RELEASE upgrade > Message-ID: <20120215174811.GA14636@daniel3.local> > > So far we've tried: > > - 'gpart bootcode -b' > - load geom_part_gpt.ko > - using zpool.cache from the 9.0-RELEASE CD > > And none of that seems to have had any effect. > > Additional info: from the CD environment, 'zpool import' reports an old > 'tank' pool on devices mfid[2-5]. (The 'zroot' pool uses mfid[0-5]p3.) > > Any further ideas, please? > > Thanks for all the suggestions so far. > > > Daniel Shahaf wrote on Wed, Feb 15, 2012 at 02:31:10 +0200: > > One of our amd64 servers runs 9.0-RC2 (releng/9.0@r228325) with a zfs root. > > > > It fails to boot the 9.0-RELEASE (releng/9.0@r229305) GENERIC kernel > > (self compiled) with a mountfrom error: > > > > http://people.apache.org/~danielsh/infra/loki-20120215-mountfrom.png > > mountfrom> zfs:zroot > > Trying to mount root from zfs:zroot []... > > Mounting from zfs:zroot failed with error 2. > > > > We've tried to upgrade the zpool format 15->28; the symptoms are > > unchanged. (The zroot fs is at version 4.) > > > > Why does 9.0-RC2 boot while 9.0-RELEASE (as /boot/testkernel) doesn't? > > What can do to boot 9.0-RELEASE from our zfs root filesystem? > > > > Thanks. > > > > [[[ > > % uname -a > > FreeBSD loki.apache.org 9.0-RC2 FreeBSD 9.0-RC2 #0: Sat Nov 12 18:35:25 UTC 2011 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > % cat /boot/loader.conf > > # zfs > > zfs_load="YES" > > vfs.root.mountfrom="zfs:zroot" > > > > # > > ipmi_load="YES" > > > > # Console for DRAC5 > > boot_multicons="YES" > > boot_serial="YES" > > comconsole_speed="57600" > > console="comconsole,vidconsole" > > hint.sio.0.flags=0 > > hint.sio.1.flags=0x10 > > > > accf_http_load="YES" > > accf_data_load="YES" > > % > > > > ]]] > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" ----- End forwarded message ----- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 16 08:03: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 0FB5A106566B for ; Thu, 16 Feb 2012 08:03:12 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from ffe2.ukr.net (ffe2.ukr.net [195.214.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id 581F48FC0A for ; Thu, 16 Feb 2012 08:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=ZJ5AWO/helP/BL+SjJdkcLQshpgTTiA9c4hDyN+oqpw=; b=K7JxII6RqEoy5gQLS5100WTdbiQqfl3Gb8pvh8AXZKM5uU4kfnlv7lG7Y5C48IvXzERLg+HuHJHPZak4AIXWUN1CK8bhms0x0z2CO/NbohJwOzT/VJAMyhy9rQO1TdkHzzbUXcjb7pjvtqvkcCLIVyYyPnpUCAO18AvjokKCEG4=; Received: from mail by ffe2.ukr.net with local ID 1RxwJ3-0009ce-IR ; Thu, 16 Feb 2012 10:03:09 +0200 MIME-Version: 1.0 In-Reply-To: References: <41082.1329320114.6955040073494560768@ffe1.ukr.net> <70229.1329318412.9319724204137054208@ffe16.ukr.net> To: freebsd-fs@freebsd.org From: "Pavlo" X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [212.42.94.154] Message-Id: <35197.1329379389.10113652667292975104@ffe2.ukr.net> X-Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.1) Gecko/20100101 Firefox/10.0.1 Date: Thu, 16 Feb 2012 10:03:09 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ZFS and mem management 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, 16 Feb 2012 08:03:12 -0000 Interesting stuff follows: >From log: Feb 16 04:28:39 zebra-test kernel: pid 29258 (thread), uid 8, was killed: out of swap space Now let's see top log for a night : Second before: ------------------------------------------------------------------------------------------------------------------------ Thu Feb 16 04:28:38 EET 2012 last pid: 31341; load averages: 0.04, 0.05, 0.00 up 0+15:25:11 04:28:38 61 processes: 1 running, 60 sleeping Mem: 2514M Active, 2058M Inact, 3109M Wired, 142M Cache, 96K Buf, 106M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29258 mail 1 45 0 37960K 6064K zio->i 3 0:08 2.10% thread 1750 root 1 44 0 25024K 1772K select 0 4:24 0.10% snmpd 1967 root 1 76 0 5716K 892K piperd 1 1:09 0.00% sh 1913 gs 1 76 0 9704K 1328K pause 0 0:41 0.00% zsh 15920 gs 1 44 0 9400K 2028K select 1 0:33 0.00% top 71345 gs 1 44 0 38132K 936K select 2 0:29 0.00% sshd 1889 gs 1 44 0 9100K 620K nanslp 2 0:13 0.00% iostat 1886 gs 1 44 0 38132K 848K select 3 0:12 0.00% sshd 52290 gs 1 44 0 5844K 856K kqread 0 0:05 0.00% tail 1902 gs 1 44 0 38132K 1044K select 3 0:04 0.00% sshd 1891 satan 1 44 0 9396K 688K select 3 0:04 0.00% screen 1357 nagios 1 44 0 6908K 512K select 0 0:02 0.00% nrpe2 1153 root 1 44 0 6936K 748K select 1 0:01 0.00% syslogd 1632 root 1 44 0 5428K 432K nanslp 0 0:00 0.00% cron 1912 gs 1 44 0 38132K 792K select 1 0:00 0.00% sshd 71346 gs 1 44 0 9692K 1452K pause 0 0:00 0.00% zsh 1791 root 1 44 0 7992K 372K nanslp 0 0:00 0.00% cron 1903 gs 1 44 0 9704K 1968K pause 2 0:00 0.00% zsh ------------------------------------------------------------------------------------------------------------------------ PID 29258 is still alive (thread is that indexing tool). Also there is a lot of free and inactive memory. And thread can't possibly ask for a big piece of memory because of the nature of this tool. Next second we see: ------------------------------------------------------------------------------------------------------------------------ Thu Feb 16 04:28:39 EET 2012 last pid: 31362; load averages: 0.04, 0.05, 0.00 up 0+15:25:12 04:28:39 60 processes: 1 running, 59 sleeping Mem: 2512M Active, 2055M Inact, 3092M Wired, 145M Cache, 96K Buf, 125M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 15920 gs 1 44 0 9400K 2028K select 3 0:33 0.10% top 1750 root 1 44 0 25024K 1772K select 0 4:24 0.00% snmpd 1967 root 1 64 0 5716K 892K zio->i 0 1:09 0.00% sh 1913 gs 1 76 0 9704K 1328K pause 0 0:41 0.00% zsh 71345 gs 1 44 0 38132K 936K select 2 0:29 0.00% sshd 1889 gs 1 44 0 9100K 620K nanslp 2 0:13 0.00% iostat 1886 gs 1 44 0 38132K 848K select 3 0:12 0.00% sshd 52290 gs 1 44 0 5844K 856K kqread 0 0:05 0.00% tail 1902 gs 1 44 0 38132K 1044K select 0 0:04 0.00% sshd 1891 satan 1 44 0 9396K 688K select 3 0:04 0.00% screen 1357 nagios 1 44 0 6908K 512K select 2 0:02 0.00% nrpe2 1153 root 1 44 0 6936K 748K select 2 0:01 0.00% syslogd 1632 root 1 44 0 5428K 432K nanslp 0 0:00 0.00% cron 1912 gs 1 44 0 38132K 792K select 1 0:00 0.00% sshd 71346 gs 1 44 0 9692K 1452K pause 0 0:00 0.00% zsh 1791 root 1 44 0 7992K 372K nanslp 0 0:00 0.00% cron 1903 gs 1 44 0 9704K 1968K pause 2 0:00 0.00% zsh 1497 root 1 44 0 5396K 708K select 0 0:00 0.00% syslogd ------------------------------------------------------------------------------------------------------------------------ It is dead although inactive and active queues of memory didn't even get touched. Please tell me, is that appropriate behaviour? And why this never happens on Linux for example (and maybe on other systems as well)? From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 10:24:59 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 634531065672 for ; Fri, 17 Feb 2012 10:24:59 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id DEAD78FC08 for ; Fri, 17 Feb 2012 10:24:58 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q1HAOnVj005030 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2012 10:24:55 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q1HAOnVj005030 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1329474295; bh=HdwSsbTuK6YG4s7sddVjweb6dbylOpk5CPHBNiW3YC8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=XAu2aQMjzJXVSe0PqIo/3C7SILq39z7kFc5HyxZePNMHdklS1QfBL5GV7rgOaRvD9 TZIV1+S3YrSV4SvqTPFrhaOyqDdnmthQH9MfgCQlMo8BSbd4+KpKYYtAZC95i6KulX qcqoeD2igNh299NxomVtEmQMVOQ2r1W2Ld5qDjlM= Message-ID: <4F3E2AEA.7080401@infracaninophile.co.uk> Date: Fri, 17 Feb 2012 10:24:42 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4F377457.4080807@FreeBSD.org> <20120212084052.GA43095@icarus.home.lan> <4F3789C1.9000903@FreeBSD.org> <4F37A8E7.7060102@brockmann-consult.de> <4F37B25A.10002@FreeBSD.org> <4F37BA49.50700@brockmann-consult.de> <4F37C52A.2030803@infracaninophile.co.uk> <4F3A30A2.9050603@FreeBSD.org> <4F3A6D44.4040105@brockmann-consult.de> <4F3A7264.8080301@infracaninophile.co.uk> In-Reply-To: <4F3A7264.8080301@infracaninophile.co.uk> X-Enigmail-Version: 1.3.5 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11061EBDB913CBF7D0F2D9EC" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS Snapshot problems 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, 17 Feb 2012 10:24:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11061EBDB913CBF7D0F2D9EC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14/02/2012 14:40, Matthew Seaman wrote: > Hmmm... no. That sounds like a thing to try when I have a day or so > that I can take the machine down for. Probably right around the point > that I do the upgrade to 9.x. Thinking about it, I'd probably split th= e > mirror, rebuild one of the drives, pull the ZFSes across, boot from the= > rebuilt drive and then add the old drive back to the mirror. Ah. I've worked out what the problem is. dedup. Turning dedup off has made everything behave normally. I only turned on dedup as an experiment in the first place, so no great loss. However, it seems that the bad effects due to dedup only appeared by chance -- the machine was running fine for months until a change in operation triggered the problem. That was what should have been a completely innocuous change from using anoncvs to mirroring /home/ncvs using csup(1) for the ports tree. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig11061EBDB913CBF7D0F2D9EC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+KvAACgkQ8Mjk52CukIyfFACfRrhwRII+DEXXfQV+alOc1XxR +P8AniIQ7cG+yaFkvGkuYSTDpRjWnp0L =1Wot -----END PGP SIGNATURE----- --------------enig11061EBDB913CBF7D0F2D9EC-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 13:49:36 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 2C6A3106566C for ; Fri, 17 Feb 2012 13:49:36 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1197B8FC0A for ; Fri, 17 Feb 2012 13:49:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RyOBo-000202-Vv for freebsd-fs@freebsd.org; Fri, 17 Feb 2012 14:49:32 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 14:49:32 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 14:49:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Fri, 17 Feb 2012 14:49:24 +0100 Lines: 32 Message-ID: References: <41082.1329320114.6955040073494560768@ffe1.ukr.net> <70229.1329318412.9319724204137054208@ffe16.ukr.net> <35197.1329379389.10113652667292975104@ffe2.ukr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8885DD13216A9B3D50387E1" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <35197.1329379389.10113652667292975104@ffe2.ukr.net> X-Enigmail-Version: 1.3.5 Subject: Re: ZFS and mem management 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, 17 Feb 2012 13:49:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8885DD13216A9B3D50387E1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16/02/2012 09:03, Pavlo wrote: > It is dead although inactive and active queues of memory didn't even ge= t > touched. Please tell me, is that appropriate behaviour? And why this > never happens on Linux for example (and maybe on other systems as well)= ? As far as I can help you, it is that I can advise you to try without ZFS.= --------------enigD8885DD13216A9B3D50387E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+WuQACgkQldnAQVacBcgzbgCgmxyMAH41KmuiYaansLEUeCez Z1UAniH22J31uwFngrfDTTuGqeZzgKh8 =CSAb -----END PGP SIGNATURE----- --------------enigD8885DD13216A9B3D50387E1-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 13:55: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 9670E106566C for ; Fri, 17 Feb 2012 13:55:02 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 401D18FC19 for ; Fri, 17 Feb 2012 13:55:02 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RyOH6-0006TU-P5 for freebsd-fs@freebsd.org; Fri, 17 Feb 2012 14:55:00 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 14:55:00 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 14:55:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Fri, 17 Feb 2012 14:54:51 +0100 Lines: 57 Message-ID: References: <15861.1329298812.1414986334451204096@ffe12.ukr.net> <92617.1329301696.6338962447434776576@ffe5.ukr.net> <96280.1329309582.18313701080496209920@ffe5.ukr.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFDB021B573E865305C9A686F" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Subject: Re: ZFS and mem management 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, 17 Feb 2012 13:55:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFDB021B573E865305C9A686F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15/02/2012 17:07, Kai Gallasch wrote: >=20 > Am 15.02.2012 um 15:02 schrieb Ivan Voras: >=20 >> On 15/02/2012 13:39, Pavlo wrote: >>> >>> >>> >>> Unfortunately we can't afford disabling prefetch. It is too much of a= n >>> overhead. >>> >>> Also I made some tests. I have process that maps file using mmap() an= d >>> writes or reads first byte of each page of mapped file with some data= =2E >> >> Note that ZFS is designed so that it interacts somewhat badly with >> mmap() and other kernel services which rely on coherency between VM an= d >> IO such as sendfile(). At the very best, you will have two in-kernel >> copies of all data buffers used with such interfaces, but there have >> been sporadic reports that there are other bugs with it. >=20 > So best practice for running apache2 on FreeBSD ZFS is making sure Enab= leMMAP and EnableSendfile are disabled in httpd.conf, right? Yes. > (both are turned off by default) No, they are enabled by default: http://httpd.apache.org/docs/2.2/mod/core.html#enablemmap --------------enigFDB021B573E865305C9A686F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+XCsACgkQldnAQVacBcjQswCgjdhwr+oUhMCpbOwlxcG0K+uc e/oAoJJnKr2KTTfqKl/AwhFlQdql3Kkz =jmua -----END PGP SIGNATURE----- --------------enigFDB021B573E865305C9A686F-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 14:16:07 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9433B1065679; Fri, 17 Feb 2012 14:16:07 +0000 (UTC) Date: Fri, 17 Feb 2012 14:16:07 +0000 From: Alexander Best To: freebsd-fs@freebsd.org Message-ID: <20120217141607.GA63659@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: freebsd-swap on ssd 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, 17 Feb 2012 14:16:07 -0000 hi there, putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs structure (unlike zfs e.g.) requires certain data to be continuously written to a fixed location and thus will cause the ssd to quickly run out of write-cycles and die. but how about using a small ssd (approx. 10GB) as one entire freebsd-swap partition? will this make more sense, or are there certain structures within the freebsd-swap partition type, which also need to be continuously written to a fixed location? another question i'd like to ask: are there also issues with read-cycles on ssds? because i was thinking about putting a freebsd-boot partition on an ssd drive and only mounting it ro. this should solve the write-cycle issue in theory. however i'm not sure, if stuff like the dirty bit or the ufs label will also remain untouched. so even though the partition will only be mounted ro, freebsd might still frequently write certain data to a fixed location on the ssd drive which hosts the freebsd-boot partition. if this is the case, is there a way of completely prohibiting any writes to a disk? will revoking any write permissions from the device entry under /dev guarantee this, or is using a any device 100% ro under freebsd impossible (unless it has a hardware switch to forbid writes)? cheers. alex From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 14:27:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A3947106567C; Fri, 17 Feb 2012 14:27:45 +0000 (UTC) Date: Fri, 17 Feb 2012 14:27:45 +0000 From: Alexander Best To: freebsd-fs@freebsd.org Message-ID: <20120217142745.GA68510@freebsd.org> References: <20120217141607.GA63659@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120217141607.GA63659@freebsd.org> Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 14:27:45 -0000 On Fri Feb 17 12, Alexander Best wrote: > hi there, > > putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs > structure (unlike zfs e.g.) requires certain data to be continuously written to > a fixed location and thus will cause the ssd to quickly run out of write-cycles > and die. > > but how about using a small ssd (approx. 10GB) as one entire freebsd-swap > partition? will this make more sense, or are there certain structures within > the freebsd-swap partition type, which also need to be continuously written to > a fixed location? > > another question i'd like to ask: are there also issues with read-cycles on > ssds? because i was thinking about putting a freebsd-boot partition on an ssd > drive and only mounting it ro. this should solve the write-cycle issue in > theory. however i'm not sure, if stuff like the dirty bit or the ufs label will > also remain untouched. so even though the partition will only be mounted ro, > freebsd might still frequently write certain data to a fixed location on the > ssd drive which hosts the freebsd-boot partition. if this is the case, is there > a way of completely prohibiting any writes to a disk? will revoking any write > permissions from the device entry under /dev guarantee this, or is using a any > device 100% ro under freebsd impossible (unless it has a hardware switch to > forbid writes)? i'm sorry, if i was unprecise here. what i meant was to have a ssd drive with a freebsd-boot partition on it (which of course cannot be mounted) and an extra freebsd-ufs partition with the contents of / on it, which is the partition i'd like to only mount ro. so again the question is: will this configuration (freebsd-boot and freebsd-ufs (ro) partition) ensure that no writes to the ssd are being performed? cheers. alex > > cheers. > alex From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 15:30: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 BD879106566B; Fri, 17 Feb 2012 15:30:10 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6D78D8FC14; Fri, 17 Feb 2012 15:30:10 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 78B9028426; Fri, 17 Feb 2012 16:10:50 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7FEB02842D; Fri, 17 Feb 2012 16:10:49 +0100 (CET) Message-ID: <4F3E6DF8.30605@quip.cz> Date: Fri, 17 Feb 2012 16:10:48 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Alexander Best References: <20120217141607.GA63659@freebsd.org> <20120217142745.GA68510@freebsd.org> In-Reply-To: <20120217142745.GA68510@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 15:30:10 -0000 Alexander Best wrote: > On Fri Feb 17 12, Alexander Best wrote: >> hi there, >> >> putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs >> structure (unlike zfs e.g.) requires certain data to be continuously written to >> a fixed location and thus will cause the ssd to quickly run out of write-cycles >> and die. >> >> but how about using a small ssd (approx. 10GB) as one entire freebsd-swap >> partition? will this make more sense, or are there certain structures within >> the freebsd-swap partition type, which also need to be continuously written to >> a fixed location? >> >> another question i'd like to ask: are there also issues with read-cycles on >> ssds? because i was thinking about putting a freebsd-boot partition on an ssd >> drive and only mounting it ro. this should solve the write-cycle issue in >> theory. however i'm not sure, if stuff like the dirty bit or the ufs label will >> also remain untouched. so even though the partition will only be mounted ro, >> freebsd might still frequently write certain data to a fixed location on the >> ssd drive which hosts the freebsd-boot partition. if this is the case, is there >> a way of completely prohibiting any writes to a disk? will revoking any write >> permissions from the device entry under /dev guarantee this, or is using a any >> device 100% ro under freebsd impossible (unless it has a hardware switch to >> forbid writes)? > > i'm sorry, if i was unprecise here. what i meant was to have a ssd drive with a > freebsd-boot partition on it (which of course cannot be mounted) and an extra > freebsd-ufs partition with the contents of / on it, which is the partition i'd > like to only mount ro. so again the question is: will this configuration > (freebsd-boot and freebsd-ufs (ro) partition) ensure that no writes to the ssd > are being performed? I am not sure, because I am not a developer, but we are using similar setup with USB flash disk drive on our backup storage. USB flashdisk contains boot and / (root partition) including /home, /usr, /usr/local directories with UFS mounted as read only. Other things (/var, /usr/ports, /usr/src) are on ZFS pool storage. I remounted USB flash disk read-write for system / packages updates only. The machine is in production for more than 3 years. First flash disk died during perl upgrade (lot's of writes) after one and half year. It was really cheap USB flash disk with bad performance from start. Then it was replaced with slightly better 2GB USB flash disk which is running fine. So I think if we are able to run it on cheap ($15) flash disk, you will be fine with SSD even if there are some writes. Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 15:35: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 A98081065673 for ; Fri, 17 Feb 2012 15:35:41 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE018FC0A for ; Fri, 17 Feb 2012 15:35:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RyPqS-0004Jx-Ab for freebsd-fs@freebsd.org; Fri, 17 Feb 2012 16:35:36 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 16:35:36 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Feb 2012 16:35:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Fri, 17 Feb 2012 16:35:24 +0100 Lines: 73 Message-ID: References: <20120217141607.GA63659@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9E77AA4BA40123E93C37DD88" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <20120217141607.GA63659@freebsd.org> X-Enigmail-Version: 1.3.5 Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 15:35:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9E77AA4BA40123E93C37DD88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17/02/2012 15:16, Alexander Best wrote: > hi there, >=20 > putting a freebsd-ufs partition on an ssd isn't recommended, since the = ufs > structure (unlike zfs e.g.) requires certain data to be continuously wr= itten to > a fixed location and thus will cause the ssd to quickly run out of writ= e-cycles > and die. This is outdated information as all current SSD drives will perform internal write-leveling (data relocation) in attempt to get around this. UFS also has one other benefit: it currently supports the "TRIM" operation (via BIO_DELETE) while ZFS doesn't. > but how about using a small ssd (approx. 10GB) as one entire freebsd-sw= ap > partition? will this make more sense, or are there certain structures w= ithin > the freebsd-swap partition type, which also need to be continuously wri= tten to > a fixed location? This all depends on how much swap and how often do you use it. I'd say it's a great idea if you run into out-of-memory situations rarely and then if you do run into it, you want the least performance degradation. In *all other cases* you will probably fry the SSD quickly. > another question i'd like to ask: are there also issues with read-cycle= s on > ssds? Not that I've heard of. > because i was thinking about putting a freebsd-boot partition on an ssd= > drive and only mounting it ro. this should solve the write-cycle issue = in > theory. however i'm not sure, if stuff like the dirty bit or the ufs la= bel will > also remain untouched. so even though the partition will only be mounte= d ro, > freebsd might still frequently write certain data to a fixed location o= n the > ssd drive which hosts the freebsd-boot partition.=20 It shouldn't - if the file system is mounted read-only then the underlying device will not be updated. --------------enig9E77AA4BA40123E93C37DD88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8+c7wACgkQldnAQVacBcgAJgCg7w+pn8dAvmjg194jhb84cdeJ TzEAoNcGOmvffoWdUQMlNym11GJiIIvW =KDLy -----END PGP SIGNATURE----- --------------enig9E77AA4BA40123E93C37DD88-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 18:17: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 A6A571065703; Fri, 17 Feb 2012 18:17:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 778C88FC16; Fri, 17 Feb 2012 18:17:29 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1HIHRrn027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 10:17:28 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3E9A14.3070605@freebsd.org> Date: Fri, 17 Feb 2012 10:19:00 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Alexander Best References: <20120217141607.GA63659@freebsd.org> In-Reply-To: <20120217141607.GA63659@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 18:17:29 -0000 On 2/17/12 6:16 AM, Alexander Best wrote: > hi there, > > putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs > structure (unlike zfs e.g.) requires certain data to be continuously written to > a fixed location and thus will cause the ssd to quickly run out of write-cycles > and die. nonsense. the SSD doesn't use the same flash for the same logical locatio each time! it maps it to different locations each time. > but how about using a small ssd (approx. 10GB) as one entire freebsd-swap > partition? will this make more sense, or are there certain structures within > the freebsd-swap partition type, which also need to be continuously written to > a fixed location? small SSDs may have less wear resistance than big ones.. the cheap ones may not even use proper mapping.. > another question i'd like to ask: are there also issues with read-cycles on > ssds? because i was thinking about putting a freebsd-boot partition on an ssd > drive and only mounting it ro. this should solve the write-cycle issue in > theory. however i'm not sure, if stuff like the dirty bit or the ufs label will > also remain untouched. so even though the partition will only be mounted ro, > freebsd might still frequently write certain data to a fixed location on the > ssd drive which hosts the freebsd-boot partition. if this is the case, is there > a way of completely prohibiting any writes to a disk? will revoking any write > permissions from the device entry under /dev guarantee this, or is using a any > device 100% ro under freebsd impossible (unless it has a hardware switch to > forbid writes)? yes there are small issues with read cycles but it is all hidden from you by the drive. > cheers. > alex > _______________________________________________ > 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 Fri Feb 17 19:09:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BF2171065670; Fri, 17 Feb 2012 19:09:21 +0000 (UTC) Date: Fri, 17 Feb 2012 19:09:21 +0000 From: Alexander Best To: Julian Elischer Message-ID: <20120217190921.GA26568@freebsd.org> References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3E9A14.3070605@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 19:09:21 -0000 On Fri Feb 17 12, Julian Elischer wrote: > On 2/17/12 6:16 AM, Alexander Best wrote: > >hi there, > > > >putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs > >structure (unlike zfs e.g.) requires certain data to be continuously > >written to > >a fixed location and thus will cause the ssd to quickly run out of > >write-cycles > >and die. > nonsense. > the SSD doesn't use the same flash for the same logical locatio each time! > it maps it to different locations each time. i simply repeated what kirk mckusick said in the SU+J introduction video. he said for exactly this reason ufs should not be used on an ssd, since stuff like inode entries live in a fixed location, whereas with zfs the ueberblock can live in 128 locations. also in case of SU+J, where the journal only takes up a very small part of the disk due to the fact that it's only tracking metadata changes and isn't doing logging (like gjournal), there's also the chance to run out of write-cycles. see: http://youtu.be/_NuhRkiInvA cheers. alex > > >but how about using a small ssd (approx. 10GB) as one entire freebsd-swap > >partition? will this make more sense, or are there certain structures > >within > >the freebsd-swap partition type, which also need to be continuously > >written to > >a fixed location? > small SSDs may have less wear resistance than big ones.. the cheap > ones may not even > use proper mapping.. > >another question i'd like to ask: are there also issues with read-cycles on > >ssds? because i was thinking about putting a freebsd-boot partition on an > >ssd > >drive and only mounting it ro. this should solve the write-cycle issue in > >theory. however i'm not sure, if stuff like the dirty bit or the ufs label > >will > >also remain untouched. so even though the partition will only be mounted > >ro, > >freebsd might still frequently write certain data to a fixed location on > >the > >ssd drive which hosts the freebsd-boot partition. if this is the case, is > >there > >a way of completely prohibiting any writes to a disk? will revoking any > >write > >permissions from the device entry under /dev guarantee this, or is using a > >any > >device 100% ro under freebsd impossible (unless it has a hardware switch to > >forbid writes)? > > yes there are small issues with read cycles but it is all hidden from > you by the drive. > >cheers. > >alex > >_______________________________________________ > >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 Fri Feb 17 19:14: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 B87361065672; Fri, 17 Feb 2012 19:14:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 887058FC0C; Fri, 17 Feb 2012 19:14:10 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1HJE8SZ027481 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 11:14:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3EA75C.6070407@freebsd.org> Date: Fri, 17 Feb 2012 11:15:40 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Alexander Best References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> In-Reply-To: <20120217190921.GA26568@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 19:14:10 -0000 On 2/17/12 11:09 AM, Alexander Best wrote: > On Fri Feb 17 12, Julian Elischer wrote: >> On 2/17/12 6:16 AM, Alexander Best wrote: >>> hi there, >>> >>> putting a freebsd-ufs partition on an ssd isn't recommended, since the ufs >>> structure (unlike zfs e.g.) requires certain data to be continuously >>> written to >>> a fixed location and thus will cause the ssd to quickly run out of >>> write-cycles >>> and die. >> nonsense. >> the SSD doesn't use the same flash for the same logical locatio each time! >> it maps it to different locations each time. > i simply repeated what kirk mckusick said in the SU+J introduction video. he > said for exactly this reason ufs should not be used on an ssd, since stuff like > inode entries live in a fixed location, whereas with zfs the ueberblock can > live in 128 locations. also in case of SU+J, where the journal only takes up a > very small part of the disk due to the fact that it's only tracking metadata > changes and isn't doing logging (like gjournal), there's also the chance to run > out of write-cycles. I think he meant ON A RAW FLASH DEVICE SSD's have all that taken care of transparently. There are special file systems for raw flash devices that take all that into account, and ffs is not one of them. From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 19:30:31 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E2A961065677; Fri, 17 Feb 2012 19:30:31 +0000 (UTC) Date: Fri, 17 Feb 2012 19:30:31 +0000 From: Alexander Best To: Julian Elischer Message-ID: <20120217193031.GA34283@freebsd.org> References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> <4F3EA75C.6070407@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3EA75C.6070407@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 19:30:32 -0000 On Fri Feb 17 12, Julian Elischer wrote: > On 2/17/12 11:09 AM, Alexander Best wrote: > >On Fri Feb 17 12, Julian Elischer wrote: > >>On 2/17/12 6:16 AM, Alexander Best wrote: > >>>hi there, > >>> > >>>putting a freebsd-ufs partition on an ssd isn't recommended, since the > >>>ufs > >>>structure (unlike zfs e.g.) requires certain data to be continuously > >>>written to > >>>a fixed location and thus will cause the ssd to quickly run out of > >>>write-cycles > >>>and die. > >>nonsense. > >>the SSD doesn't use the same flash for the same logical locatio each time! > >>it maps it to different locations each time. > >i simply repeated what kirk mckusick said in the SU+J introduction video. > >he > >said for exactly this reason ufs should not be used on an ssd, since stuff > >like > >inode entries live in a fixed location, whereas with zfs the ueberblock can > >live in 128 locations. also in case of SU+J, where the journal only takes > >up a > >very small part of the disk due to the fact that it's only tracking > >metadata > >changes and isn't doing logging (like gjournal), there's also the chance > >to run > >out of write-cycles. > I think he meant ON A RAW FLASH DEVICE > SSD's have all that taken care of transparently. ahh is see. i wasn't aware of that. so in theory doing while true; do dd if=/dev/zero bs=4096 of=/dev/ssd count=1; done will not overwrite the first sector continuously, but the ssd controller will make sure the writes are being sprinkled all over the actual ssd? cheers. alex > > There are special file systems for raw flash devices that take all > that into account, > and ffs is not one of them. > From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 19:41: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 5B99910656B9; Fri, 17 Feb 2012 19:41:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9898FC13; Fri, 17 Feb 2012 19:41:54 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1HJfqYD027586 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 11:41:53 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3EADDD.2010500@freebsd.org> Date: Fri, 17 Feb 2012 11:43:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Alexander Best References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> <4F3EA75C.6070407@freebsd.org> <20120217193031.GA34283@freebsd.org> In-Reply-To: <20120217193031.GA34283@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 19:41:55 -0000 > On Fri Feb 17 12, Julian Elischer wrote: >> On 2/17/12 11:09 AM, Alexander Best wrote: >>> On Fri Feb 17 12, Julian Elischer wrote: >>>> On 2/17/12 6:16 AM, Alexander Best wrote: >>>>> hi there, >>>>> >>>>> putting a freebsd-ufs partition on an ssd isn't recommended, since the >>>>> ufs >>>>> structure (unlike zfs e.g.) requires certain data to be continuously >>>>> written to >>>>> a fixed location and thus will cause the ssd to quickly run out of >>>>> write-cycles >>>>> and die. >>>> nonsense. >>>> the SSD doesn't use the same flash for the same logical locatio each time! >>>> it maps it to different locations each time. >>> i simply repeated what kirk mckusick said in the SU+J introduction video. >>> he >>> said for exactly this reason ufs should not be used on an ssd, since stuff >>> like >>> inode entries live in a fixed location, whereas with zfs the ueberblock can >>> live in 128 locations. also in case of SU+J, where the journal only takes >>> up a >>> very small part of the disk due to the fact that it's only tracking >>> metadata >>> changes and isn't doing logging (like gjournal), there's also the chance >>> to run >>> out of write-cycles. >> I think he meant ON A RAW FLASH DEVICE >> SSD's have all that taken care of transparently. > ahh is see. i wasn't aware of that. so in theory doing > > while true; do dd if=/dev/zero bs=4096 of=/dev/ssd count=1; done > > will not overwrite the first sector continuously, but the ssd controller will > make sure the writes are being sprinkled all over the actual ssd? yes. that's the differnce between an SSD and a lump of flash soldered onto a motherboard > cheers. > alex > >> There are special file systems for raw flash devices that take all >> that into account, >> and ffs is not one of them. >> From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 19:43:49 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 3626E1065687; Fri, 17 Feb 2012 19:43:49 +0000 (UTC) Date: Fri, 17 Feb 2012 19:43:49 +0000 From: Alexander Best To: Julian Elischer Message-ID: <20120217194349.GA36250@freebsd.org> References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> <4F3EA75C.6070407@freebsd.org> <20120217193031.GA34283@freebsd.org> <4F3EADDD.2010500@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3EADDD.2010500@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 19:43:49 -0000 On Fri Feb 17 12, Julian Elischer wrote: > >On Fri Feb 17 12, Julian Elischer wrote: > >>On 2/17/12 11:09 AM, Alexander Best wrote: > >>>On Fri Feb 17 12, Julian Elischer wrote: > >>>>On 2/17/12 6:16 AM, Alexander Best wrote: > >>>>>hi there, > >>>>> > >>>>>putting a freebsd-ufs partition on an ssd isn't recommended, since the > >>>>>ufs > >>>>>structure (unlike zfs e.g.) requires certain data to be continuously > >>>>>written to > >>>>>a fixed location and thus will cause the ssd to quickly run out of > >>>>>write-cycles > >>>>>and die. > >>>>nonsense. > >>>>the SSD doesn't use the same flash for the same logical locatio each > >>>>time! > >>>>it maps it to different locations each time. > >>>i simply repeated what kirk mckusick said in the SU+J introduction video. > >>>he > >>>said for exactly this reason ufs should not be used on an ssd, since > >>>stuff > >>>like > >>>inode entries live in a fixed location, whereas with zfs the ueberblock > >>>can > >>>live in 128 locations. also in case of SU+J, where the journal only takes > >>>up a > >>>very small part of the disk due to the fact that it's only tracking > >>>metadata > >>>changes and isn't doing logging (like gjournal), there's also the chance > >>>to run > >>>out of write-cycles. > >>I think he meant ON A RAW FLASH DEVICE > >>SSD's have all that taken care of transparently. > >ahh is see. i wasn't aware of that. so in theory doing > > > >while true; do dd if=/dev/zero bs=4096 of=/dev/ssd count=1; done > > > >will not overwrite the first sector continuously, but the ssd controller > >will > >make sure the writes are being sprinkled all over the actual ssd? > > yes. that's the differnce between an SSD and a lump of flash soldered > onto a motherboard thanks for the info. it seems all my ufs on ssd related concerns were unnecessary then. cheers. alex > >cheers. > >alex > > > >>There are special file systems for raw flash devices that take all > >>that into account, > >>and ffs is not one of them. > >> From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 20:19:36 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 02D561065675; Fri, 17 Feb 2012 20:19:36 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 582018FC12; Fri, 17 Feb 2012 20:19:34 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so3073647wgb.31 for ; Fri, 17 Feb 2012 12:19:34 -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=gtrjwtZmULZ/eVVzbC/IIznucrici/dD1Jl03nNEmJc=; b=idEIn3ag8FLZpgPU35KjNMpFgOlDexETm6IV4wukDP2j2Utq5IkKUWUPOKwF/IkKtS plB6UFG7v7UD1yFpMAr8PjfZOwHoRZRAp0eS9SiVCrIFFIZbacRbuYlZAtoDQNv32blW fVM5KKyaJP1Y/xLPpNCNdnveoLqczxsBYuBXE= MIME-Version: 1.0 Received: by 10.216.134.157 with SMTP id s29mr3894267wei.1.1329508649004; Fri, 17 Feb 2012 11:57:29 -0800 (PST) Received: by 10.223.62.70 with HTTP; Fri, 17 Feb 2012 11:57:28 -0800 (PST) In-Reply-To: <20120217193031.GA34283@freebsd.org> References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> <4F3EA75C.6070407@freebsd.org> <20120217193031.GA34283@freebsd.org> Date: Fri, 17 Feb 2012 13:57:28 -0600 Message-ID: From: Adam Vande More To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: freebsd-swap on ssd 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, 17 Feb 2012 20:19:36 -0000 On Fri, Feb 17, 2012 at 1:30 PM, Alexander Best wrote: > ahh is see. i wasn't aware of that. so in theory doing > > while true; do dd if=/dev/zero bs=4096 of=/dev/ssd count=1; done > > will not overwrite the first sector continuously, but the ssd controller > will > make sure the writes are being sprinkled all over the actual ssd? > Sounds like you are seeking info on this process: http://en.wikipedia.org/wiki/Wear_leveling -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Fri Feb 17 20:20:21 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 07AF21065679; Fri, 17 Feb 2012 20:20:21 +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 B28A98FC1C; Fri, 17 Feb 2012 20:20:20 +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 q1HKKK5E021162; Fri, 17 Feb 2012 20:20:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1HKKKml021158; Fri, 17 Feb 2012 20:20:20 GMT (envelope-from linimon) Date: Fri, 17 Feb 2012 20:20:20 GMT Message-Id: <201202172020.q1HKKKml021158@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165087: [unionfs] lock violation in unionfs 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, 17 Feb 2012 20:20:21 -0000 Old Synopsis: lock violation in unionfs New Synopsis: [unionfs] lock violation in unionfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 17 20:19:43 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165087 From owner-freebsd-fs@FreeBSD.ORG Sat Feb 18 11:34:00 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 70782106564A for ; Sat, 18 Feb 2012 11:34:00 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id EB0688FC0C for ; Sat, 18 Feb 2012 11:33:59 +0000 (UTC) Received: from [213.108.104.138] (helo=smtp.greenhost.nl) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RyiJP-00040i-Nf for freebsd-fs@freebsd.org; Sat, 18 Feb 2012 12:18:44 +0100 Received: from dhcp-077-251-052-224.chello.nl ([77.251.52.224] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RyiJQ-00056R-40 for freebsd-fs@freebsd.org; Sat, 18 Feb 2012 12:18:44 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <20120217141607.GA63659@freebsd.org> <4F3E9A14.3070605@freebsd.org> <20120217190921.GA26568@freebsd.org> Date: Sat, 18 Feb 2012 12:18:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20120217190921.GA26568@freebsd.org> User-Agent: Opera Mail/11.61 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.1 X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50, RDNS_NONE autolearn=disabled version=3.2.5 X-Scan-Signature: aadb025e1561638fa3cfee7b14734d3b Subject: Re: freebsd-swap on ssd 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, 18 Feb 2012 11:34:00 -0000 On Fri, 17 Feb 2012 20:09:21 +0100, Alexander Best wrote: > On Fri Feb 17 12, Julian Elischer wrote: >> On 2/17/12 6:16 AM, Alexander Best wrote: >> >hi there, >> > >> >putting a freebsd-ufs partition on an ssd isn't recommended, since the >> ufs >> >structure (unlike zfs e.g.) requires certain data to be continuously >> >written to >> >a fixed location and thus will cause the ssd to quickly run out of >> >write-cycles >> >and die. >> nonsense. >> the SSD doesn't use the same flash for the same logical locatio each >> time! >> it maps it to different locations each time. > > i simply repeated what kirk mckusick said in the SU+J introduction > video. he > said for exactly this reason ufs should not be used on an ssd, since > stuff like > inode entries live in a fixed location, whereas with zfs the ueberblock > can > live in 128 locations. also in case of SU+J, where the journal only > takes up a > very small part of the disk due to the fact that it's only tracking > metadata > changes and isn't doing logging (like gjournal), there's also the chance > to run > out of write-cycles. A related question. Does journaling make sense on a ssd? I don't think there is a write cache on the ssd. Ronald. > > see: http://youtu.be/_NuhRkiInvA > > cheers. > alex > >> >> >but how about using a small ssd (approx. 10GB) as one entire >> freebsd-swap >> >partition? will this make more sense, or are there certain structures >> >within >> >the freebsd-swap partition type, which also need to be continuously >> >written to >> >a fixed location? >> small SSDs may have less wear resistance than big ones.. the cheap >> ones may not even >> use proper mapping.. >> >another question i'd like to ask: are there also issues with >> read-cycles on >> >ssds? because i was thinking about putting a freebsd-boot partition on >> an >> >ssd >> >drive and only mounting it ro. this should solve the write-cycle issue >> in >> >theory. however i'm not sure, if stuff like the dirty bit or the ufs >> label >> >will >> >also remain untouched. so even though the partition will only be >> mounted >> >ro, >> >freebsd might still frequently write certain data to a fixed location >> on >> >the >> >ssd drive which hosts the freebsd-boot partition. if this is the case, >> is >> >there >> >a way of completely prohibiting any writes to a disk? will revoking any >> >write >> >permissions from the device entry under /dev guarantee this, or is >> using a >> >any >> >device 100% ro under freebsd impossible (unless it has a hardware >> switch to >> >forbid writes)? >> >> yes there are small issues with read cycles but it is all hidden from >> you by the drive. >> >cheers. >> >alex >> >_______________________________________________ >> >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" From owner-freebsd-fs@FreeBSD.ORG Sat Feb 18 15:48: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 1A4D8106564A for ; Sat, 18 Feb 2012 15:48:24 +0000 (UTC) (envelope-from shuey@fmepnet.org) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C40A88FC08 for ; Sat, 18 Feb 2012 15:48:23 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4170808vcm.13 for ; Sat, 18 Feb 2012 07:48:23 -0800 (PST) Received-SPF: pass (google.com: domain of shuey@fmepnet.org designates 10.52.88.235 as permitted sender) client-ip=10.52.88.235; Authentication-Results: mr.google.com; spf=pass (google.com: domain of shuey@fmepnet.org designates 10.52.88.235 as permitted sender) smtp.mail=shuey@fmepnet.org Received: from mr.google.com ([10.52.88.235]) by 10.52.88.235 with SMTP id bj11mr6473722vdb.119.1329580103207 (num_hops = 1); Sat, 18 Feb 2012 07:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.88.235 with SMTP id bj11mr5186686vdb.119.1329578716693; Sat, 18 Feb 2012 07:25:16 -0800 (PST) Received: by 10.220.64.141 with HTTP; Sat, 18 Feb 2012 07:25:16 -0800 (PST) X-Originating-IP: [98.223.59.225] Date: Sat, 18 Feb 2012 10:25:16 -0500 Message-ID: From: Michael Shuey To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkSGKb5aL3H15tHyD4qEkxs5m24D6ednPuWbHwNfjsFg0EZdwOrb6UNV0kBNX4VSM8MpkgO Subject: ZFS size reduced, 100% full, on fbsd9 upgrade 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, 18 Feb 2012 15:48:24 -0000 I'm upgrading a server from 8.2p6 to 9.0-RELEASE, and I've tried both make in the source tree and freebsd-update and I get the same strange result. As soon as I boot to the fbsd9 kernel, even booting into single-user mode, the pool's size is greatly reduced. All filesystems show 100% full (0 bytes free space), nothing can be written to the pool (probably a side-effect of being 100% full), and dmesg shows several of "Solaris: WARNING: metaslab_free_dva(): bad DVA 0:5978620460544" warnings (with different numbers). Switching kernels back to the 8.2p6 kernel restores things to normal, but I'd really like to finish my fbsd9 upgrade. The system is a 64-bit Intel box with 4 GB of memory, and 8 disks in a raidz2 pool called "pool". It's booted to the 8.2p6 kernel now, and scrubbing the pool, but last time I did this (roughly a week ago) it was fine. / is a gmirror, but /usr, /tmp, and /var all come from the pool. Normally, the pool has 1.2 TB of free space, and is version 15 (zfs version 4). Some disks are WD drives, with 4k native sectors, but some time ago I rebuilt the pool to use a native 4k sector size (ashift=12). Over time, I've been slowly replacing disks (1 at a time) to increase the free space in the pool. Also, the system experienced severe failure recently; the power supply blew, and took out the memory (and presumably motherboard). I replaced these last week with known-good board/memory/processor/PS, and it's been running fine since. Any suggestions? Is it possible I've got some nasty pool corruption going on - and if so, how do I go about fixing it? Any advice would be appreciated. This is a backup server, so I could rebuild its contents from the primary, but I'd rather fix it if possible (since I want to do a fbsd9 upgrade on the primary next). From owner-freebsd-fs@FreeBSD.ORG Sat Feb 18 17:55: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 B9FA91065674; Sat, 18 Feb 2012 17:55:55 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0F38FC0C; Sat, 18 Feb 2012 17:55:54 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1IHtR0x055181 ; Sat, 18 Feb 2012 18:55:40 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1IHtI5t037430; Sat, 18 Feb 2012 18:55:18 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1IHtHdr037427; Sat, 18 Feb 2012 18:55:17 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Sat, 18 Feb 2012 18:55:17 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3FE60F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3FE60F.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 18 Feb 2012 17:55:55 -0000 Hello, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? > > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? > > 3) Can you try zfs without geli? yeah, and it seems to rule out geli : [ splitted original /dev/ada0s3 in equally sized /dev/ada0s3 and /dev/ada0s4 ] geli init /dev/ada0s3 geli attach /dev/ada0s3 zpool create zgeli /dev/ada0s3.eli zfs create zgeli/home zfs create zgeli/home/arno zfs create zgeli/home/arno/.priv zfs create zgeli/home/arno/.scito zfs set copies=2 zgeli/home/arno/.priv zfs set atime=off zgeli [put some files on it, wait a little : ] [root@cc ~]# zpool status -v pool: zgeli state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub in progress since Sat Feb 18 17:46:54 2012 425M scanned out of 2.49G at 85.0M/s, 0h0m to go 0 repaired, 16.64% done config: NAME STATE READ WRITE CKSUM zgeli ONLINE 0 0 1 ada0s3.eli ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /zgeli/home/arno/8.0-CURRENT-200902-amd64-livefs.iso [root@cc ~]# zpool scrub -s zgeli [root@cc ~]# [then idem directly on next partition ] zpool create zgpart /dev/ada0s4 zfs create zgpart/home zfs create zgpart/home/arno zfs create zgpart/home/arno/.priv zfs create zgpart/home/arno/.scito zfs set copies=2 zgpart/home/arno/.priv zfs set atime=off zgpart [put some files on it, wait a little : ] pool: zgpart state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 0h0m with 1 errors on Sat Feb 18 18:04:45 2012 config: NAME STATE READ WRITE CKSUM zgpart ONLINE 0 0 1 ada0s4 ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /zgpart/home/arno/.scito/ .... [root@cc ~]# I still do not particuliarly suspect the disk since I cannot reproduce similar behaviour on UFS. That said, this disk is supposed to be 'hybrid-SSD', maybe something special ZFS doesn't like ??? : ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 5YX0J5YD ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: new disk ada0 Please let me know what information to provide more. Best, Arno > 4) Is the slice/partition layout definitely correct? > > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > From owner-freebsd-fs@FreeBSD.ORG Sat Feb 18 20:06: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 EFA22106566C for ; Sat, 18 Feb 2012 20:06:09 +0000 (UTC) (envelope-from dg17@penx.com) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) by mx1.freebsd.org (Postfix) with ESMTP id A36DF8FC12 for ; Sat, 18 Feb 2012 20:06:09 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by btw.pki2.com (8.14.5/8.14.5) with ESMTP id q1IK63PK001758; Sat, 18 Feb 2012 12:06:04 -0800 (PST) (envelope-from dg17@penx.com) From: Dennis Glatting To: Michael Shuey In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Feb 2012 12:06:03 -0800 Message-ID: <1329595563.42839.28.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: q1IK63PK001758 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: dg17@penx.com Cc: freebsd-fs@freebsd.org Subject: Re: ZFS size reduced, 100% full, on fbsd9 upgrade X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dg17@penx.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:06:10 -0000 I'm not a ZFS wiz but... On Sat, 2012-02-18 at 10:25 -0500, Michael Shuey wrote: > I'm upgrading a server from 8.2p6 to 9.0-RELEASE, and I've tried both > make in the source tree and freebsd-update and I get the same strange > result. As soon as I boot to the fbsd9 kernel, even booting into > single-user mode, the pool's size is greatly reduced. All filesystems > show 100% full (0 bytes free space), nothing can be written to the > pool (probably a side-effect of being 100% full), and dmesg shows > several of "Solaris: WARNING: metaslab_free_dva(): bad DVA > 0:5978620460544" warnings (with different numbers). Switching kernels > back to the 8.2p6 kernel restores things to normal, but I'd really > like to finish my fbsd9 upgrade. > > The system is a 64-bit Intel box with 4 GB of memory, and 8 disks in a > raidz2 pool called "pool". It's booted to the 8.2p6 kernel now, and > scrubbing the pool, but last time I did this (roughly a week ago) it > was fine. / is a gmirror, but /usr, /tmp, and /var all come from the > pool. Normally, the pool has 1.2 TB of free space, and is version 15 > (zfs version 4). Some disks are WD drives, with 4k native sectors, > but some time ago I rebuilt the pool to use a native 4k sector size > (ashift=12). > I believe 4GB of memory is the minimum. More is better. When you use the minimum of anything, expect dodginess. You should upgrade your pool -- bug fixes and all that. Are all the disks 4k sectors? I found that a mix of 512 and 4k work but performance is best when they are all the same. I have also found 512 emulation isn't a believable choice when looking at performance (i.e., set for 4k). Different people have different opinions but I personally do not use ZFS for the OS, rather I RAID1 the OS. The question you have to ask is if /usr goes kablewie whether you have he skills to put it back together. I do not, so "simple" (i.e., hardware RAID1) for the OS is good for me -- it isn't the OS that's being worked in my setups, rather the data areas. > Over time, I've been slowly replacing disks (1 at a time) to increase > the free space in the pool. Also, the system experienced severe > failure recently; the power supply blew, and took out the memory (and > presumably motherboard). I replaced these last week with known-good > board/memory/processor/PS, and it's been running fine since. > Expect mixed results with mixed disks, at least from my experience, particularly when it comes to performance. Is the MB the same? I have had mixed results. I find the Gigabyte boards work well but ASUS dodgy when it comes to high interrupt handling. Server boards with ECC memory are the most reliable. > Any suggestions? Is it possible I've got some nasty pool corruption > going on - and if so, how do I go about fixing it? Any advice would > be appreciated. This is a backup server, so I could rebuild its > contents from the primary, but I'd rather fix it if possible (since I > want to do a fbsd9 upgrade on the primary next). I screw around with my set ups. What I found is rebuilding the pool (when I screw it up) is the least troublesome approach. Recently I found a tray bad on one of my servers. Drove me nuts for two weeks. It could be a loose cable, or bad cable, or crimped cable, but I am not yet in the position to open the case. Most of my ZFS weirdnesses have been hardware related. It could be your blowout impacted your disks or wiring. Do you SMART? I found, generally, SMART is goodness but I presently have a question mark when it comes to the Hitachi 4TB disks (I misbehaved on that system so then issue could be my own; however on another system there wasn't any errors). I have found, when I have multiple, identical controllers, that the same firmware across the controllers is a good approach, otherwise weirdness and different MBs manifest this problem in different ways. Also, make sure your MB's BIOS is recent. YMMV