From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 03:24:22 2011 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 9878F106564A for ; Sun, 30 Jan 2011 03:24:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 55BCC8FC08 for ; Sun, 30 Jan 2011 03:24:22 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0U3OJEN053899 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 29 Jan 2011 22:24:20 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D44D9D5.1020400@sentex.net> Date: Sat, 29 Jan 2011 22:24:05 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4D43475D.5050008@sentex.net> <4D44D775.50507@jrv.org> In-Reply-To: <4D44D775.50507@jrv.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS help! 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, 30 Jan 2011 03:24:22 -0000 On 1/29/2011 10:13 PM, James R. Van Artsdalen wrote: > On 1/28/2011 4:46 PM, Mike Tancsa wrote: >> >> I had just added another set of disks to my zfs array. It looks like the >> drive cage with the new drives is faulty. I had added a couple of files >> to the main pool, but not much. Is there any way to restore the pool >> below ? I have a lot of files on ad0,1,4,6 and ada4,5,6,7 and perhaps >> one file on the new drives in the bad cage. > > Get another enclosure and verify it works OK. Then move the disks from > the suspect enclosure to the tested enclosure and try to import the pool. Hi, Thats the plan on Monday. Post reboot, I can access the disks directly, but all 3 disks show 0(offsite)# zdb -l /dev/ada3 -------------------------------------------- LABEL 0 -------------------------------------------- failed to unpack label 0 -------------------------------------------- LABEL 1 -------------------------------------------- failed to unpack label 1 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 0(offsite)# > > The problem may be cabling or the controller instead - you didn't > specify how the disks were attached or which version of FreeBSD you're > using. RELENG_8, AMD64 8G of RAM. Is there any way to pull zpool history from an unmounted pool ? ---Mike From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 03:30:12 2011 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 9E47F1065670 for ; Sun, 30 Jan 2011 03:30:11 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from zimbra.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0288FC12 for ; Sun, 30 Jan 2011 03:30:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.jrv.org (Postfix) with ESMTP id 62DB116A09F; Sat, 29 Jan 2011 21:14:06 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from zimbra.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbta0raXSt55; Sat, 29 Jan 2011 21:14:05 -0600 (CST) Received: from [10.0.2.15] (adsl-99-66-60-250.dsl.aus2tx.sbcglobal.net [99.66.60.250]) by zimbra.jrv.org (Postfix) with ESMTPSA id 0642316A04F; Sat, 29 Jan 2011 21:14:04 -0600 (CST) Message-ID: <4D44D775.50507@jrv.org> Date: Sat, 29 Jan 2011 21:13:57 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D43475D.5050008@sentex.net> In-Reply-To: <4D43475D.5050008@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS help! 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, 30 Jan 2011 03:30:12 -0000 On 1/28/2011 4:46 PM, Mike Tancsa wrote: > > I had just added another set of disks to my zfs array. It looks like the > drive cage with the new drives is faulty. I had added a couple of files > to the main pool, but not much. Is there any way to restore the pool > below ? I have a lot of files on ad0,1,4,6 and ada4,5,6,7 and perhaps > one file on the new drives in the bad cage. Get another enclosure and verify it works OK. Then move the disks from the suspect enclosure to the tested enclosure and try to import the pool. The problem may be cabling or the controller instead - you didn't specify how the disks were attached or which version of FreeBSD you're using. From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 03:47:09 2011 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 DF09E106564A for ; Sun, 30 Jan 2011 03:47:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 471288FC0C for ; Sun, 30 Jan 2011 03:47:08 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0U3l25B030478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 14:47:04 +1100 Date: Sun, 30 Jan 2011 14:47:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <10004544.1071580.1296332968025.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20110130131048.Q988@besplex.bde.org> References: <10004544.1071580.1296332968025.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD FS Subject: Re: runtime nfs mount options for existing mounts 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, 30 Jan 2011 03:47:09 -0000 On Sat, 29 Jan 2011, Rick Macklem wrote: >>> I can say that, if someone else came up with the syscall/VFS >>> changes, I >>> could easily implement a function in the NFS client that generates >>> the >>> name/value pairs like nmount() uses. (There is currently a function >>> that >>> basically does that for the old mount() and I think a slightly >>> modified >>> version of that would do it. However, I haven't actually tried >>> it.:-) >> >> Old mount(2) doesn't do this. All mount(8) just use statfs(2). >> statfs() >> just returns the old mount flags and a couple of other broken things >> (async and sync i/o counts) that are used mainly by mount -v. >> > All I was trying to say here was that the NFS client(s) already > have a function that turns the flags, etc in the old mount args > into the name/value pairs used by nmount() so that the old > mount() still works. If it the clients did that, then their parsing would be perfectly horrible, but they do less than that -- essentially the opposite. If they actually did that, then for old mount(2) they would start with the args in convenient binary form (packed into struct nfs_args); they would unpack this into 100 or so string options to match the inconvenient nmount(2) form. The options would then arrive back in string form, as if from nmount(2), and have to be reparsed back into binary form and packed into a convenient struct, which might be named nfs_args but would now be kernel-only and need not be restricted by the mount(2) ABI, so it could hold the binary form of string options not supported by old ABI(s). What the clients actually do is just pass struct nfs_args as a binary blob attached to the string option "nfs_args". (IIRC, mount_nfs(8) used the same method until relatively recently when it was converted to use the full awe fullness of nmount(). The simpler userland parsing required by nmount() results in the current mount_nfs sources being only 50% larger than in FreeBSD-5 (well, they still have all the old parsing code, and code for new options, so as to support fallback to mount(2)).) Since struct nfs_args is still compatible with the old mount(2) ABI, it cannot hold some of the newer options like "negnametimeo". The binary value of at least this newer option is held in a global variable. So anything reporting the args back to userland would now have to gather unstructured globals and and combine these with variables in the nfs_args struct. The conversion actually done by the nfs clients is essentially the opposite: nmount() passes them options in inconvenient string form, or possibly as a convenient already-parsed binary blob. The binary blob is copied to the nfs_args struct, which is checked for errors later. String options are converted into binary form in the nfs_args struct, except in cases like "negnametimeo" where they don't fit. The options parsing is of low quality. > I believe that this function could return > the mount options (set as flag bits in the nfs variant of the > kernel mount structure, etc) as nmount() style name/value pairs > if there was a way to get them to userland. (It could be done as > yet another flag for nfssvc() if no other file system needs this > capability.) Well, the options could always have been returned in convenient binary form in the nfs_args struct, except now they don't all fit, and there were always ABI considerations which make the binary format not so good in some cases (say a 32-bit app on a 64-bit kernel wanting to know the nfs options). name=value takes more conversions which are not done even now: - Case 1: old mount(8) utility supplied a binary blob. The kernel just copied it to the kernel nfs_args struct and doesn't have many string options for it - Case 2: nmount(2) supplied string options. The kernel now has some options in string form, but only ones that weren't defaulted. Examples of low-quality options parsing: - from 4.4BSD-Lite mount_nfs.c. Hmm, this is not to bad -- it has no atoi() or sscanf(), but just strtol() with common errors: % case 'r': % num = strtol(optarg, &p, 10); % if (*p || num <= 0) % errx(1, "illegal -r value -- %s", optarg); % nfsargsp->rsize = num; % nfsargsp->flags |= NFSMNT_RSIZE; % break; This has mainly common overflow bugs: - strtol() returns long, so overflow may occur when it is blindly assigned to `num', which is int. Even if overflow is benign, it breaks the subsequent check that num <= 0. - no checking of overflows avoided by by strtol(), except when longs are longer than ints these cause overflow in the assignment here. Input consisting only of whitespace is detected bogusly as num being 0. - from FreeBSD-5.2 mount_nfs.c: it still uses strtol() in old code, but most new code uses atoi() like this: % if (altflags & ALTF_ACREGMAX) { % p = strstr(optarg, "acregmax="); % if (p) % nfsargsp->acregmax = atoi(p + 9); % } atoi() is unusable in serious parsing, since among other design errors, it gives undefined behaviour on overflow (except in FreeBSD, this behaviour is defined as being the same undefined behaviour that occurs on blind assignment of strtol() to int as done in the previous example). - from FreeBSD-current mount_nfs.c: % if (findopt(iov, iovlen, "rsize", &opt, NULL) == 0) { % if (opt == NULL) { % errx(1, "illegal rsize"); % } % ret = sscanf(opt, "%d", &args.rsize); % if (ret != 1 || args.rsize <= 0) { % errx(1, "illegal wsize: %s", opt); % } % args.flags |= NFSMNT_RSIZE; % } Now even the rsize parsing doesn't use strtol(). It uses sscanf(), whose behaviour on overflow is even more undefined than atoi()'s. Despite less error checking, the parsing is now more verbose, with the help of extra braces. It takes such care with strings that it spells "rsize" as "wsize" in the error message. From FreeBSD-current nfsclients (the new one, but I think they use identical code which is almost identical to the userland code, and triplicates all its bugs): % if (vfs_getopt(mp->mnt_optnew, "rsize", (void **)&opt, NULL) == 0) { % if (opt == NULL) { % vfs_mount_error(mp, "illegal rsize"); % error = EINVAL; % goto out; % } % ret = sscanf(opt, "%d", &args.rsize); % if (ret != 1 || args.rsize <= 0) { % vfs_mount_error(mp, "illegal wsize: %s", % opt); % error = EINVAL; % goto out; % } % args.flags |= NFSMNT_RSIZE; % } Parsing of strings in the kernel is even more laborious than in userland. sscanf() is unusable but used. I was asleep when it was committed to the kernel (it was at first used only for parsing a couple of path/device names for booting). The braces are needed now. The vfs_mount_error() line is unnecessarily split, and triplicates the misspelling of "rsize" as "wsize". % if ((argp->flags & NFSMNT_RSIZE) && argp->rsize > 0) { % nmp->nm_rsize = argp->rsize; % /* Round down to multiple of blocksize */ % nmp->nm_rsize &= ~(NFS_FABLKSIZE - 1); % if (nmp->nm_rsize <= 0) % nmp->nm_rsize = NFS_FABLKSIZE; % } % if (nmp->nm_rsize > maxio) % nmp->nm_rsize = maxio; % if (nmp->nm_rsize > MAXBSIZE) % nmp->nm_rsize = MAXBSIZE; This is old code for range checking of rsize. It is still useful and used once the value reaches the nfs_args struct. Not much wrong with it, but altogether it gives about 50 lines of option parsing and range checking code for a single simple numeric option, with bugs in the range checking for overflow cases and redundant checks for the <= 0 case. I would like to be able to write such code as nmp->nm_rsize = parsopt(stringval, minval, dfltval, maxval) in 1 place (actually table-driven). But the range should also be checked in the kernel a userland utility did the parsing. The kernel doesn't need to do any defaulting if userland does it. Bruce From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 11:09:23 2011 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 EDFCD106564A; Sun, 30 Jan 2011 11:09:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 64C928FC14; Sun, 30 Jan 2011 11:09:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0UB9ITx071618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 13:09:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0UB9Ik2056352; Sun, 30 Jan 2011 13:09:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0UB9IoW056351; Sun, 30 Jan 2011 13:09:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 30 Jan 2011 13:09:18 +0200 From: Kostik Belousov To: Ivan Voras Message-ID: <20110130110918.GR2518@deviant.kiev.zoral.com.ua> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9OLhvBqktUnNquIT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 30 Jan 2011 11:09:23 -0000 --9OLhvBqktUnNquIT Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 05:27:38PM +0100, Ivan Voras wrote: > On 19 January 2011 16:02, Kostik Belousov wrote: >=20 > >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch > >> > >> I don't think this is a complete solution but it's a start. If you can, > >> try it and see if it helps. > > This is not a start, and actually a step in the wrong direction. > > Tmpfs is wrong now, but the patch would make the wrongness even bigger. > > > > Issue is that the current tmpfs calculation should not depend on the > > length of the inactive queue or the amount of free pages. This data only > > measures =9Athe pressure on the pagedaemon, and has absolutely no relat= ion > > to the amount of data that can be put into anonymous objects before the > > system comes out of swap. > > > > vm_lowmem handler is invoked in two situations: > > - when KVA cannot satisfy the request for the space allocation; > > - when pagedaemon have to start the scan. > > None of the situations has any direct correlation with the fact that > > tmpfs needs to check, that is "Is there enough swap to keep all my > > future anonymous memory requests ?". > > > > Might be, swap reservation numbers can be useful to the tmpfs reporting. > > Also might be, tmpfs should reserve the swap explicitely on start, inst= ead > > of making attempts to guess how much can be allocated at random moment. >=20 > Thank you for your explanation! I'm still not very familiar with VM > and VFS. Could you also read my report at > http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html > ? I'm curious about the fact that there is lots of 'free' memory here > in the same situation. This is another ugliness in the dynamic calculation. Your wired is around 15GB, that is always greater then available swap + free + inactive. As result, tmpfs_mem_info() always returns 0. In this situation TMPFS_PAGES_MAX() seems to return negative value, and then TMPFS_PAGES_AVAIL() clamps at 0. >=20 > Do you think that there is something which can be done as a band-aid > without a major modification to tmpfs? --9OLhvBqktUnNquIT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1FRt0ACgkQC3+MBN1Mb4hw+ACfevIR8rgj+TkhYYi9QDEGikyT cvkAn3TX2xPZRson6FNi/4EL3kKWn7LY =YpCa -----END PGP SIGNATURE----- --9OLhvBqktUnNquIT-- From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 13:31:04 2011 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 EE205106566C for ; Sun, 30 Jan 2011 13:31:04 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4598FC0C for ; Sun, 30 Jan 2011 13:31:04 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 82310153446 for ; Sun, 30 Jan 2011 14:31:02 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CmCfUeGWST6 for ; Sun, 30 Jan 2011 14:30:59 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1] (unknown [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1]) by mail.digiware.nl (Postfix) with ESMTP id D63B7153435 for ; Sun, 30 Jan 2011 14:30:59 +0100 (CET) Message-ID: <4D456812.9060504@digiware.nl> Date: Sun, 30 Jan 2011 14:30:58 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 13:31:05 -0000 Hi, I've configured a fresh and new Supermicro server (with an X8SIL-F motherboard) an 2* 500GB seagate ST3500514NS 's. Disks are connected to: atapci0: I've created gpt partitions for freebsd-boot,swap,zfs on both disks. Wrote gptzfsboot in boot bootsectors. gpart add -s 128 -b34 -t freebsd-root ad{4,6} gpart add -s 16G -t freebsd-swap ad{4,6} gpart add -s 100G -t freebsd-zfs ad{4,6} gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} After which I did the "regular stuff" to create the system. Which seemed to have worked because when both disks are in the system everything is hunky-dory and boots as expected. Same for booting with the second disk removed. But with only the second disk in the system, it does not boot. Not even when I put it in the bay of the first disk. On screen I get: Error 1 lba 32 Error 1 lba 1 Error 1 lba 32 Error 1 lba 1 No ZFS pools located, can't boot I browsed thru the ZFS bootcode, but that is way to sophisticated for me. So why doesn't it like to boot of the second disk? What did I forget to do? Which is what I would like for this system to be able to do, in case of failure of the first disk. Thanx, --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 14:06:54 2011 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 71A6C106564A for ; Sun, 30 Jan 2011 14:06:54 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 595358FC0C for ; Sun, 30 Jan 2011 14:06:53 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p0UE6mJx031053 for ; Sun, 30 Jan 2011 16:06:48 +0200 (EET) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4D457077.4010507@ukr.net> Date: Sun, 30 Jan 2011 16:06:47 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4D456812.9060504@digiware.nl> In-Reply-To: <4D456812.9060504@digiware.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 14:06:54 -0000 30.01.2011 15:30, Willem Jan Withagen wrote: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} ^^^ -- Vladislav V. Prodan VVP24-UANIC +38[067]4584408 +38[099]4060508 vlad11@jabber.ru From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 14:32:29 2011 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 A7C9E1065670 for ; Sun, 30 Jan 2011 14:32:29 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 396658FC1C for ; Sun, 30 Jan 2011 14:32:29 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 02963153446; Sun, 30 Jan 2011 15:32:28 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWEM5ANaJSn4; Sun, 30 Jan 2011 15:32:25 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1] (unknown [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1]) by mail.digiware.nl (Postfix) with ESMTP id B2B6B153435; Sun, 30 Jan 2011 15:32:25 +0100 (CET) Message-ID: <4D457677.3000508@digiware.nl> Date: Sun, 30 Jan 2011 15:32:23 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Vladislav V. Prodan" References: <4D456812.9060504@digiware.nl> <4D457077.4010507@ukr.net> In-Reply-To: <4D457077.4010507@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 14:32:29 -0000 On 2011-01-30 15:06, Vladislav V. Prodan wrote: > 30.01.2011 15:30, Willem Jan Withagen wrote: >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} > ^^^ > Thanx for pointing out the typo. But this was only a retype of what I did, not a verbatim cut&paste. I've redone this action serveral times since I'm also tracking 8.2-PRERELEASE on a weekly basis. From the error message I concluded that gptzfsboot is available on the second disk. But in an odd way, it does not find a valid pool to boot from. If not, why is it giving me the reported message? Question is: why is the pool on the second disk not valid/available? --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 14:43:57 2011 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 A07AD1065673 for ; Sun, 30 Jan 2011 14:43:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 876228FC08 for ; Sun, 30 Jan 2011 14:43:57 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 1qWW1g0080vp7WLA4qWnfl; Sun, 30 Jan 2011 14:30:47 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta05.emeryville.ca.mail.comcast.net with comcast id 1qWm1g0022tehsa8RqWm60; Sun, 30 Jan 2011 14:30:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C41789B427; Sun, 30 Jan 2011 06:30:45 -0800 (PST) Date: Sun, 30 Jan 2011 06:30:45 -0800 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20110130143045.GA50566@icarus.home.lan> References: <4D456812.9060504@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D456812.9060504@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 14:43:57 -0000 On Sun, Jan 30, 2011 at 02:30:58PM +0100, Willem Jan Withagen wrote: > Hi, > > I've configured a fresh and new Supermicro server (with an X8SIL-F > motherboard) an 2* 500GB seagate ST3500514NS 's. > Disks are connected to: > atapci0: > > I've created gpt partitions for freebsd-boot,swap,zfs on both disks. > Wrote gptzfsboot in boot bootsectors. > gpart add -s 128 -b34 -t freebsd-root ad{4,6} > gpart add -s 16G -t freebsd-swap ad{4,6} > gpart add -s 100G -t freebsd-zfs ad{4,6} > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} > > After which I did the "regular stuff" to create the system. > > Which seemed to have worked because when both disks are in the > system everything is hunky-dory and boots as expected. > Same for booting with the second disk removed. > > But with only the second disk in the system, it does not boot. Not > even when I put it in the bay of the first disk. > > On screen I get: > Error 1 lba 32 > Error 1 lba 1 > Error 1 lba 32 > Error 1 lba 1 > No ZFS pools located, can't boot > > I browsed thru the ZFS bootcode, but that is way to sophisticated for me. > > So why doesn't it like to boot of the second disk? > What did I forget to do? > > Which is what I would like for this system to be able to do, in case > of failure of the first disk. uname -a output please. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 14:50:33 2011 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 81D92106564A for ; Sun, 30 Jan 2011 14:50:33 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF73F8FC13 for ; Sun, 30 Jan 2011 14:50:31 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 13474153448 for ; Sun, 30 Jan 2011 15:50:30 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjDzaVQLT8Su for ; Sun, 30 Jan 2011 15:50:27 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1] (unknown [IPv6:2001:4cb8:3:1:28a5:9b85:57d2:5fc1]) by mail.digiware.nl (Postfix) with ESMTP id 81EE215344A for ; Sun, 30 Jan 2011 15:50:27 +0100 (CET) Message-ID: <4D457AB1.90109@digiware.nl> Date: Sun, 30 Jan 2011 15:50:25 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 14:50:33 -0000 On 2011-01-30 15:30, Jeremy Chadwick wrote: > On Sun, Jan 30, 2011 at 02:30:58PM +0100, Willem Jan Withagen wrote: >> Hi, >> >> I've configured a fresh and new Supermicro server (with an X8SIL-F >> motherboard) an 2* 500GB seagate ST3500514NS 's. >> Disks are connected to: >> atapci0: >> >> I've created gpt partitions for freebsd-boot,swap,zfs on both disks. >> Wrote gptzfsboot in boot bootsectors. >> gpart add -s 128 -b34 -t freebsd-root ad{4,6} >> gpart add -s 16G -t freebsd-swap ad{4,6} >> gpart add -s 100G -t freebsd-zfs ad{4,6} >> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} >> >> After which I did the "regular stuff" to create the system. >> >> Which seemed to have worked because when both disks are in the >> system everything is hunky-dory and boots as expected. >> Same for booting with the second disk removed. >> >> But with only the second disk in the system, it does not boot. Not >> even when I put it in the bay of the first disk. >> >> On screen I get: >> Error 1 lba 32 >> Error 1 lba 1 >> Error 1 lba 32 >> Error 1 lba 1 >> No ZFS pools located, can't boot >> >> I browsed thru the ZFS bootcode, but that is way to sophisticated for me. >> >> So why doesn't it like to boot of the second disk? >> What did I forget to do? >> >> Which is what I would like for this system to be able to do, in case >> of failure of the first disk. > > uname -a output please. > FreeBSD big.medusa.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sat Jan 29 22:11:44 CET 2011 wjw@big.medusa.nl:/usr/obj/usr/src/sys/BIG amd64 Haven't tested it with this version though, but only with the build I did on 22 Jan, and then it didn't work. --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 15:15:44 2011 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 277A41065694 for ; Sun, 30 Jan 2011 15:15:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id CA1548FC16 for ; Sun, 30 Jan 2011 15:15:43 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id 1qZr1g0051ap0As59r2UlZ; Sun, 30 Jan 2011 15:02:28 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta22.westchester.pa.mail.comcast.net with comcast id 1r2T1g01X2tehsa3ir2Uvj; Sun, 30 Jan 2011 15:02:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8D2859B427; Sun, 30 Jan 2011 07:02:26 -0800 (PST) Date: Sun, 30 Jan 2011 07:02:26 -0800 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20110130150226.GA51190@icarus.home.lan> References: <20110130143045.GA50566@icarus.home.lan> <4D457AB1.90109@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D457AB1.90109@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 15:15:44 -0000 On Sun, Jan 30, 2011 at 03:50:25PM +0100, Willem Jan Withagen wrote: > On 2011-01-30 15:30, Jeremy Chadwick wrote: > >On Sun, Jan 30, 2011 at 02:30:58PM +0100, Willem Jan Withagen wrote: > >>Hi, > >> > >>I've configured a fresh and new Supermicro server (with an X8SIL-F > >>motherboard) an 2* 500GB seagate ST3500514NS 's. > >>Disks are connected to: > >> atapci0: > >> > >>I've created gpt partitions for freebsd-boot,swap,zfs on both disks. > >>Wrote gptzfsboot in boot bootsectors. > >>gpart add -s 128 -b34 -t freebsd-root ad{4,6} > >>gpart add -s 16G -t freebsd-swap ad{4,6} > >>gpart add -s 100G -t freebsd-zfs ad{4,6} > >>gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} > >> > >>After which I did the "regular stuff" to create the system. > >> > >>Which seemed to have worked because when both disks are in the > >>system everything is hunky-dory and boots as expected. > >>Same for booting with the second disk removed. > >> > >>But with only the second disk in the system, it does not boot. Not > >>even when I put it in the bay of the first disk. > >> > >>On screen I get: > >>Error 1 lba 32 > >>Error 1 lba 1 > >>Error 1 lba 32 > >>Error 1 lba 1 > >>No ZFS pools located, can't boot > >> > >>I browsed thru the ZFS bootcode, but that is way to sophisticated for me. > >> > >>So why doesn't it like to boot of the second disk? > >>What did I forget to do? > >> > >>Which is what I would like for this system to be able to do, in case > >>of failure of the first disk. > > > >uname -a output please. > > > FreeBSD big.medusa.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sat Jan > 29 22:11:44 CET 2011 wjw@big.medusa.nl:/usr/obj/usr/src/sys/BIG amd64 > > Haven't tested it with this version though, but only with the build I > did on 22 Jan, and then it didn't work. Thanks. The reason I asked for this was that there were some changes to the ZFS bootloader which may have addressed your problem, but those would have been before January 29th. This command looks suspicious thought, specifically the "-b34" argument: > >>gpart add -s 128 -b34 -t freebsd-root ad{4,6} Someone else will have to comment on the implications of that; I don't use GPT. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 19:32:55 2011 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 8CBC0106564A for ; Sun, 30 Jan 2011 19:32:55 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21A228FC0C for ; Sun, 30 Jan 2011 19:32:54 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 6532A153448; Sun, 30 Jan 2011 20:32:53 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPwyYVuNJv3f; Sun, 30 Jan 2011 20:32:50 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:e169:4e7:c7ea:8c2d] (unknown [IPv6:2001:4cb8:3:1:e169:4e7:c7ea:8c2d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 62283153447; Sun, 30 Jan 2011 20:32:50 +0100 (CET) Message-ID: <4D45BCE2.1020508@digiware.nl> Date: Sun, 30 Jan 2011 20:32:50 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <20110130143045.GA50566@icarus.home.lan> <4D457AB1.90109@digiware.nl> <20110130150226.GA51190@icarus.home.lan> In-Reply-To: <20110130150226.GA51190@icarus.home.lan> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 19:32:55 -0000 On 30-1-2011 16:02, Jeremy Chadwick wrote: > On Sun, Jan 30, 2011 at 03:50:25PM +0100, Willem Jan Withagen wrote: >> On 2011-01-30 15:30, Jeremy Chadwick wrote: >>> On Sun, Jan 30, 2011 at 02:30:58PM +0100, Willem Jan Withagen wrote: >>>> Hi, >>>> >>>> I've configured a fresh and new Supermicro server (with an X8SIL-F >>>> motherboard) an 2* 500GB seagate ST3500514NS 's. >>>> Disks are connected to: >>>> atapci0: >>>> >>>> I've created gpt partitions for freebsd-boot,swap,zfs on both disks. >>>> Wrote gptzfsboot in boot bootsectors. >>>> gpart add -s 128 -b34 -t freebsd-root ad{4,6} >>>> gpart add -s 16G -t freebsd-swap ad{4,6} >>>> gpart add -s 100G -t freebsd-zfs ad{4,6} >>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} >>>> >>>> After which I did the "regular stuff" to create the system. >>>> >>>> Which seemed to have worked because when both disks are in the >>>> system everything is hunky-dory and boots as expected. >>>> Same for booting with the second disk removed. >>>> >>>> But with only the second disk in the system, it does not boot. Not >>>> even when I put it in the bay of the first disk. >>>> >>>> On screen I get: >>>> Error 1 lba 32 >>>> Error 1 lba 1 >>>> Error 1 lba 32 >>>> Error 1 lba 1 >>>> No ZFS pools located, can't boot >>>> >>>> I browsed thru the ZFS bootcode, but that is way to sophisticated for me. >>>> >>>> So why doesn't it like to boot of the second disk? >>>> What did I forget to do? >>>> >>>> Which is what I would like for this system to be able to do, in case >>>> of failure of the first disk. >>> >>> uname -a output please. >>> >> FreeBSD big.medusa.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sat Jan >> 29 22:11:44 CET 2011 wjw@big.medusa.nl:/usr/obj/usr/src/sys/BIG amd64 >> >> Haven't tested it with this version though, but only with the build I >> did on 22 Jan, and then it didn't work. > > Thanks. The reason I asked for this was that there were some changes to > the ZFS bootloader which may have addressed your problem, but those > would have been before January 29th. Oke, enough reason to update again, and see what comes of it. It will have to wait until some of the bonnie tests are completed. > This command looks suspicious thought, specifically the "-b34" argument: > >>>> gpart add -s 128 -b34 -t freebsd-root ad{4,6} > > Someone else will have to comment on the implications of that; I don't > use GPT. Right, I see, but this comes from the "manuals" like: http://www.freebsdwiki.net/index.php/ZFS,_booting_from#Create_GPT_Disks And just to counter your suggestion: It does work for the "regular" first disk! So why not for a second disk? --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 19:43:36 2011 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 96170106566C for ; Sun, 30 Jan 2011 19:43:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 77C5C8FC0A for ; Sun, 30 Jan 2011 19:43:36 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 1vVz1g0030cQ2SLA2vjbW2; Sun, 30 Jan 2011 19:43:35 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta10.emeryville.ca.mail.comcast.net with comcast id 1vja1g00F2tehsa8WvjaQX; Sun, 30 Jan 2011 19:43:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6E85E9B427; Sun, 30 Jan 2011 11:43:34 -0800 (PST) Date: Sun, 30 Jan 2011 11:43:34 -0800 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20110130194334.GA57052@icarus.home.lan> References: <20110130143045.GA50566@icarus.home.lan> <4D457AB1.90109@digiware.nl> <20110130150226.GA51190@icarus.home.lan> <4D45BCE2.1020508@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D45BCE2.1020508@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 19:43:36 -0000 On Sun, Jan 30, 2011 at 08:32:50PM +0100, Willem Jan Withagen wrote: > On 30-1-2011 16:02, Jeremy Chadwick wrote: > > On Sun, Jan 30, 2011 at 03:50:25PM +0100, Willem Jan Withagen wrote: > >> On 2011-01-30 15:30, Jeremy Chadwick wrote: > >>> On Sun, Jan 30, 2011 at 02:30:58PM +0100, Willem Jan Withagen wrote: > >>>> Hi, > >>>> > >>>> I've configured a fresh and new Supermicro server (with an X8SIL-F > >>>> motherboard) an 2* 500GB seagate ST3500514NS 's. > >>>> Disks are connected to: > >>>> atapci0: > >>>> > >>>> I've created gpt partitions for freebsd-boot,swap,zfs on both disks. > >>>> Wrote gptzfsboot in boot bootsectors. > >>>> gpart add -s 128 -b34 -t freebsd-root ad{4,6} > >>>> gpart add -s 16G -t freebsd-swap ad{4,6} > >>>> gpart add -s 100G -t freebsd-zfs ad{4,6} > >>>> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad)4,6} > >>>> > >>>> After which I did the "regular stuff" to create the system. > >>>> > >>>> Which seemed to have worked because when both disks are in the > >>>> system everything is hunky-dory and boots as expected. > >>>> Same for booting with the second disk removed. > >>>> > >>>> But with only the second disk in the system, it does not boot. Not > >>>> even when I put it in the bay of the first disk. > >>>> > >>>> On screen I get: > >>>> Error 1 lba 32 > >>>> Error 1 lba 1 > >>>> Error 1 lba 32 > >>>> Error 1 lba 1 > >>>> No ZFS pools located, can't boot > >>>> > >>>> I browsed thru the ZFS bootcode, but that is way to sophisticated for me. > >>>> > >>>> So why doesn't it like to boot of the second disk? > >>>> What did I forget to do? > >>>> > >>>> Which is what I would like for this system to be able to do, in case > >>>> of failure of the first disk. > >>> > >>> uname -a output please. > >>> > >> FreeBSD big.medusa.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sat Jan > >> 29 22:11:44 CET 2011 wjw@big.medusa.nl:/usr/obj/usr/src/sys/BIG amd64 > >> > >> Haven't tested it with this version though, but only with the build I > >> did on 22 Jan, and then it didn't work. > > > > Thanks. The reason I asked for this was that there were some changes to > > the ZFS bootloader which may have addressed your problem, but those > > would have been before January 29th. > > Oke, enough reason to update again, and see what comes of it. > It will have to wait until some of the bonnie tests are completed. Sorry, I should be more clear: the changes I was referring to was committed back in September 2010, which means your RELENG_8 kernel of January 29th already has it. There's no need to update again. What I'm referring to: http://lists.freebsd.org/pipermail/freebsd-fs/2010-August/009016.html http://lists.freebsd.org/pipermail/freebsd-fs/2010-August/009018.html http://www.freebsd.org/cgi/query-pr.cgi?pr=148655 > > This command looks suspicious thought, specifically the "-b34" argument: > > > >>>> gpart add -s 128 -b34 -t freebsd-root ad{4,6} > > > > Someone else will have to comment on the implications of that; I don't > > use GPT. > > Right, I see, but this comes from the "manuals" like: > http://www.freebsdwiki.net/index.php/ZFS,_booting_from#Create_GPT_Disks > > And just to counter your suggestion: > It does work for the "regular" first disk! > So why not for a second disk? As stated, someone else will have to comment on the gpart arguments, as well as what the actual problem is. I don't have an answer. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 22:29:52 2011 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 7F54F106564A for ; Sun, 30 Jan 2011 22:29:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 140608FC14 for ; Sun, 30 Jan 2011 22:29:51 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 8F5CF153446 for ; Sun, 30 Jan 2011 23:29:50 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO68w3vIGwxU for ; Sun, 30 Jan 2011 23:29:48 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:e169:4e7:c7ea:8c2d] (unknown [IPv6:2001:4cb8:3:1:e169:4e7:c7ea:8c2d]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 00A8F153435 for ; Sun, 30 Jan 2011 23:29:47 +0100 (CET) Message-ID: <4D45E65C.2040200@digiware.nl> Date: Sun, 30 Jan 2011 23:29:48 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: fs@freebsd.org References: <20110130143045.GA50566@icarus.home.lan> <4D457AB1.90109@digiware.nl> <20110130150226.GA51190@icarus.home.lan> <4D45BCE2.1020508@digiware.nl> In-Reply-To: <4D45BCE2.1020508@digiware.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 30 Jan 2011 22:29:52 -0000 On 30-1-2011 20:32, Willem Jan Withagen wrote: >>>>> But with only the second disk in the system, it does not boot. Not >>>>> even when I put it in the bay of the first disk. >>>>> >>>>> On screen I get: >>>>> Error 1 lba 32 >>>>> Error 1 lba 1 >>>>> Error 1 lba 32 >>>>> Error 1 lba 1 >>>>> No ZFS pools located, can't boot This code stems from boot/boot2.c: static int drvread(void *buf, unsigned lba, unsigned nblk) { static unsigned c = 0x2d5c7c2f; v86.ctl = V86_ADDR | V86_CALLF | V86_FLAGS; v86.addr = XREADORG; /* call to xread in boot1 */ v86.es = VTOPSEG(buf); v86.eax = lba; v86.ebx = VTOPOFF(buf); v86.ecx = lba >> 16; v86.edx = nblk << 8 | dsk.drive v86int(); v86.ctl = V86_FLAGS; if (V86_CY(v86.efl)) { printf("error %u lba %u\n", v86.eax >> 8 & 0xff, lba); return -1; } return 0; } Suggesting that code from boot1 is used to read from the disk. Now the question would be why doesn't this then just work when I place the disk in at the first position. This is not going to be a charmer, diving back into assembly and old PC BIOS conventions.... Or could this occur when the MBR is not "correct"? --WjW From owner-freebsd-fs@FreeBSD.ORG Sun Jan 30 23:25:19 2011 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 43A9A106564A for ; Sun, 30 Jan 2011 23:25:19 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id CD3D68FC1D for ; Sun, 30 Jan 2011 23:25:18 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id E34C8F2DC7; Mon, 31 Jan 2011 00:25:17 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nVGFsQnRxVCU; Mon, 31 Jan 2011 00:25:15 +0100 (CET) Received: from [10.9.8.134] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id B754DF2DC0; Mon, 31 Jan 2011 00:25:15 +0100 (CET) Message-ID: <4D45F359.4040402@FreeBSD.org> Date: Mon, 31 Jan 2011 00:25:13 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Artem Belevich References: <4D443407.7010604@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 30 Jan 2011 23:25:19 -0000 I have re-checked OpenSolaris, and discovered that long is a int32_t. I agree, we should go for int64_t in our case. Dňa 29.01.2011 20:06, Artem Belevich wrote / napísal(a): > On Sat, Jan 29, 2011 at 7:36 AM, Martin Matuska wrote: >> I agree to you that we have different types and this may be an issue but >> I disagree to your patch. >> clock_t is not signed (int64_t) and this can be done in a much easier >> (and cleaner way) without touching the code, see attached patch. > > I like the minimalism of your patch. > > It should fix the overflow on LP64, but it would still be there on > i386. To avoid this particular problem we need int64_t even on 32-bit > platforms. Either that, or we should change the way we emulate > solaris' LBOLT in FreeBSD. > > Another concern I have is with this patch we'll end up with parts of > kernel compiled with 32-bit clock_t and other parts build with 64-bit > clock_t. If someone passes a pointer to clock_t between these two > classes of code, we'll have a problem. > > --Artem From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 05:25:41 2011 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 391B81065672; Mon, 31 Jan 2011 05:25:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id B89AA8FC0C; Mon, 31 Jan 2011 05:25:40 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0V5PWQE003310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 16:25:35 +1100 Date: Mon, 31 Jan 2011 16:25:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Matuska In-Reply-To: <4D45F359.4040402@FreeBSD.org> Message-ID: <20110131160644.P2539@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 31 Jan 2011 05:25:41 -0000 On Mon, 31 Jan 2011, Martin Matuska wrote: > I have re-checked OpenSolaris, and discovered that long is a int32_t. > > I agree, we should go for int64_t in our case. Why be different from both OpenSolaris and FreeBSD? clock_t is 32 bits on all, and only bogusly signed on some. Also, there must be another bug for overflow to occur after only 24 days. clock_t is only specified for holding statclock ticks, which have a frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of ticks. 32-bit signed ints hold 194 days of ticks. It is a units/type error to use clock_t for any other type of ticks. I used this an excuse to not expand clock_t on i386 about 15 years ago when I worked on this most. Clock ticks should be virtual and have a frequency much higher than 128, especially 15 years later. 1 MHz would have been OK 15 years ago, and some broken standards (XSI?) even required this. 1 GHz would have been good to cover the next 15 years, but it actually only lasted about 5 years since CPU frequencies exceeded it in about 2001. Now that CPU frequencies have stopped growing rapidly, there seem to be no clock periods much smaller than 0.1 nsec on the horizon, so 1 THz might last more than 5 years. But even 1 GHz will overflow a 32-bit signed int in about 2 seconds. IIRC, POSIX only requires clock_t to work for 24 hours, so overflow after 24 days isn't necessarily a bug, but overflow after 2 or 2000 seconds (the latter for 1 MHz) would be. POSIX mostly uses timespecs when more resolution is required, but this has only been standard for 23 years so support and use of them for are patchy. [Context lost to top posting] Bruce From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 09:03:56 2011 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 585E71065694; Mon, 31 Jan 2011 09:03:56 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA9618FC34; Mon, 31 Jan 2011 09:03:55 +0000 (UTC) Received: by bwz12 with SMTP id 12so5109898bwz.13 for ; Mon, 31 Jan 2011 01:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=734LAX8Pat4A+J/xMUIlI6+tmeaAwfFoI0yKMOsn+ik=; b=sZjJ15elfaCkEmpFRvMHZ7Dr0GYczgKQ2SzJpuOA9bRcjVWbOZijQGlhWphffpi9dV HBue71xeo4/kz3eU6rgQyqBpamn8XQWwYG041mm0DQazsNezVg9jR2wUn+qT7SmJ3x3R 2Xu/HzoTl8W49eSbNo5xlUQPtvOpnxJQqQM1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cNHggIETVTdBVrbu1SP2Ds0RaSnM57Ijt6Nyu4I5bdDEIxIv5CBHGBxwplSu7jIIHO KQNwDcFODW/dRr5NhFw+QTFegWB3PE3fPFBbIJwHDpxc0Wzs6cQrkenaGpQrOrw5hsRd QC/1chM6C5jvdDksmRonTrXZ45UK/bVJ1M81M= MIME-Version: 1.0 Received: by 10.204.123.14 with SMTP id n14mr4967377bkr.49.1296464632910; Mon, 31 Jan 2011 01:03:52 -0800 (PST) Sender: artemb@gmail.com Received: by 10.204.49.13 with HTTP; Mon, 31 Jan 2011 01:03:52 -0800 (PST) In-Reply-To: <20110131160644.P2539@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> <20110131160644.P2539@besplex.bde.org> Date: Mon, 31 Jan 2011 01:03:52 -0800 X-Google-Sender-Auth: KO7g3HCfKKa6DX_wzwYf36-O3Dg Message-ID: From: Artem Belevich To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 31 Jan 2011 09:03:56 -0000 On Sun, Jan 30, 2011 at 9:25 PM, Bruce Evans wrote: > On Mon, 31 Jan 2011, Martin Matuska wrote: > >> I have re-checked OpenSolaris, and discovered that long is a int32_t. Not true. It's 'long' which would be int64_t on LP64 and int32_t on ILP32 http://src.opensolaris.org/source/search?q=3D&project=3Donnv&defs=3Dclock_t= &refs=3D&path=3D&hist=3D > Why be different from both OpenSolaris and FreeBSD? =A0clock_t is 32 bits > on all, and only bogusly signed on some. See above. > Also, there must be another bug for overflow to occur after only 24 days. > clock_t is only specified for holding statclock ticks, which have a > frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of ticks= . clock_t is used in solaris code to hold LBOLT (rough equivalent of *uptime() in FreeBSD). When the code was ported to FreeBSD, LBOLT was implemented so that it holds uptime in HZ ticks. HZ happens to be 1000, so clock_t as implemented on FreeBSD will overflow in 24 days. --Artem From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 09:27:21 2011 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 956AE106564A; Mon, 31 Jan 2011 09:27:21 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2969A8FC1A; Mon, 31 Jan 2011 09:27:21 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id B7E1A137E51; Mon, 31 Jan 2011 10:27:19 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yylaPgApy7Wt; Mon, 31 Jan 2011 10:27:17 +0100 (CET) Received: from [10.0.3.144] (188-167-50-235.dynamic.chello.sk [188.167.50.235]) by mail.vx.sk (Postfix) with ESMTPSA id 54814137E3F; Mon, 31 Jan 2011 10:27:16 +0100 (CET) Message-ID: <4D468074.5050402@FreeBSD.org> Date: Mon, 31 Jan 2011 10:27:16 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Evans References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> <20110131160644.P2539@besplex.bde.org> In-Reply-To: <20110131160644.P2539@besplex.bde.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 31 Jan 2011 09:27:21 -0000 This is a problem for several places in the ZFS code, most of them in arc.c. The L2 issuse is quite clear: in arc.c: l2arc_feed_thread() we have the following statement: (void) cv_timedwait(&l2arc_feed_thr_cv, &l2arc_feed_thr_lock, next - LBOLT); next gets calculated from l2arc_write_interval() from the previous while() loop. Now a value of 0 will occur if l2arc_writ_interval() returns the same LBOLT, effectively making this a cv_wait(), negative values for the timeout are theoretically possible, too. In addition there are other areas in the code where comparative decisions based on a stored LBOLT and current LBOLT are made. A wrong decision made on clock_t overflow time might be harmful and cause unexpected behaviour. Affected are (what I have seen so far, in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/): arc.c: arc_access(), arc_reclaim_thread(), l2arc_write_interval(), l2arc_feed_thread() dmu_zfetch.c: dmu_zfetch_dofetch(), dmu_zfetch_stream_reclaim() zil.c: zil_replay() In userland we have some clock_t in: lib/libzpool/common/kernel.c Dňa 31.01.2011 06:25, Bruce Evans wrote / napísal(a): > On Mon, 31 Jan 2011, Martin Matuska wrote: > >> I have re-checked OpenSolaris, and discovered that long is a int32_t. >> >> I agree, we should go for int64_t in our case. > > Why be different from both OpenSolaris and FreeBSD? clock_t is 32 bits > on all, and only bogusly signed on some. > > Also, there must be another bug for overflow to occur after only 24 days. > clock_t is only specified for holding statclock ticks, which have a > frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of > ticks. > 32-bit signed ints hold 194 days of ticks. It is a units/type error to > use clock_t for any other type of ticks. I used this an excuse to not > expand clock_t on i386 about 15 years ago when I worked on this most. > Clock ticks should be virtual and have a frequency much higher than 128, > especially 15 years later. 1 MHz would have been OK 15 years ago, and > some broken standards (XSI?) even required this. 1 GHz would have been > good to cover the next 15 years, but it actually only lasted about 5 > years since CPU frequencies exceeded it in about 2001. Now that CPU > frequencies have stopped growing rapidly, there seem to be no clock > periods much smaller than 0.1 nsec on the horizon, so 1 THz might last > more than 5 years. But even 1 GHz will overflow a 32-bit signed int > in about 2 seconds. IIRC, POSIX only requires clock_t to work for > 24 hours, so overflow after 24 days isn't necessarily a bug, but overflow > after 2 or 2000 seconds (the latter for 1 MHz) would be. POSIX mostly > uses timespecs when more resolution is required, but this has only been > standard for 23 years so support and use of them for are patchy. > > [Context lost to top posting] > > Bruce > _______________________________________________ > 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 Jan 31 09:58:02 2011 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 8105B106564A for ; Mon, 31 Jan 2011 09:58:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B0B578FC0C for ; Mon, 31 Jan 2011 09:58:01 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 45C0CE8208 for ; Mon, 31 Jan 2011 09:58:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=mail; bh=vhEQF67LccpDuGqKNRv1r1qdW /A=; b=zI8GYZtoXlj1/Ok6ggy29DxbJq6BIur/cTwndu6r0DGUpw9QThNV/P5Jl 5iFE5yb2TprdsXVw5v3x5HzH/C3mAwiJNUr7wSXZn82GzUs6KNdwDFEICpCV1JWJ HDyzEN/m/70UzGOz8mOOks9XKmM+W02kGBnDcWj7VVXuRJI6kQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=GWg/jkq+02oc5Vs6xo8 MYw+/B9BmYCeCqLO7Uzv2lUK3j5raUaRxZ6QYK9kHXZc6tgtIDC/1xox2/eCitsx oPiLc9DIQkZJHP/msOKYoHah/rDmBDT5hBDQImsLzSeFepHc/znt00vShnT4meje tRV+5yYUXL5tw7TAUnDM6rqw= Received: from unknown (client-86-23-95-6.brhm.adsl.virginmedia.com [86.23.95.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id D2377E71A0 for ; Mon, 31 Jan 2011 09:57:59 +0000 (GMT) Date: Mon, 31 Jan 2011 09:57:52 +0000 From: Bruce Cran To: freebsd-fs@freebsd.org Message-ID: <20110131095752.00001957@unknown> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Configuring which pool to load zfsloader from 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, 31 Jan 2011 09:58:02 -0000 Hi, I recently reinstalled my system and after the initial installation created a second pool, zhome. After rebooting, the loader is trying to load zhome:/boot/zfsloader by default instead of the previous zroot:/boot/zfsloader. Is there a way to reconfigure it to use zroot instead of zhome? -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 11:07:00 2011 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 C410F10656A4 for ; Mon, 31 Jan 2011 11:07:00 +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 980B28FC1B for ; Mon, 31 Jan 2011 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0VB70xN091762 for ; Mon, 31 Jan 2011 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0VB6xkD091760 for freebsd-fs@FreeBSD.org; Mon, 31 Jan 2011 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Jan 2011 11:06:59 GMT Message-Id: <201101311106.p0VB6xkD091760@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, 31 Jan 2011 11:07:00 -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 -------------------------------------------------------------------------------- f 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf 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/153584 fs [ext2fs] [patch] Performance fix and cleanups for BSD o kern/153552 fs [zfs] zfsboot from 8.2-RC1 freeze at boot time 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/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs 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 o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs 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 o 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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/142914 fs [zfs] ZFS performance degradation over time 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD 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/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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/138790 fs [zfs] ZFS ceases caching when mem demand is high 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/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int 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 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/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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/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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp 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/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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 bin/94635 fs snapinfo(8)/libufs only works for disk-backed filesyst 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 kern/33464 fs [ufs] soft update inconsistencies after system crash 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 219 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 12:00:16 2011 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 7F54D106566B; Mon, 31 Jan 2011 12:00:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id E9FC28FC13; Mon, 31 Jan 2011 12:00:15 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0VC06At032305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 23:00:08 +1100 Date: Mon, 31 Jan 2011 23:00:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Artem Belevich In-Reply-To: Message-ID: <20110131224103.M15650@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> <20110131160644.P2539@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs , Martin Matuska Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 31 Jan 2011 12:00:16 -0000 On Mon, 31 Jan 2011, Artem Belevich wrote: > On Sun, Jan 30, 2011 at 9:25 PM, Bruce Evans wrote: > >> Also, there must be another bug for overflow to occur after only 24 days. >> clock_t is only specified for holding statclock ticks, which have a >> frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of ticks. > > clock_t is used in solaris code to hold LBOLT (rough equivalent of > *uptime() in FreeBSD). When the code was ported to FreeBSD, LBOLT was > implemented so that it holds uptime in HZ ticks. HZ happens to be > 1000, so clock_t as implemented on FreeBSD will overflow in 24 days. Certainly a bug. More than 1: - clock_t is for stathz ticks, but is abused to count hz ticks. - the type for hz ticks is plain int. This is even smaller than clock_t provided clock_t is correctly unsigned. It should be a larger type if hz is much larger than stathz. It worked better when hz was a little smaller than stathz, as it still needs to be so that it is not too easy to hide from the scheduler using timeouts to schedule yourself. When hz was 100, timeouts worked for 194 days, but now they only work for 24 days. - neither of these types can represent long times, but the time may be a long time and clock_t is abused to represent it. Plain int64_t might work. Many times are still represented as timevals, and the tvtohz() function is used to convert them to a timeout in hz ticks without overflow (long times are clamped to the maximum). Bruce From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 12:31:52 2011 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 6799C106564A; Mon, 31 Jan 2011 12:31:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id DE5FD8FC17; Mon, 31 Jan 2011 12:31:51 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0VCVmkU029423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 23:31:48 +1100 Date: Mon, 31 Jan 2011 23:31:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Martin Matuska In-Reply-To: <4D468074.5050402@FreeBSD.org> Message-ID: <20110131230041.W15650@besplex.bde.org> References: <4D443407.7010604@FreeBSD.org> <4D45F359.4040402@FreeBSD.org> <20110131160644.P2539@besplex.bde.org> <4D468074.5050402@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-150974143-1296477107=:15650" Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 31 Jan 2011 12:31:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-150974143-1296477107=:15650 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 31 Jan 2011, Martin Matuska wrote: > This is a problem for several places in the ZFS code, most of them in > arc.c. The L2 issuse is quite clear: > in arc.c: l2arc_feed_thread() we have the following statement: > > (void) cv_timedwait(&l2arc_feed_thr_cv, &l2arc_feed_thr_lock, > next - LBOLT); > > next gets calculated from l2arc_write_interval() from the previous > while() loop. > Now a value of 0 will occur if l2arc_writ_interval() returns the same > LBOLT, effectively making this a cv_wait(), > negative values for the timeout are theoretically possible, too. Ugh. Bugs like this are avoided for timevals by doing all conversions using tvtohz(). This involves lots more than subtracting values. There is some magic for zero and negative timeouts. I wanted tvtohz() to panic for them, but it only has a printf() and that is normally inactive since it is under DIAGNOSTIC. callout_reset_on() still silently changes timeouts of <=3D 0 to 1. cv_timedwait() seems to call that eventually, so I don't se why a negative timeout in the above would cause larger problems -- it should just wake up early, which should be handled since it can happen for other reasons. nanosleep() handles long timeouts by waking up early (after only 24 days) and going back to sleep. > In addition there are other areas in the code where comparative > decisions based on a stored LBOLT and current LBOLT are made. > A wrong decision made on clock_t overflow time might be harmful and > cause unexpected behaviour. I didn't see all of the early discussion. Once timeouts become negative (but changed to 1 by callout_reset_on), they might remain that way for a long time until LBOLT and/or `next' overflow again, and this would waste time at best. If their types are significantly different (say long for next and int for LBOLT, where long happens to be 64 bits and int happens to be 32 bits), then only 1 of them will overflow and it will never catch up with the other. Similar problems with network sequence numbers are rendered mostly harmless by making all values wrap at the same point, but similar bugs result if the "next" number is actually before the "current" number or only 1 of the types is bogusly casted or if a difference is assigned to a mismatched type... > Affected are (what I have seen so far, in > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/): > arc.c: arc_access(), arc_reclaim_thread(), l2arc_write_interval(), > l2arc_feed_thread() > dmu_zfetch.c: dmu_zfetch_dofetch(), dmu_zfetch_stream_reclaim() > zil.c: zil_replay() > > In userland we have some clock_t in: > lib/libzpool/common/kernel.c > > D=C5=88a 31.01.2011 06:25, Bruce Evans wrote / nap=C3=ADsal(a): >> On Mon, 31 Jan 2011, Martin Matuska wrote: >> >>> I have re-checked OpenSolaris, and discovered that long is a int32_t. >>> >>> I agree, we should go for int64_t in our case. If there are no pointers in sight, then you can probably just use int64_t for LBOLT. The type of `next', and overflows on implicit conversion of `next - LBOLT' to int by the prototype should still be checked. I think bugs in these are relatively harmless -- provided neither `next' or LBOLT overflows, their difference will usually be relatively small and positive, and glitches when it is negative will be handled by callout_reset_on() changing it to 1. Only cases where the overflow gives a large positive value (24 days is possible) wouldn't be harmless. Another harmless case would be if sign extension bugs and/or type bugs give a value near -1U, as happens in many overflow cases. -1U overflows again in the conversion in the prototype and becomes -1 on 2's complement machines, and then 1 in callout_reset_on(). Bruce --0-150974143-1296477107=:15650-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 13:45:28 2011 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 9C52B106566B for ; Mon, 31 Jan 2011 13:45:28 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 398738FC14 for ; Mon, 31 Jan 2011 13:45:27 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Pju3e-0002Cc-F1; Mon, 31 Jan 2011 15:44:42 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id EF0271CC44; Mon, 31 Jan 2011 15:45:26 +0200 (EET) Date: Mon, 31 Jan 2011 15:45:26 +0200 From: Andrey Simonenko To: Rick Macklem Message-ID: <20110131134526.GB21870@pm513-1.comsys.ntu-kpi.kiev.ua> References: <715248679.1071311.1296332245920.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <715248679.1071311.1296332245920.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-01-31 15:44:42 X-Connected-IP: 10.18.52.101:15245 X-Message-Linecount: 102 X-Body-Linecount: 86 X-Message-Size: 4181 X-Body-Size: 3418 Cc: freebsd-fs@freebsd.org, Mickael Canevet Subject: Re: "rpc mount export: RPC: Can't decode result" when export list is to long 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, 31 Jan 2011 13:45:28 -0000 On Sat, Jan 29, 2011 at 03:17:25PM -0500, Rick Macklem wrote: > Oops, I should have looked at the sources... > > In mountd.c it limits the RPC size to 8800 for UDP and 9000 > for TCP. (UDPMSGSIZE and RPC_MAXDATASIZE respectively) > > You could increase this by changing: > svc_dg_create(...,0, 0); > else > svc_vc_create(...,RPC_MAXDATASIZE, RPC_MAXDATASIZE); > > to > svc_dg_create(..., 63 * 1024, 63 * 1024); > else > svc_vc_create(..., 200 * 1024, 200 * 1024); > in mountd.c > > But... > The Linux client might set a smaller limit in its client > side RPC library anyhow. > > Again, I am surprised that the Linux automount checks the > exports reported via mountd, but??? > > Did you check to see if the mounts work manually? > (That would confirm if they are exported ok.) > > rick > ps: UDP datagrams are limited to 64K, but since I can't remember > if that size includes the UDP header, I went with 63K. For > TCP it is limited to 256K in the RPC library and to a somewhat > lower value with the default kern.ipc.maxsockbuf. (Basically > what the kernel sets sb_max_adj to.) The problem is in the RPC library code, that was my first idea since I could reproduce this mistake with my nfse. Sometimes the answer for MOUNT EXPORT request was truncated, sometimes the answer was damaged. I wrote a special client/server program that use RPC to reproduce this mistake. I did not see this mistake if a TCP socket is blocking (just remove the rpc_control(RPC_SVC_CONNMAXREC_SET) call from the mountd.c or nfse.c and check result), but this mistake exists when a non-blocking socket for RPC is used. Here is the problem description. The libc/rpc/svc_vc.c:write_vc() function calls _write() and sends data to opened TCP connection. For non-blocking socket it has something like timeout in 2 seconds (actually write_vc() can spend more real time for sending for non-blocking socket). The i variable is used for offset in a buffer and as a counter at the same time. When _write() fails this variable got the -1 value and this value as added to the buffer address and to the counter (the buffer address is decreased and the counter value actually is increased). So we get buffer underflow. As a result write_vc() can send data that does not belong to data that were expected to be sent, so this is a security mistake for any program that use RPC with a non-blocking TCP socket. This this the update (this is the minimal version, without optimization): --- svc_vc.c.orig 2009-08-03 11:13:06.000000000 +0300 +++ svc_vc.c 2011-01-31 11:31:28.000000000 +0200 @@ -546,7 +546,7 @@ write_vc(xprtp, buf, len) cd->strm_stat = XPRT_DIED; return (-1); } - if (cd->nonblock && i != cnt) { + if (cd->nonblock) { /* * For non-blocking connections, do not * take more than 2 seconds writing the @@ -560,6 +560,7 @@ write_vc(xprtp, buf, len) return (-1); } } + i = 0; } } After this update I could not reproduce this mistake with nfse under 8-STABLE, for tests I created nfs.exports file with 10.000 pathnames, each of them has 18 addresses in specification. ------------------------------------------- I have another question. Why does mountd need two versions for MOUNT EXPORT request's answer (complete and brief)? I checked other implementations of showmount and non of them try to send second query if the first query failed. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 13:45:29 2011 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 83A371065698 for ; Mon, 31 Jan 2011 13:45:29 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id E16788FC15 for ; Mon, 31 Jan 2011 13:45:28 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PjtAL-0007gI-Rz; Mon, 31 Jan 2011 14:47:33 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id E07A81CC44; Mon, 31 Jan 2011 14:48:17 +0200 (EET) Date: Mon, 31 Jan 2011 14:48:17 +0200 From: Andrey Simonenko To: Mickael Canevet Message-ID: <20110131124817.GA21870@pm513-1.comsys.ntu-kpi.kiev.ua> References: <1296137375.27843.11.camel@pc286.embl.fr> <46cfac53-03f5-4f3f-a34a-a4a504af31b0@email.android.com> <1296141430.27843.16.camel@pc286.embl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1296141430.27843.16.camel@pc286.embl.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 10-Dec-2010 16:36:10) X-Date: 2011-01-31 14:47:33 X-Connected-IP: 10.18.52.101:37446 X-Message-Linecount: 51 X-Body-Linecount: 33 X-Message-Size: 2152 X-Body-Size: 1334 Cc: freebsd-fs@freebsd.org, Weldon Godfrey Subject: Re: "rpc mount export: RPC: Can't decode result" when export list is to long 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, 31 Jan 2011 13:45:29 -0000 On Thu, Jan 27, 2011 at 04:17:10PM +0100, Mickael Canevet wrote: > Hi, > > Thank you for you quick answer. > > I tested with 'sysctl vfs.nfsrv.maxthreads=20' and even 'sysctl > vfs.nfsrv.maxthreads=1000' (though I'm not sure it's reasonable), but I > still have the problem. Moreover, sysctl vfs.nfsrv.threads stays to 4 > (maybe it goes up, then down before I can notice anything)... > > I noticed that if I wait a few minutes, showmount -e works once, then > fails again. > > Somebody has another idea ? > When one runs "showmount -e server", then this program sends the MOUNT protocol's procedure EXPORT RPC request to the server and it generates the answer. The mountd(8) program is responsible for MOUNT protocol requests, so the kernel part of the NFS server is not related to the problem you've described. I can reproduce this mistake on 8-STABLE and 9-CURRENT with mountd(8) and nfse [1]. These implementations are different, and looks like that I've found and corrected the problem for RPC services that use TCP non- blocking sockets. At least after my update I do not see this mistake neither with nfse nor with specially written program (I wrote it to reproduce the problem and to minimize impact of possible other mistakes in mountd or nfse). See my next messages for details. [1] http://nfse.sourceforge.net/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 14:36:02 2011 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 D0C081065670 for ; Mon, 31 Jan 2011 14:36:02 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A2FC98FC0C for ; Mon, 31 Jan 2011 14:36:02 +0000 (UTC) Received: by iwn39 with SMTP id 39so5545228iwn.13 for ; Mon, 31 Jan 2011 06:36:02 -0800 (PST) Received: by 10.42.170.1 with SMTP id d1mr7922854icz.227.1296483207601; Mon, 31 Jan 2011 06:13:27 -0800 (PST) Received: from wawanesa.iciti.ca (CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com [99.246.61.82]) by mx.google.com with ESMTPS id f7sm16198183icq.17.2011.01.31.06.13.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 06:13:26 -0800 (PST) Message-ID: <4D46C2E9.8000603@bellanet.org> Date: Mon, 31 Jan 2011 09:10:49 -0500 From: Graham Todd User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110118 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20110131095752.00001957@unknown> In-Reply-To: <20110131095752.00001957@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Configuring which pool to load zfsloader from 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, 31 Jan 2011 14:36:02 -0000 On 01/31/11 04:57, Bruce Cran wrote: > Hi, > > I recently reinstalled my system and after the initial installation > created a second pool, zhome. After rebooting, the loader is > trying to load zhome:/boot/zfsloader by default instead of the previous > zroot:/boot/zfsloader. Is there a way to reconfigure it to use zroot > instead of zhome? Hmm I assumed setting the root for the loader in /boot/loader.conf would work. eg: vfs.root.mountfrom="zfs:zroot" but I have never created a second pool during installation (I plan to when 9.0-RELEASE comes out, so I hope it's not too tricky). Perhaps the installation process defaulted to telling the loader to use the new pool somehow? From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 15:26:54 2011 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 BFDF91065672; Mon, 31 Jan 2011 15:26:54 +0000 (UTC) (envelope-from chreo@chreo.net) Received: from kontorsmtp1.one.com (kontorsmtp1.one.com [195.47.247.16]) by mx1.freebsd.org (Postfix) with ESMTP id 81DA48FC0A; Mon, 31 Jan 2011 15:26:54 +0000 (UTC) Received: from [10.0.0.13] (78-72-68-136-no33.tbcn.telia.com [78.72.68.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kontorsmtp1.one.com (Postfix) with ESMTP id A9E132F80270B; Mon, 31 Jan 2011 15:10:08 +0000 (UTC) Message-ID: <4D46D0CF.8090103@chreo.net> Date: Mon, 31 Jan 2011 16:10:07 +0100 From: Chreo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, Martin Matuska References: <4D0A09AF.3040005@FreeBSD.org> In-Reply-To: <4D0A09AF.3040005@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: New ZFSv28 patchset for 8-STABLE 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, 31 Jan 2011 15:26:54 -0000 Hello Martin, On 2010-12-16 13:44, Martin Matuska wrote: > Following the announcement of Pawel Jakub Dawidek (pjd@FreeBSD.org) I am > providing a ZFSv28 testing patch for 8-STABLE. > > Link to the patch: > > http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20101215.patch.xz > I've tested http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110116-nopython.patch.xz with 8-STABLE from 2011-01-18 Seems to work nicely except for a panic when importing a degraded pool on GELI vdevs: (captured from the screen and OCR'd) vdev.geom_detach:156[1]: Closing access to label/Disk.4.eli. vdev.geom_detach:160[1]: Destroyed consumer to label/Disk.4.eli. vdev.geomdetach:156[1]: Closing access to label/Disk.5.eli. vdev.geom_detach:160[1]: Destroyed consumer to label/Disk.5.eli. Solaris: WARNING: can't open objset for Ocean/Images panic: solaris assert: bpobj_iterate(defer_bpo, spa_free_sync_cb, zio, tx) == 0 (0x6 == 0x0), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c, line: 5576 cpuid = 1 KDB: stack backtrace: #0 0xffffffff802f14ce at kdb_backtrace+0x5e #1 0xffffffff802bf877 at panic+Ox187 #2 0xffffffff808e0c48 at spa_sync+0x978 #3 0xffffffff808f1011 at txg_sync_thread+0x271 #4 0xffffffff802960b7 at fork_exit+0x117 #5 0xffffffff804b7a7e at fork_trampoline+0xe GEOM_ELI: Device label/Disk.5.eli destroyed. GEOM_ELI: Device label/Disk.4.eli destroyed. The command run was: # zpool import -F Ocean and that worked with ZFS v15 The panic is 100% reproducible. The reason for this import was that I wanted to try and clear the log (something which is possible on v28 but not v15 it seems) with: zpool clear Ocean, and that caused a panic. An export was done and the import was tried. Using the same command on v15 works and imports the pool but it is faulted (due to the log). Anything I can test or do about this? I've also tried importing with -o failmode=continue and that does absolutely nothing to prevent the panic. The other pool on the same system works perfectly so far with v28. Many thanks to you and PJD for your work on ZFS. Regards, Christian Elmerot From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 18:14:02 2011 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 7047F1065675 for ; Mon, 31 Jan 2011 18:14:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 988478FC08 for ; Mon, 31 Jan 2011 18:14:01 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D9763E8208; Mon, 31 Jan 2011 18:13:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=DGuMY0g9bfo0 Si4jjg+hfpxRGsQ=; b=UdIRms7hwKaN3vSwY04oveExtOtf160PqLZAzsEYzuWa liMFdG4Hyh0PIC1UwljBSWSRjTXuJAq7ntkg8ENtUSAMsfUqmPG8kGFk7x8Wp+J9 +5wyg+OcnmMkAGbql8Dt8l0n64/0rMfDQTa3DFtNAedKO93NKaQ/P4rKgZllbGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=Z2ETTk ZXTnbZ4zjzIeHkSHpHyk+4vGw++DdoO3Ff0x0bQcElx8eCK+Gysw7dJ/cCLUR6CU vZ60Lc9rrAu9a71BU/0Fd9oF/6k3HVD92+qpP7rl3EiC+BnE1QT8mFZHiBSleMbB AoRY419wZiaO+69B/sRmUV/OskapvxsKULiyA= Received: from unknown (client-86-23-95-6.brhm.adsl.virginmedia.com [86.23.95.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 90581E818D; Mon, 31 Jan 2011 18:13:59 +0000 (GMT) Date: Mon, 31 Jan 2011 18:13:55 +0000 From: Bruce Cran To: Graham Todd Message-ID: <20110131181355.00006075@unknown> In-Reply-To: <4D46C2E9.8000603@bellanet.org> References: <20110131095752.00001957@unknown> <4D46C2E9.8000603@bellanet.org> X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Configuring which pool to load zfsloader from 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, 31 Jan 2011 18:14:02 -0000 On Mon, 31 Jan 2011 09:10:49 -0500 Graham Todd wrote: > Hmm I assumed setting the root for the loader in /boot/loader.conf > would work. eg: > > vfs.root.mountfrom="zfs:zroot" This is before the loader: it's the first stage (boot2?) that _loads_ the loader. I created the pool after installation, but for some reason the bootloader wants to load from the new pool. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 19:15:55 2011 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 26A83106566B for ; Mon, 31 Jan 2011 19:15:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id D317F8FC0A for ; Mon, 31 Jan 2011 19:15:54 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0VJFqTF037526 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 14:15:53 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D470A65.4050000@sentex.net> Date: Mon, 31 Jan 2011 14:15:49 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4D43475D.5050008@sentex.net> <4D44D775.50507@jrv.org> In-Reply-To: <4D44D775.50507@jrv.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS help! 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, 31 Jan 2011 19:15:55 -0000 On 1/29/2011 10:13 PM, James R. Van Artsdalen wrote: > On 1/28/2011 4:46 PM, Mike Tancsa wrote: >> >> I had just added another set of disks to my zfs array. It looks like the >> drive cage with the new drives is faulty. I had added a couple of files >> to the main pool, but not much. Is there any way to restore the pool >> below ? I have a lot of files on ad0,1,4,6 and ada4,5,6,7 and perhaps >> one file on the new drives in the bad cage. > > Get another enclosure and verify it works OK. Then move the disks from > the suspect enclosure to the tested enclosure and try to import the pool. > > The problem may be cabling or the controller instead - you didn't > specify how the disks were attached or which version of FreeBSD you're > using. > OK, good news (for me) it seems. New cage and all seems to be recognized correctly. The history is ... 2010-04-22.14:27:38 zpool add tank1 raidz /dev/ada4 /dev/ada5 /dev/ada6 /dev/ada7 2010-06-11.13:49:33 zfs create tank1/argus-data 2010-06-11.13:49:41 zfs create tank1/argus-data/previous 2010-06-11.13:50:38 zfs set compression=off tank1/argus-data 2010-08-06.12:20:59 zpool replace tank1 ad1 ad1 2010-09-16.10:17:51 zpool upgrade -a 2011-01-28.11:45:43 zpool add tank1 raidz /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 FreeBSD RELENG_8 from last week, 8G of RAM, amd64. zpool status -v pool: tank1 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 scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada6 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: /tank1/argus-data/previous/argus-sites-radium.2011.01.28.16.00 tank1/argus-data:<0xc6> /tank1/argus-data/argus-sites-radium 0(offsite)# zpool get all tank1 NAME PROPERTY VALUE SOURCE tank1 size 14.5T - tank1 used 7.56T - tank1 available 6.94T - tank1 capacity 52% - tank1 altroot - default tank1 health ONLINE - tank1 guid 7336939736750289319 default tank1 version 15 default tank1 bootfs - default tank1 delegation on default tank1 autoreplace off default tank1 cachefile - default tank1 failmode wait default tank1 listsnapshots on local Do I just want to do a scrub ? Unfortunately, http://www.sun.com/msg/ZFS-8000-8A gives a 503 ---Mike From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 19:23:10 2011 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 04125106566B for ; Mon, 31 Jan 2011 19:23:10 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8435C8FC12 for ; Mon, 31 Jan 2011 19:23:09 +0000 (UTC) Received: by fxm16 with SMTP id 16so6179200fxm.13 for ; Mon, 31 Jan 2011 11:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nI/ypO06BkmD3JtnFbeLvYvR5QkgJEpLy4+NMcy/CqM=; b=vgKHQ2TrEyL86y0hhLFD3JiEL9o62stLRx0kQy4WmizMB+nO/n0YMuM/I0QmLowI2t 9ipeUheKzqjLQzAwo7xJAe59CS0qg7g4zTqoNYFKnupOVbJoaUjcvDejISxmfLkOzeER chVJYkJaTsIZWlCdYT1HMjmNg62PxbwaWnNf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RsBLLc78iizKW/l+GutnkDfyaShRi8y800KvsnBY0lK1qRh7ZpUdOli3r0fTbBRNRu Wk1XbP4H1F5+LoKirE7J0/LE+yB7M6ZIunNhKhFzVZbxazj5bIEPC9t9Yu77+S5ZSIEY vSHT4cbS4GF+6nKvpnrBl/fzlICArivI9+t+4= MIME-Version: 1.0 Received: by 10.223.106.129 with SMTP id x1mr6407512fao.13.1296501788480; Mon, 31 Jan 2011 11:23:08 -0800 (PST) Received: by 10.223.114.4 with HTTP; Mon, 31 Jan 2011 11:23:08 -0800 (PST) In-Reply-To: <4D470A65.4050000@sentex.net> References: <4D43475D.5050008@sentex.net> <4D44D775.50507@jrv.org> <4D470A65.4050000@sentex.net> Date: Mon, 31 Jan 2011 13:23:08 -0600 Message-ID: From: Adam Vande More To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS help! 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, 31 Jan 2011 19:23:10 -0000 On Mon, Jan 31, 2011 at 1:15 PM, Mike Tancsa wrote: > On 1/29/2011 10:13 PM, James R. Van Artsdalen wrote: > > On 1/28/2011 4:46 PM, Mike Tancsa wrote: > >> > >> I had just added another set of disks to my zfs array. It looks like the > >> drive cage with the new drives is faulty. I had added a couple of files > >> to the main pool, but not much. Is there any way to restore the pool > >> below ? I have a lot of files on ad0,1,4,6 and ada4,5,6,7 and perhaps > >> one file on the new drives in the bad cage. > > > > Get another enclosure and verify it works OK. Then move the disks from > > the suspect enclosure to the tested enclosure and try to import the pool. > > > > The problem may be cabling or the controller instead - you didn't > > specify how the disks were attached or which version of FreeBSD you're > > using. > > > > OK, good news (for me) it seems. New cage and all seems to be recognized > correctly. The history is > > ... > 2010-04-22.14:27:38 zpool add tank1 raidz /dev/ada4 /dev/ada5 /dev/ada6 > /dev/ada7 > 2010-06-11.13:49:33 zfs create tank1/argus-data > 2010-06-11.13:49:41 zfs create tank1/argus-data/previous > 2010-06-11.13:50:38 zfs set compression=off tank1/argus-data > 2010-08-06.12:20:59 zpool replace tank1 ad1 ad1 > 2010-09-16.10:17:51 zpool upgrade -a > 2011-01-28.11:45:43 zpool add tank1 raidz /dev/ada0 /dev/ada1 /dev/ada2 > /dev/ada3 > > FreeBSD RELENG_8 from last week, 8G of RAM, amd64. > > zpool status -v > pool: tank1 > 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 > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank1 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad0 ONLINE 0 0 0 > ad1 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ada0 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ada5 ONLINE 0 0 0 > ada8 ONLINE 0 0 0 > ada7 ONLINE 0 0 0 > ada6 ONLINE 0 0 0 > > errors: Permanent errors have been detected in the following files: > > /tank1/argus-data/previous/argus-sites-radium.2011.01.28.16.00 > tank1/argus-data:<0xc6> > /tank1/argus-data/argus-sites-radium > > 0(offsite)# zpool get all tank1 > NAME PROPERTY VALUE SOURCE > tank1 size 14.5T - > tank1 used 7.56T - > tank1 available 6.94T - > tank1 capacity 52% - > tank1 altroot - default > tank1 health ONLINE - > tank1 guid 7336939736750289319 default > tank1 version 15 default > tank1 bootfs - default > tank1 delegation on default > tank1 autoreplace off default > tank1 cachefile - default > tank1 failmode wait default > tank1 listsnapshots on local > > > Do I just want to do a scrub ? > > Unfortunately, http://www.sun.com/msg/ZFS-8000-8A gives a 503 > A scrub will not help fix those files, but if it was me I'd do it anyway to ensure consistency. http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html I've seen similar types of corruption on ZFS when using devices that don't obey cache flush. Perhaps this can help provide some understanding. http://blogs.digitar.com/jjww/2006/12/shenanigans-with-zfs-flushing-and-intelligent-arrays/ -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Mon Jan 31 20:10:26 2011 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 6C09E1065693 for ; Mon, 31 Jan 2011 20:10:26 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD288FC26 for ; Mon, 31 Jan 2011 20:10:25 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0VKALJO050096 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 15:10:21 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D471729.3050804@sentex.net> Date: Mon, 31 Jan 2011 15:10:17 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Vande More References: <4D43475D.5050008@sentex.net> <4D44D775.50507@jrv.org> <4D470A65.4050000@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS help! 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, 31 Jan 2011 20:10:26 -0000 On 1/31/2011 2:23 PM, Adam Vande More wrote: > On Mon, Jan 31, 2011 at 1:15 PM, Mike Tancsa wrote: >> zpool status -v >> pool: tank1 >> 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 ... >> errors: Permanent errors have been detected in the following files: >> >> /tank1/argus-data/previous/argus-sites-radium.2011.01.28.16.00 >> tank1/argus-data:<0xc6> >> /tank1/argus-data/argus-sites-radium >> >> Do I just want to do a scrub ? >> >> Unfortunately, http://www.sun.com/msg/ZFS-8000-8A gives a 503 >> > > A scrub will not help fix those files, but if it was me I'd do it anyway to > ensure consistency. Thanks! I dont mind losing those files. I just want to get all back to a 'good' state. > > http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html > > I've seen similar types of corruption on ZFS when using devices that don't > obey cache flush. Perhaps this can help provide some understanding. > > http://blogs.digitar.com/jjww/2006/12/shenanigans-with-zfs-flushing-and-intelligent-arrays/ > Hmmm, I was able to delete two of the files that have actual names to them, but I cant find the other and now it shows errors: Permanent errors have been detected in the following files: tank1/argus-data:<0xc5> tank1/argus-data:<0xc6> tank1/argus-data:<0xc7> 0(offsite)# echo "ibase=16; C5" | bc 197 0(offsite)# find . -inum 197 0(offsite)# find . -inum 198 0(offsite)# find . -inum 199 0(offsite)# pwd /tank1/argus-data 0(offsite)# ---Mike From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 07:42:15 2011 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 3DEAC1065674 for ; Tue, 1 Feb 2011 07:42:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id C60B08FC27 for ; Tue, 1 Feb 2011 07:42:14 +0000 (UTC) Received: (qmail 21002 invoked by uid 399); 1 Feb 2011 07:42:14 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Feb 2011 07:42:14 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D47B954.3010600@FreeBSD.org> Date: Mon, 31 Jan 2011 23:42:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101212 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin Subject: ext2fs crash in -current (r218056) 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, 01 Feb 2011 07:42:15 -0000 As I've discussed here previously I am using ext2fs in -current as a general-purpose /home directory, which includes my ports tree, and at the time of the crash my WRKDIRPREFIX. I was doing some heavy ports building to re-create my amd64-current system from scratch when the following crash happened (sorry for the fuzzy photo): http://dougbarton.us/ext2fs-crash-dump.jpg http://dougbarton.us/ext2fs-crash-dump.txt Previous to the recent changes in -current I hadn't been experiencing actual crashes, so I can't help think this is related to some of the changes that John has been shepherding in recently. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 1 09:49:26 2011 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 EA05C106564A; Tue, 1 Feb 2011 09:49:26 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D61838FC0C; Tue, 1 Feb 2011 09:49:25 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id EB9C471D08D; Tue, 1 Feb 2011 10:49:23 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.8165] X-CRM114-CacheID: sfid-20110201_10492_5F6B6611 X-CRM114-Status: Good ( pR: 15.8165 ) X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 9551C71D084; Tue, 1 Feb 2011 10:49:23 +0100 (CET) Message-ID: <4D47D723.6000106@fsn.hu> Date: Tue, 01 Feb 2011 10:49:23 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Kostik Belousov References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> <20110130110918.GR2518@deviant.kiev.zoral.com.ua> In-Reply-To: <20110130110918.GR2518@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? 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, 01 Feb 2011 09:49:27 -0000 On 01/30/11 12:09, Kostik Belousov wrote: > On Wed, Jan 19, 2011 at 05:27:38PM +0100, Ivan Voras wrote: >> On 19 January 2011 16:02, Kostik Belousov wrote: >> >>>> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch >>>> >>>> I don't think this is a complete solution but it's a start. If you can, >>>> try it and see if it helps. >>> This is not a start, and actually a step in the wrong direction. >>> Tmpfs is wrong now, but the patch would make the wrongness even bigger. >>> >>> Issue is that the current tmpfs calculation should not depend on the >>> length of the inactive queue or the amount of free pages. This data only >>> measures the pressure on the pagedaemon, and has absolutely no relation >>> to the amount of data that can be put into anonymous objects before the >>> system comes out of swap. >>> >>> vm_lowmem handler is invoked in two situations: >>> - when KVA cannot satisfy the request for the space allocation; >>> - when pagedaemon have to start the scan. >>> None of the situations has any direct correlation with the fact that >>> tmpfs needs to check, that is "Is there enough swap to keep all my >>> future anonymous memory requests ?". >>> >>> Might be, swap reservation numbers can be useful to the tmpfs reporting. >>> Also might be, tmpfs should reserve the swap explicitely on start, instead >>> of making attempts to guess how much can be allocated at random moment. >> Thank you for your explanation! I'm still not very familiar with VM >> and VFS. Could you also read my report at >> http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html >> ? I'm curious about the fact that there is lots of 'free' memory here >> in the same situation. > This is another ugliness in the dynamic calculation. Your wired is around > 15GB, that is always greater then available swap + free + inactive. > As result, tmpfs_mem_info() always returns 0. > In this situation TMPFS_PAGES_MAX() seems to return negative value, and > then TMPFS_PAGES_AVAIL() clamps at 0. > Well, if nobody can take care of this now, could you please state this in the BUGS section of the tmpfs man page? Thanks, From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 09:54:18 2011 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 367DF106564A for ; Tue, 1 Feb 2011 09:54:18 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD618FC14 for ; Tue, 1 Feb 2011 09:54:17 +0000 (UTC) Received: (qmail 93288 invoked by uid 89); 1 Feb 2011 10:54:15 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 1 Feb 2011 10:54:15 +0100 Message-ID: <4D47D847.8080308@bytecamp.net> Date: Tue, 01 Feb 2011 10:54:15 +0100 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR in dirhash 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, 01 Feb 2011 09:54:18 -0000 We are currently having continuous problems with 8-STABLE. Since we upgraded, we have "double faults" every three days or so, yesterday we built a debugging kernel to identify the problem. Today I saw a LOR in /var/log/messages, the whole output: 8<---------------------------------------------------------- lock order reversal: 1st 0xffffff81ef08ce98 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2636 2nd 0xffffff00157b4600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d3 _sx_xlock() at _sx_xlock+0x4a ufsdirhash_acquire() at ufsdirhash_acquire+0x3a ufsdirhash_add() at ufsdirhash_add+0x19 ufs_diren ter() at ufs_direnter+0x876 ufs_makeinode() at ufs_makeinode+0x239 VOP_CREATE_APV() at VOP_CREATE_APV+0xb6 vn_open_cred() at vn_open_cred+0x415 kern_openat() at kern_openat+0x165 syscallenter() at syscallenter+0xe5 syscall() at syscall+0x55 Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (5, FreeBSD ELF64 , open) , rip = 0x8009 a4a7c, rsp = 0x 7ffffff e918, r bp = 0x1 --- 8<---------------------------------------------------------- maybe this is a seriuos one? with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 11:17:57 2011 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 2A1D9106564A for ; Tue, 1 Feb 2011 11:17:57 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id AF7CB8FC1C for ; Tue, 1 Feb 2011 11:17:56 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id CAF1B139977; Tue, 1 Feb 2011 12:17:55 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AGOTCtC1xHw9; Tue, 1 Feb 2011 12:17:53 +0100 (CET) Received: from [10.9.8.3] (chello085216231078.chello.sk [85.216.231.78]) by mail.vx.sk (Postfix) with ESMTPSA id 6AD66139965; Tue, 1 Feb 2011 12:17:53 +0100 (CET) Message-ID: <4D47EBE0.8090208@FreeBSD.org> Date: Tue, 01 Feb 2011 12:17:52 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Artem Belevich References: <4D443407.7010604@FreeBSD.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090109010904010807040702" Cc: freebsd-fs Subject: Re: ZFS: clock_t overflow in l2arc_feed_thread 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, 01 Feb 2011 11:17:57 -0000 This is a multi-part message in MIME format. --------------090109010904010807040702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Please try the attached patch. Thanks, mm Dňa 29.01.2011 20:06, Artem Belevich wrote / napísal(a): > On Sat, Jan 29, 2011 at 7:36 AM, Martin Matuska wrote: >> I agree to you that we have different types and this may be an issue but >> I disagree to your patch. >> clock_t is not signed (int64_t) and this can be done in a much easier >> (and cleaner way) without touching the code, see attached patch. > I like the minimalism of your patch. > > It should fix the overflow on LP64, but it would still be there on > i386. To avoid this particular problem we need int64_t even on 32-bit > platforms. Either that, or we should change the way we emulate > solaris' LBOLT in FreeBSD. > > Another concern I have is with this patch we'll end up with parts of > kernel compiled with 32-bit clock_t and other parts build with 64-bit > clock_t. If someone passes a pointer to clock_t between these two > classes of code, we'll have a problem. > > --Artem --------------090109010904010807040702 Content-Type: text/x-patch; name="zfs_clock_t.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zfs_clock_t.patch" Index: sys/cddl/compat/opensolaris/sys/types.h =================================================================== --- sys/cddl/compat/opensolaris/sys/types.h (revision 218166) +++ sys/cddl/compat/opensolaris/sys/types.h (working copy) @@ -34,6 +34,10 @@ */ #include + +typedef int64_t clock_t; +#define _CLOCK_T_DECLARED + #include_next #define MAXNAMELEN 256 --------------090109010904010807040702-- From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 14:53:12 2011 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 CAEA5106566C; Tue, 1 Feb 2011 14:53:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88BE68FC08; Tue, 1 Feb 2011 14:53:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2797A46B2E; Tue, 1 Feb 2011 09:53:12 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 437638A02A; Tue, 1 Feb 2011 09:53:11 -0500 (EST) From: John Baldwin To: Doug Barton Date: Tue, 1 Feb 2011 08:41:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D47B954.3010600@FreeBSD.org> In-Reply-To: <4D47B954.3010600@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102010841.14967.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:11 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 01 Feb 2011 14:53:13 -0000 On Tuesday, February 01, 2011 2:42:12 am Doug Barton wrote: > As I've discussed here previously I am using ext2fs in -current as a > general-purpose /home directory, which includes my ports tree, and at > the time of the crash my WRKDIRPREFIX. I was doing some heavy ports > building to re-create my amd64-current system from scratch when the > following crash happened (sorry for the fuzzy photo): > > http://dougbarton.us/ext2fs-crash-dump.jpg > http://dougbarton.us/ext2fs-crash-dump.txt > > Previous to the recent changes in -current I hadn't been experiencing > actual crashes, so I can't help think this is related to some of the > changes that John has been shepherding in recently. All of the changes so far have been cosmetic, not functional. However, it seems to me that the ext2 code is rife with locking races that could explain this, and that this is just one of them. I can take a look at the locking, but here is an example from this routine of how it is wrong: /* * Determine whether an inode can be allocated. * * Check to see if an inode is available, and if it is, * allocate it using tode in the specified cylinder group. */ static daddr_t ext2_nodealloccg(struct inode *ip, int cg, daddr_t ipref, int mode) { struct m_ext2fs *fs; struct buf *bp; struct ext2mount *ump; int error, start, len, loc, map, i; char *ibp; ipref--; /* to avoid a lot of (ipref -1) */ if (ipref == -1) ipref = 0; fs = ip->i_e2fs; ump = ip->i_ump; if (fs->e2fs_gd[cg].ext2bgd_nifree == 0) return (0); EXT2_UNLOCK(ump); error = bread(ip->i_devvp, fsbtodb(fs, fs->e2fs_gd[cg].ext2bgd_i_bitmap), (int)fs->e2fs_bsize, NOCRED, &bp); if (error) { brelse(bp); EXT2_LOCK(ump); return (0); } ibp = (char *)bp->b_data; if (ipref) { ipref %= fs->e2fs->e2fs_ipg; if (isclr(ibp, ipref)) goto gotit; } start = ipref / NBBY; len = howmany(fs->e2fs->e2fs_ipg - ipref, NBBY); loc = skpc(0xff, len, &ibp[start]); if (loc == 0) { len = start + 1; start = 0; loc = skpc(0xff, len, &ibp[0]); if (loc == 0) { printf("cg = %d, ipref = %lld, fs = %s\n", cg, (long long)ipref, fs->e2fs_fsmnt); panic("ext2fs_nodealloccg: map corrupted"); /* NOTREACHED */ } } i = start + len - loc; map = ibp[i]; ipref = i * NBBY; for (i = 1; i < (1 << NBBY); i <<= 1, ipref++) { if ((map & i) == 0) { goto gotit; } } printf("fs = %s\n", fs->e2fs_fsmnt); panic("ext2fs_nodealloccg: block not in map"); /* NOTREACHED */ gotit: setbit(ibp, ipref); EXT2_LOCK(ump); fs->e2fs_gd[cg].ext2bgd_nifree--; fs->e2fs->e2fs_ficount--; fs->e2fs_fmod = 1; if ((mode & IFMT) == IFDIR) { fs->e2fs_gd[cg].ext2bgd_ndirs++; fs->e2fs_total_dir++; } EXT2_UNLOCK(ump); bdwrite(bp); return (cg * fs->e2fs->e2fs_ipg + ipref +1); } Note that we don't hold any locks while we scan for a free i-node. Two concurrent attempts to allocate an i-node could be running when there is only one i-node available. The first one could then grab that free i-node and the second thread would find a full bitmap. I think the simplest solution is to lock the ump far earlier after the bread() returns and to recheck nifree at that time. It may be that having the buffer locked makes this race occur less often, but it could still be the case even then that we would need to recheck nifree after the bread() returns. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 14:53:16 2011 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 0F0731065748 for ; Tue, 1 Feb 2011 14:53:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C011F8FC1A for ; Tue, 1 Feb 2011 14:53:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 590F346B03; Tue, 1 Feb 2011 09:53:15 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4F3778A027; Tue, 1 Feb 2011 09:53:14 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 1 Feb 2011 09:46:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D47D847.8080308@bytecamp.net> In-Reply-To: <4D47D847.8080308@bytecamp.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201102010946.16466.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 09:53:14 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: LOR in dirhash 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, 01 Feb 2011 14:53:16 -0000 On Tuesday, February 01, 2011 4:54:15 am Robert Schulze wrote: > We are currently having continuous problems with 8-STABLE. > Since we upgraded, we have "double faults" every three days or so,=20 > yesterday we built a debugging kernel to identify the problem. >=20 > Today I saw a LOR in /var/log/messages, the whole output: >=20 > 8<---------------------------------------------------------- >=20 > lock order reversal: > 1st 0xffffff81ef08ce98 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:26= 36 > 2nd 0xffffff00157b4600 dirhash (dirhash) @=20 > /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7d3 > _sx_xlock() at _sx_xlock+0x4a > ufsdirhash_acquire() at ufsdirhash_acquire+0x3a > ufsdirhash_add() at > ufsdirhash_add+0x19 > ufs_diren > ter() at > ufs_direnter+0x876 > ufs_makeinode() at > ufs_makeinode+0x239 > VOP_CREATE_APV() at > VOP_CREATE_APV+0xb6 > vn_open_cred() at vn_open_cred+0x415 > kern_openat() at > kern_openat+0x165 > syscallenter() at syscallenter+0xe5 > syscall() at > syscall+0x55 > Xfast_syscall() at > Xfast_syscall+0xe2 > --- syscall (5, FreeBSD ELF64 > , open) > , rip =3D > 0x8009 > a4a7c, > rsp =3D 0x > 7ffffff > e918, r > bp =3D 0x1 --- >=20 > 8<---------------------------------------------------------- >=20 > maybe this is a seriuos one? =46rom the source code in ufs_dirhash.c: /* * Locking: * * The relationship between inode and dirhash is protected either by an * exclusive vnode lock or the vnode interlock where a shared vnode lock * may be used. The dirhash_mtx is acquired after the dirhash lock. To * handle teardown races, code wishing to lock the dirhash for an inode * when using a shared vnode lock must obtain a private reference on the * dirhash while holding the vnode interlock. They can drop it once they * have obtained the dirhash lock and verified that the dirhash wasn't * recycled while they waited for the dirhash lock. * * ufsdirhash_build() acquires a shared lock on the dirhash when it is * successful. This lock is released after a call to ufsdirhash_lookup(). * * Functions requiring exclusive access use ufsdirhash_acquire() which may * free a dirhash structure that was recycled by ufsdirhash_recycle(). * * The dirhash lock may be held across io operations. * * WITNESS reports a lock order reversal between the "bufwait" lock * and the "dirhash" lock. However, this specific reversal will not * cause a deadlock. To get a deadlock, one would have to lock a * buffer followed by the dirhash while a second thread locked a * buffer while holding the dirhash lock. The second order can happen * under a shared or exclusive vnode lock for the associated directory * in lookup(). The first order, however, can only happen under an * exclusive vnode lock (e.g. unlink(), rename(), etc.). Thus, for * a thread to be doing a "bufwait" -> "dirhash" order, it has to hold * an exclusive vnode lock. That exclusive vnode lock will prevent * any other threads from doing a "dirhash" -> "bufwait" order. */ =2D-=20 John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 15:17:59 2011 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 91D811065695 for ; Tue, 1 Feb 2011 15:17:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 308638FC24 for ; Tue, 1 Feb 2011 15:17:59 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p11FHrVr005603 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 10:17:53 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D48241B.2040807@sentex.net> Date: Tue, 01 Feb 2011 10:17:47 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Vande More , freebsd-fs@freebsd.org References: <4D43475D.5050008@sentex.net> <4D44D775.50507@jrv.org> <4D470A65.4050000@sentex.net> <4D471729.3050804@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: Subject: Re: ZFS help! (solved) 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, 01 Feb 2011 15:17:59 -0000 On 1/31/2011 3:32 PM, Adam Vande More wrote: >> > > maybe the meta data stuff is stored above it in /tank1/? I don't know. I'm > pretty sure you can use a newer version of ZFS to rewind the transaction > groups until you get back to a good state, but there's probably a lot in > this scenario that would prevent that from being a viable solution. If you > do get it resolved please post the resolution. OK, to summarize what happened for the archives. This is RELENG_8 (from end of Jan, on AMD64, 8G of RAM) On my DR backup server that has backups of backups, I decided to expand an existing pool. I added a new eSata cage with integrated PM 2011-01-28.11:45:43 zpool add tank1 raidz /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 0(offsite)# camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus0 target 1 lun 0 (pass1,ada1) at scbus0 target 2 lun 0 (pass2,ada2) at scbus0 target 3 lun 0 (pass3,ada3) at scbus0 target 15 lun 0 (pass4,pmp0) at scbus1 target 0 lun 0 (pass5,ada4) at scbus1 target 1 lun 0 (pass6,ada5) at scbus1 target 2 lun 0 (pass7,ada6) at scbus1 target 3 lun 0 (pass8,ada7) at scbus1 target 4 lun 0 (pass9,ada8) at scbus1 target 15 lun 0 (pass10,pmp1) 0(offsite)# Controller is an Sil3134 (siis and ahci drivers) Shortly after bringing the new sets of drives online, the drive cage failed and started to present the drives in some odd way where the label on the drives was no longer there. # zdb -l /dev/ada0 -------------------------------------------- LABEL 0 -------------------------------------------- failed to unpack label 0 -------------------------------------------- LABEL 1 -------------------------------------------- failed to unpack label 1 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 # zpool status -v pool: tank1 state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 UNAVAIL 0 0 0 insufficient replicas raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 raidz1 UNAVAIL 0 0 0 insufficient replicas ada0 UNAVAIL 0 0 0 cannot open ada1 UNAVAIL 0 0 0 cannot open ada2 UNAVAIL 0 0 0 cannot open ada3 UNAVAIL 0 0 0 cannot open Pulling the drives out and putting them in a new drive cage allowed me to see the file system as being online, albeit with errors. Next steps were to delete the 2 problem files On bootup, it looked like zpool status -v pool: tank1 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 scrub: none requested config: NAME STATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada6 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: /tank1/argus-data/previous/argus-sites-radium.2011.01.28.16.00 tank1/argus-data:<0xc6> /tank1/argus-data/argus-sites-radium Killed those files via rm, and then zpool status -v shows errors: Permanent errors have been detected in the following files: tank1/argus-data:<0xc5> tank1/argus-data:<0xc6> tank1/argus-data:<0xc7> So started a scrub and once it was done, no errors and all is clean! 0(offsite)# zpool status pool: tank1 state: ONLINE scrub: scrub completed after 7h32m with 0 errors on Mon Jan 31 23:00:46 2011 config: NAME STATE READ WRITE CKSUM tank1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad0 ONLINE 0 0 0 ad1 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ada5 ONLINE 0 0 0 ada8 ONLINE 0 0 0 ada7 ONLINE 0 0 0 ada6 ONLINE 0 0 0 errors: No known data errors 0(offsite)# ---Mike From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 17:02:22 2011 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 E479C106564A for ; Tue, 1 Feb 2011 17:02:21 +0000 (UTC) (envelope-from luke@digital-crocus.com) Received: from mail.digital-crocus.com (node2.digital-crocus.com [91.209.244.128]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB388FC24 for ; Tue, 1 Feb 2011 17:02:21 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dkselector; d=hybrid-logic.co.uk; h=Received:Received:Subject:From:Reply-To:To:Content-Type:Organization:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Spam-Score:X-Digital-Crocus-Maillimit:X-Authenticated-Sender:X-Complaints:X-Admin:X-Abuse; b=J2b1M95XaBobN4/u4xOr8sQki6bVGX0nVp5YCvEAPUEMNWIQe4tqm/yaBuAvS8hiCpjxG7eZCC3KRuN8iqXTth282Z6lRLYpJ80qGEOdI+Qo2FwzM9kzvu+loysf4mAI; Received: from luke by mail.digital-crocus.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PkJ5F-0002E6-Tb for freebsd-fs@freebsd.org; Tue, 01 Feb 2011 16:28:01 +0000 Received: from c-76-118-178-109.hsd1.ma.comcast.net ([76.118.178.109] helo=[192.168.1.51]) by mail.digital-crocus.com with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PkJ5E-0002DK-Ko; Tue, 01 Feb 2011 16:28:01 +0000 From: Luke Marsden To: freebsd-stable@freebsd.org, freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Content-Type: text/plain; charset="UTF-8" Organization: Hybrid Web Cluster Date: Tue, 01 Feb 2011 11:27:59 -0500 Message-ID: <1296577679.2222.21.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Digital-Crocus-Maillimit: done X-Authenticated-Sender: luke X-Complaints: abuse@digital-crocus.com X-Admin: admin@digital-crocus.com X-Abuse: abuse@digital-crocus.com (Please include full headers in abuse reports) Cc: Subject: ZFS hanging with simultaneous "zfs recv" and "zfs umount -f" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: luke@hybrid-logic.co.uk List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:02:22 -0000 Hi FreeBSD-{stable,current,fs}, I've reliably been able to cause the ZFS subsystem to hang under FreeBSD 8.1-RELEASE under the following conditions: Another server is sending the server an incremental snapshot stream which is in the process of being received with: zfs send -I $OLD $FS@$NEW |ssh $HOST zfs recv -uF $FILESYSTEM On the receiving server, we forcibly unmount the filesystem which is being received into with: zfs umount -f $FILESYSTEM (the filesystem may or may not actually be mounted) This causes any ZFS file operation (such as "ls") to hang forever and when attempting to reboot the machine, it goes down and stops responding to pings, but then hangs somewhere in the reboot process and needs a hard power cycle. Unfortunately we don't have a remote console on this machine. I understand this is a fairly harsh use case but the ideal behaviour would be for the zfs recv to emit an error message (if necessary) rather than rendering the entire machine unusable ;-) Let me know if you need any further information. I appreciate that providing a script to reliably reproduce the problem, testing on -CURRENT and 8.2-PRE, and submitting a bug report will help... I will do this in due course, but don't have time right now -- just wanted to get this bug report out there first in case there's an obvious fix. Thank you for supporting ZFS on FreeBSD!! -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting Phone: +441172232002 / +16179496062 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 17:09:59 2011 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 BCBD01065695 for ; Tue, 1 Feb 2011 17:09:59 +0000 (UTC) (envelope-from luke@digital-crocus.com) Received: from mail.digital-crocus.com (node2.digital-crocus.com [91.209.244.128]) by mx1.freebsd.org (Postfix) with ESMTP id 727258FC19 for ; Tue, 1 Feb 2011 17:09:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dkselector; d=hybrid-logic.co.uk; h=Received:Received:Subject:From:To:Cc:Content-Type:Organization:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Spam-Score:X-Digital-Crocus-Maillimit:X-Authenticated-Sender:X-Complaints:X-Admin:X-Abuse; b=hoAI2D3ZUGJxQQzdH9BQbC1jLDl3raGXQHolRbv9SeKOLVSM+S7gKm1EtmKQSybY7sYieI6ZG0Reezru+8HKMN8NDFBZjVLyTNld25E46mFUR1gvkCvIhCFh6quBlawy; Received: from luke by mail.digital-crocus.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PkJ4g-0002Am-Ix for freebsd-fs@freebsd.org; Tue, 01 Feb 2011 16:27:26 +0000 Received: from c-76-118-178-109.hsd1.ma.comcast.net ([76.118.178.109] helo=[192.168.1.51]) by mail.digital-crocus.com with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1PkJ4g-0002AX-68; Tue, 01 Feb 2011 16:27:26 +0000 From: Luke Marsden To: freebsd-stable@freebsd.org, freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Content-Type: text/plain; charset="UTF-8" Organization: Hybrid Logic Date: Tue, 01 Feb 2011 11:27:24 -0500 Message-ID: <1296577644.2222.20.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Digital-Crocus-Maillimit: done X-Authenticated-Sender: luke X-Complaints: abuse@digital-crocus.com X-Admin: admin@digital-crocus.com X-Abuse: abuse@digital-crocus.com (Please include full headers in abuse reports) Cc: tech@hybrid-logic.co.uk, Pawel Jakub Dawidek Subject: ZFS hanging with simultaneous "zfs recv" and "zfs 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, 01 Feb 2011 17:09:59 -0000 Hi FreeBSD-{stable,current,fs}, I've reliably been able to cause the ZFS subsystem to hang under FreeBSD 8.1-RELEASE under the following conditions: Another server is sending the server an incremental snapshot stream which is in the process of being received with: zfs send -I $OLD $FS@$NEW |ssh $HOST zfs recv -uF $FILESYSTEM On the receiving server, we forcibly unmount the filesystem which is being received into with: zfs umount -f $FILESYSTEM (the filesystem may or may not actually be mounted) This causes any ZFS file operation (such as "ls") to hang forever and when attempting to reboot the machine, it goes down and stops responding to pings, but then hangs somewhere in the reboot process and needs a hard power cycle. Unfortunately we don't have a remote console on this machine. I understand this is a fairly harsh use case but the ideal behaviour would be for the zfs recv to emit an error message (if necessary) rather than rendering the entire machine unusable ;-) Let me know if you need any further information. I appreciate that providing a script to reliably reproduce the problem, testing on -CURRENT and 8.2-PRE, and submitting a bug report will help... I will do this in due course, but don't have time right now -- just wanted to get this bug report out there first in case there's an obvious fix. Thank you for supporting ZFS on FreeBSD!! -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting Phone: +441172232002 / +16179496062 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 18:30:11 2011 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 854451065670 for ; Tue, 1 Feb 2011 18:30:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 595A48FC13 for ; Tue, 1 Feb 2011 18:30:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p11IUBlK043778 for ; Tue, 1 Feb 2011 18:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p11IUBeC043774; Tue, 1 Feb 2011 18:30:11 GMT (envelope-from gnats) Date: Tue, 1 Feb 2011 18:30:11 GMT Message-Id: <201102011830.p11IUBeC043774@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/153584: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:30:11 -0000 The following reply was made to PR kern/153584; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/153584: commit references a PR Date: Tue, 1 Feb 2011 18:21:52 +0000 (UTC) Author: jhb Date: Tue Feb 1 18:21:45 2011 New Revision: 218175 URL: http://svn.freebsd.org/changeset/base/218175 Log: - Set the next_alloc fields for an i-node after allocating a new block so that future allocations start with most recently allocated block rather than the beginning of the filesystem. - Fix ext2_alloccg() to properly scan for 8 block chunks that are not aligned on 8-bit boundaries. Previously this was causing new blocks to be allocated in a highly fragmented fashion (block 0 of a file at lbn N, block 1 at lbn N + 8, block 2 at lbn N + 16, etc.). - Cosmetic tweaks to the currently-disabled fancy realloc sysctls. PR: kern/153584 Discussed with: bde Tested by: Pedro F. Giffuni giffunip at yahoo, Zheng Liu (lz) Modified: head/sys/fs/ext2fs/ext2_alloc.c Modified: head/sys/fs/ext2fs/ext2_alloc.c ============================================================================== --- head/sys/fs/ext2fs/ext2_alloc.c Tue Feb 1 17:42:57 2011 (r218174) +++ head/sys/fs/ext2fs/ext2_alloc.c Tue Feb 1 18:21:45 2011 (r218175) @@ -59,6 +59,10 @@ static u_long ext2_hashalloc(struct inod int)); static daddr_t ext2_nodealloccg(struct inode *, int, daddr_t, int); static daddr_t ext2_mapsearch(struct m_ext2fs *, char *, daddr_t); +#ifdef FANCY_REALLOC +static int ext2_reallocblks(struct vop_reallocblks_args *); +#endif + /* * Allocate a block in the file system. * @@ -108,13 +112,17 @@ ext2_alloc(ip, lbn, bpref, size, cred, b goto nospace; if (bpref >= fs->e2fs->e2fs_bcount) bpref = 0; - if (bpref == 0) + if (bpref == 0) cg = ino_to_cg(fs, ip->i_number); else cg = dtog(fs, bpref); bno = (daddr_t)ext2_hashalloc(ip, cg, bpref, fs->e2fs_bsize, ext2_alloccg); if (bno > 0) { + /* set next_alloc fields as done in block_getblk */ + ip->i_next_alloc_block = lbn; + ip->i_next_alloc_goal = bno; + ip->i_blocks += btodb(fs->e2fs_bsize); ip->i_flag |= IN_CHANGE | IN_UPDATE; *bnp = bno; @@ -143,13 +151,14 @@ nospace: */ #ifdef FANCY_REALLOC -#include +SYSCTL_NODE(_vfs, OID_AUTO, ext2fs, CTLFLAG_RW, 0, "EXT2FS filesystem"); + static int doasyncfree = 1; -static int doreallocblks = 1; +SYSCTL_INT(_vfs_ext2fs, OID_AUTO, doasyncfree, CTLFLAG_RW, &doasyncfree, 0, + "Use asychronous writes to update block pointers when freeing blocks"); -#ifdef OPT_DEBUG -SYSCTL_INT(_debug, 14, doasyncfree, CTLFLAG_RW, &doasyncfree, 0, ""); -#endif /* OPT_DEBUG */ +static int doreallocblks = 1; +SYSCTL_INT(_vfs_ext2fs, OID_AUTO, doreallocblks, CTLFLAG_RW, &doreallocblks, 0, ""); #endif int @@ -624,7 +633,8 @@ ext2_alloccg(struct inode *ip, int cg, d struct m_ext2fs *fs; struct buf *bp; struct ext2mount *ump; - int error, bno, start, end, loc; + daddr_t bno, runstart, runlen; + int bit, loc, end, error, start; char *bbp; /* XXX ondisk32 */ fs = ip->i_e2fs; @@ -665,18 +675,52 @@ ext2_alloccg(struct inode *ip, int cg, d else start = 0; end = howmany(fs->e2fs->e2fs_fpg, NBBY) - start; +retry: + runlen = 0; + runstart = 0; for (loc = start; loc < end; loc++) { - if (bbp[loc] == 0) { - bno = loc * NBBY; - goto gotit; + if (bbp[loc] == (char)0xff) { + runlen = 0; + continue; } - } - for (loc = 0; loc < start; loc++) { - if (bbp[loc] == 0) { - bno = loc * NBBY; + + /* Start of a run, find the number of high clear bits. */ + if (runlen == 0) { + bit = fls(bbp[loc]); + runlen = NBBY - bit; + runstart = loc * NBBY + bit; + } else if (bbp[loc] == 0) { + /* Continue a run. */ + runlen += NBBY; + } else { + /* + * Finish the current run. If it isn't long + * enough, start a new one. + */ + bit = ffs(bbp[loc]) - 1; + runlen += bit; + if (runlen >= 8) { + bno = runstart; + goto gotit; + } + + /* Run was too short, start a new one. */ + bit = fls(bbp[loc]); + runlen = NBBY - bit; + runstart = loc * NBBY + bit; + } + + /* If the current run is long enough, use it. */ + if (runlen >= 8) { + bno = runstart; goto gotit; } } + if (start != 0) { + end = start; + start = 0; + goto retry; + } bno = ext2_mapsearch(fs, bbp, bpref); if (bno < 0){ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 18:53:01 2011 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 24CD8106564A; Tue, 1 Feb 2011 18:53:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB84D8FC14; Tue, 1 Feb 2011 18:53:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A666946B06; Tue, 1 Feb 2011 13:53:00 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8DA98A027; Tue, 1 Feb 2011 13:52:59 -0500 (EST) From: John Baldwin To: Doug Barton Date: Tue, 1 Feb 2011 13:52:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D47B954.3010600@FreeBSD.org> In-Reply-To: <4D47B954.3010600@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102011352.57998.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 01 Feb 2011 13:52:59 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 01 Feb 2011 18:53:01 -0000 On Tuesday, February 01, 2011 2:42:12 am Doug Barton wrote: > As I've discussed here previously I am using ext2fs in -current as a > general-purpose /home directory, which includes my ports tree, and at > the time of the crash my WRKDIRPREFIX. I was doing some heavy ports > building to re-create my amd64-current system from scratch when the > following crash happened (sorry for the fuzzy photo): > > http://dougbarton.us/ext2fs-crash-dump.jpg > http://dougbarton.us/ext2fs-crash-dump.txt > > Previous to the recent changes in -current I hadn't been experiencing > actual crashes, so I can't help think this is related to some of the > changes that John has been shepherding in recently. Please try this: Index: ext2_alloc.c =================================================================== --- ext2_alloc.c (revision 218175) +++ ext2_alloc.c (working copy) @@ -650,6 +650,18 @@ EXT2_LOCK(ump); return (0); } + EXT2_LOCK(ump); + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { + /* + * Another thread allocated the last block in this + * group while we were waiting for the buffer. + */ + EXT2_UNLOCK(ump); + brelse(bp); + EXT2_LOCK(ump); + return (0); + } + EXT2_UNLOCK(ump); bbp = (char *)bp->b_data; if (dtog(fs, bpref) != cg) @@ -776,6 +788,18 @@ EXT2_LOCK(ump); return (0); } + EXT2_LOCK(ump); + if (fs->e2fs_gd[cg].ext2bgd_nifree == 0) { + /* + * Another thread allocated the last i-node in this + * group while we were waiting for the buffer. + */ + EXT2_UNLOCK(ump); + brelse(bp); + EXT2_LOCK(ump); + return (0); + } + EXT2_UNLOCK(ump); ibp = (char *)bp->b_data; if (ipref) { ipref %= fs->e2fs->e2fs_ipg; -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 19:38:08 2011 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 BC9ED10656D9; Tue, 1 Feb 2011 19:38:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 948918FC15; Tue, 1 Feb 2011 19:38:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p11Jc8N3018125; Tue, 1 Feb 2011 19:38:08 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p11Jc8b5018121; Tue, 1 Feb 2011 19:38:08 GMT (envelope-from jhb) Date: Tue, 1 Feb 2011 19:38:08 GMT Message-Id: <201102011938.p11Jc8b5018121@freefall.freebsd.org> To: giffunip@tutopia.com, jhb@FreeBSD.org, freebsd-fs@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/153584: [ext2fs] [patch] Performance fix and cleanups for BSD licensed ext2fs 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, 01 Feb 2011 19:38:08 -0000 Synopsis: [ext2fs] [patch] Performance fix and cleanups for BSD licensed ext2fs State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Tue Feb 1 19:37:42 UTC 2011 State-Changed-Why: Various patches applied to HEAD. Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=153584 From owner-freebsd-fs@FreeBSD.ORG Tue Feb 1 21:11:02 2011 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 9145F106567A for ; Tue, 1 Feb 2011 21:11:02 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25DC88FC17 for ; Tue, 1 Feb 2011 21:11:02 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id F24AD153448; Tue, 1 Feb 2011 22:11:00 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0FPu83vge63; Tue, 1 Feb 2011 22:10:58 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:213a:f7be:d24f:3631] (unknown [IPv6:2001:4cb8:3:1:213a:f7be:d24f:3631]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 40CEA153447; Tue, 1 Feb 2011 22:10:58 +0100 (CET) Message-ID: <4D4876E3.8050703@digiware.nl> Date: Tue, 01 Feb 2011 22:10:59 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <20110130143045.GA50566@icarus.home.lan> <4D457AB1.90109@digiware.nl> <20110130150226.GA51190@icarus.home.lan> <4D45BCE2.1020508@digiware.nl> In-Reply-To: <4D45BCE2.1020508@digiware.nl> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fs@freebsd.org Subject: Re: Errors booting of the ZFS alternative mirror disk 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, 01 Feb 2011 21:11:02 -0000 On 30-1-2011 20:32, Willem Jan Withagen wrote: > On 30-1-2011 16:02, Jeremy Chadwick wrote: >>>> uname -a output please. >>>> >>> FreeBSD big.medusa.nl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Sat Jan >>> 29 22:11:44 CET 2011 wjw@big.medusa.nl:/usr/obj/usr/src/sys/BIG amd64 >>> >>> Haven't tested it with this version though, but only with the build I >>> did on 22 Jan, and then it didn't work. >> >> Thanks. The reason I asked for this was that there were some changes to >> the ZFS bootloader which may have addressed your problem, but those >> would have been before January 29th. Well, found some time made world and redid the hole on the second disk. And added it again in the mirror. That rebuild, then tried to reboot from the second disk.... And low and behold, it now works. My guess: Pilot error. So once more ZFS has shown that it requires a ver precise instalation. --WjW From owner-freebsd-fs@FreeBSD.ORG Wed Feb 2 00:37:45 2011 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 D23A91065670 for ; Wed, 2 Feb 2011 00:37:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8868FC24 for ; Wed, 2 Feb 2011 00:37:45 +0000 (UTC) Received: (qmail 21344 invoked by uid 399); 2 Feb 2011 00:37:43 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Feb 2011 00:37:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D48A756.4080002@FreeBSD.org> Date: Tue, 01 Feb 2011 16:37:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D47B954.3010600@FreeBSD.org> <201102011352.57998.jhb@freebsd.org> In-Reply-To: <201102011352.57998.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 02 Feb 2011 00:37:45 -0000 On 02/01/2011 10:52, John Baldwin wrote: > On Tuesday, February 01, 2011 2:42:12 am Doug Barton wrote: >> As I've discussed here previously I am using ext2fs in -current as a >> general-purpose /home directory, which includes my ports tree, and at >> the time of the crash my WRKDIRPREFIX. I was doing some heavy ports >> building to re-create my amd64-current system from scratch when the >> following crash happened (sorry for the fuzzy photo): >> >> http://dougbarton.us/ext2fs-crash-dump.jpg >> http://dougbarton.us/ext2fs-crash-dump.txt >> >> Previous to the recent changes in -current I hadn't been experiencing >> actual crashes, so I can't help think this is related to some of the >> changes that John has been shepherding in recently. > > Please try this: Thanks John. The patch compiles and runs just fine (against an otherwise-stock r218178) so I'll first run it with "normal" load during working hours, then I'll stress test it. I think your analysis is correct given that the problem went away when I moved WRKDIRPREFIX to a UFS partition on a different disk. That made the ports tree on the ext2fs partition basically read-only so it eliminated the potential for inode contention. On that same system I built world from scratch today, but with the same scenario (src on ext2fs, obj on UFS) at -j2 without any problems. I'll get back to you after I stress the system tonight. Thanks again for jumping on this so quickly. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Wed Feb 2 02:11:42 2011 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 AB2D2106566B; Wed, 2 Feb 2011 02:11:42 +0000 (UTC) (envelope-from sarawgi.aditya@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6484E8FC14; Wed, 2 Feb 2011 02:11:42 +0000 (UTC) Received: by iwn39 with SMTP id 39so7300667iwn.13 for ; Tue, 01 Feb 2011 18:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=zOrhvTXkz7Ycygi4/e3TjHJgLbhZ7d9HYHbpBPzrUKk=; b=l3Cn+R7nqvL5kQoS+YVnTUm+Xe3+mTn7u1cVIMQLv3CA8uVoK5wk2BCx7+0avgmVx7 8nt9qStUPxOz807XIEXUL2wnyznG3rmluL8zot6FLA4Xer4n6hGr9lz7pkLKj5cVRTjm 8xZ+BYLzEeWRs7XsZAWC7AUoQXO2Xje83Orl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BS/IQ7iM9wCg2ewoWIqkrmmzeE4TeZAHglGYC8UOIL28iC71i3pbJu/LJpQgm+YfQE xzFPokFl3Dby5AGsqVQKCguFo05n7ocTUeqPId8UBzcNG+5mDVmOvCI1Hz7IgwNFP6Mb +jxdQ/eRuKPs3zTkAbf8TZGc4+z4yoPCKyMXM= Received: by 10.42.177.129 with SMTP id bi1mr10358586icb.328.1296610872821; Tue, 01 Feb 2011 17:41:12 -0800 (PST) Received: from earth ([27.106.73.42]) by mx.google.com with ESMTPS id d13sm11758183ice.16.2011.02.01.17.41.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 17:41:12 -0800 (PST) Date: Wed, 2 Feb 2011 07:12:55 +0530 From: Aditya Sarawgi To: John Baldwin Message-ID: <20110202014252.GA1574@earth> References: <4D47B954.3010600@FreeBSD.org> <201102011352.57998.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102011352.57998.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 02 Feb 2011 02:11:42 -0000 Hi John, I can see what you are saying. Can't we check the number of free blocks in the given cg without locking the fs. This way EXT2_LOCK(ump); return (0); } + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { + /* + * Another thread allocated the last block in this + * group while we were waiting for the buffer. + */ + brelse(bp); + EXT2_LOCK(ump); + return (0); + } bbp = (char *)bp->b_data; if (dtog(fs, bpref) != cg) UFS is doing something similar static ufs2_daddr_t ffs_alloccg(ip, cg, bpref, size, rsize) struct inode *ip; u_int cg; ufs2_daddr_t bpref; int size; int rsize; { struct fs *fs; struct cg *cgp; struct buf *bp; struct ufsmount *ump; ufs1_daddr_t bno; ufs2_daddr_t blkno; int i, allocsiz, error, frags; u_int8_t *blksfree; ump = ip->i_ump; fs = ip->i_fs; if (fs->fs_cs(fs, cg).cs_nbfree == 0 && size == fs->fs_bsize) return (0); UFS_UNLOCK(ump); error = bread(ip->i_devvp, fsbtodb(fs, cgtod(fs, cg)), (int)fs->fs_cgsize, NOCRED, &bp); if (error) goto fail; cgp = (struct cg *)bp->b_data; if (!cg_chkmagic(cgp) || (cgp->cg_cs.cs_nbfree == 0 && size == fs->fs_bsize)) goto fail; > Please try this: > > Index: ext2_alloc.c > =================================================================== > --- ext2_alloc.c (revision 218175) > +++ ext2_alloc.c (working copy) > @@ -650,6 +650,18 @@ > EXT2_LOCK(ump); > return (0); > } > + EXT2_LOCK(ump); > + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { > + /* > + * Another thread allocated the last block in this > + * group while we were waiting for the buffer. > + */ > + EXT2_UNLOCK(ump); > + brelse(bp); > + EXT2_LOCK(ump); > + return (0); > + } > + EXT2_UNLOCK(ump); > bbp = (char *)bp->b_data; > > if (dtog(fs, bpref) != cg) > @@ -776,6 +788,18 @@ > EXT2_LOCK(ump); > return (0); > } > + EXT2_LOCK(ump); > + if (fs->e2fs_gd[cg].ext2bgd_nifree == 0) { > + /* > + * Another thread allocated the last i-node in this > + * group while we were waiting for the buffer. > + */ > + EXT2_UNLOCK(ump); > + brelse(bp); > + EXT2_LOCK(ump); > + return (0); > + } > + EXT2_UNLOCK(ump); > ibp = (char *)bp->b_data; > if (ipref) { > ipref %= fs->e2fs->e2fs_ipg; -- Aditya Sarawgi From owner-freebsd-fs@FreeBSD.ORG Wed Feb 2 21:13:51 2011 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 CBB0B1065673 for ; Wed, 2 Feb 2011 21:13:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 018AC8FC20 for ; Wed, 2 Feb 2011 21:13:50 +0000 (UTC) Received: (qmail 25819 invoked by uid 399); 2 Feb 2011 21:13:50 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Feb 2011 21:13:50 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D49C90C.2090003@FreeBSD.org> Date: Wed, 02 Feb 2011 13:13:48 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101212 Thunderbird/3.1.7 MIME-Version: 1.0 To: Aditya Sarawgi References: <4D47B954.3010600@FreeBSD.org> <201102011352.57998.jhb@freebsd.org> <20110202014252.GA1574@earth> In-Reply-To: <20110202014252.GA1574@earth> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 02 Feb 2011 21:13:51 -0000 I haven't had a chance to test this patch yet, but John's did not work (sorry): http://dougbarton.us/ext2fs-crash-dump-2.jpg No actual dump this time either. I'm happy to test the patch below on Thursday if there is consensus that it will work. Doug On 02/01/2011 17:42, Aditya Sarawgi wrote: > Hi John, > > I can see what you are saying. Can't we check > the number of free blocks in the given cg without > locking the fs. > This way > > EXT2_LOCK(ump); > return (0); > } > + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { > + /* > + * Another thread allocated the last block in this > + * group while we were waiting for the buffer. > + */ > + brelse(bp); > + EXT2_LOCK(ump); > + return (0); > + } > bbp = (char *)bp->b_data; > > if (dtog(fs, bpref) != cg) > > > UFS is doing something similar > > static ufs2_daddr_t > ffs_alloccg(ip, cg, bpref, size, rsize) > struct inode *ip; > u_int cg; > ufs2_daddr_t bpref; > int size; > int rsize; > { > struct fs *fs; > struct cg *cgp; > struct buf *bp; > struct ufsmount *ump; > ufs1_daddr_t bno; > ufs2_daddr_t blkno; > int i, allocsiz, error, frags; > u_int8_t *blksfree; > > ump = ip->i_ump; > fs = ip->i_fs; > if (fs->fs_cs(fs, cg).cs_nbfree == 0&& size == fs->fs_bsize) > return (0); > UFS_UNLOCK(ump); > error = bread(ip->i_devvp, fsbtodb(fs, cgtod(fs, cg)), > (int)fs->fs_cgsize, NOCRED,&bp); > if (error) > goto fail; > cgp = (struct cg *)bp->b_data; > if (!cg_chkmagic(cgp) || > (cgp->cg_cs.cs_nbfree == 0&& size == fs->fs_bsize)) > goto fail; >> Please try this: >> >> Index: ext2_alloc.c >> =================================================================== >> --- ext2_alloc.c (revision 218175) >> +++ ext2_alloc.c (working copy) >> @@ -650,6 +650,18 @@ >> EXT2_LOCK(ump); >> return (0); >> } >> + EXT2_LOCK(ump); >> + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { >> + /* >> + * Another thread allocated the last block in this >> + * group while we were waiting for the buffer. >> + */ >> + EXT2_UNLOCK(ump); >> + brelse(bp); >> + EXT2_LOCK(ump); >> + return (0); >> + } >> + EXT2_UNLOCK(ump); >> bbp = (char *)bp->b_data; >> >> if (dtog(fs, bpref) != cg) >> @@ -776,6 +788,18 @@ >> EXT2_LOCK(ump); >> return (0); >> } >> + EXT2_LOCK(ump); >> + if (fs->e2fs_gd[cg].ext2bgd_nifree == 0) { >> + /* >> + * Another thread allocated the last i-node in this >> + * group while we were waiting for the buffer. >> + */ >> + EXT2_UNLOCK(ump); >> + brelse(bp); >> + EXT2_LOCK(ump); >> + return (0); >> + } >> + EXT2_UNLOCK(ump); >> ibp = (char *)bp->b_data; >> if (ipref) { >> ipref %= fs->e2fs->e2fs_ipg; > > -- > Aditya Sarawgi > _______________________________________________ > 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" > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Wed Feb 2 22:04:07 2011 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 CD4E810656A8; Wed, 2 Feb 2011 22:04:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3108FC1A; Wed, 2 Feb 2011 22:04:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2C69546B0C; Wed, 2 Feb 2011 17:04:07 -0500 (EST) Received: from kavik.baldwin.cx (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EAFE68A009; Wed, 2 Feb 2011 17:04:05 -0500 (EST) From: John Baldwin To: Doug Barton Date: Wed, 2 Feb 2011 17:04:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-RC1; KDE/4.5.5; i386; ; ) References: <4D47B954.3010600@FreeBSD.org> <20110202014252.GA1574@earth> <4D49C90C.2090003@FreeBSD.org> In-Reply-To: <4D49C90C.2090003@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102021704.04274.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Feb 2011 17:04:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=4.2 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 02 Feb 2011 22:04:08 -0000 On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: > I haven't had a chance to test this patch yet, but John's did not work > (sorry): > > http://dougbarton.us/ext2fs-crash-dump-2.jpg > > No actual dump this time either. > > I'm happy to test the patch below on Thursday if there is consensus that > it will work. Err, this is a different panic than what you reported earlier. Your disk died and spewed a bunch of EIO errors. I can look at the locking assertion failure tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to handle disks dying gracefully. > Doug > > On 02/01/2011 17:42, Aditya Sarawgi wrote: > > Hi John, > > > > I can see what you are saying. Can't we check > > the number of free blocks in the given cg without > > locking the fs. > > This way > > > > EXT2_LOCK(ump); > > return (0); > > > > } > > > > + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { > > + /* > > + * Another thread allocated the last block in this > > + * group while we were waiting for the buffer. > > + */ > > + brelse(bp); > > + EXT2_LOCK(ump); > > + return (0); > > + } > > > > bbp = (char *)bp->b_data; > > > > if (dtog(fs, bpref) != cg) > > > > UFS is doing something similar > > > > static ufs2_daddr_t > > ffs_alloccg(ip, cg, bpref, size, rsize) > > > > struct inode *ip; > > u_int cg; > > ufs2_daddr_t bpref; > > int size; > > int rsize; > > > > { > > > > struct fs *fs; > > struct cg *cgp; > > struct buf *bp; > > struct ufsmount *ump; > > ufs1_daddr_t bno; > > ufs2_daddr_t blkno; > > int i, allocsiz, error, frags; > > u_int8_t *blksfree; > > > > ump = ip->i_ump; > > fs = ip->i_fs; > > if (fs->fs_cs(fs, cg).cs_nbfree == 0&& size == fs->fs_bsize) > > > > return (0); > > > > UFS_UNLOCK(ump); > > error = bread(ip->i_devvp, fsbtodb(fs, cgtod(fs, cg)), > > > > (int)fs->fs_cgsize, NOCRED,&bp); > > > > if (error) > > > > goto fail; > > > > cgp = (struct cg *)bp->b_data; > > if (!cg_chkmagic(cgp) || > > > > (cgp->cg_cs.cs_nbfree == 0&& size == fs->fs_bsize)) > > > > goto fail; > >> > >> Please try this: > >> > >> Index: ext2_alloc.c > >> =================================================================== > >> --- ext2_alloc.c (revision 218175) > >> +++ ext2_alloc.c (working copy) > >> @@ -650,6 +650,18 @@ > >> > >> EXT2_LOCK(ump); > >> return (0); > >> > >> } > >> > >> + EXT2_LOCK(ump); > >> + if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) { > >> + /* > >> + * Another thread allocated the last block in this > >> + * group while we were waiting for the buffer. > >> + */ > >> + EXT2_UNLOCK(ump); > >> + brelse(bp); > >> + EXT2_LOCK(ump); > >> + return (0); > >> + } > >> + EXT2_UNLOCK(ump); > >> > >> bbp = (char *)bp->b_data; > >> > >> if (dtog(fs, bpref) != cg) > >> > >> @@ -776,6 +788,18 @@ > >> > >> EXT2_LOCK(ump); > >> return (0); > >> > >> } > >> > >> + EXT2_LOCK(ump); > >> + if (fs->e2fs_gd[cg].ext2bgd_nifree == 0) { > >> + /* > >> + * Another thread allocated the last i-node in this > >> + * group while we were waiting for the buffer. > >> + */ > >> + EXT2_UNLOCK(ump); > >> + brelse(bp); > >> + EXT2_LOCK(ump); > >> + return (0); > >> + } > >> + EXT2_UNLOCK(ump); > >> > >> ibp = (char *)bp->b_data; > >> if (ipref) { > >> > >> ipref %= fs->e2fs->e2fs_ipg; > > > > -- > > Aditya Sarawgi > > _______________________________________________ > > 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" -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Feb 2 22:20:25 2011 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 429AE106566B for ; Wed, 2 Feb 2011 22:20:25 +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 22DC98FC0A for ; Wed, 2 Feb 2011 22:20:25 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 3A3W1g00B16AWCUADALQUo; Wed, 02 Feb 2011 22:20:24 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta06.emeryville.ca.mail.comcast.net with comcast id 3ALP1g01X2tehsa8SALQr2; Wed, 02 Feb 2011 22:20:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7E6359B427; Wed, 2 Feb 2011 14:20:23 -0800 (PST) Date: Wed, 2 Feb 2011 14:20:23 -0800 From: Jeremy Chadwick To: John Baldwin Message-ID: <20110202222023.GA45401@icarus.home.lan> References: <4D47B954.3010600@FreeBSD.org> <20110202014252.GA1574@earth> <4D49C90C.2090003@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102021704.04274.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 02 Feb 2011 22:20:25 -0000 On Wed, Feb 02, 2011 at 05:04:03PM -0500, John Baldwin wrote: > On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: > > I haven't had a chance to test this patch yet, but John's did not work > > (sorry): > > > > http://dougbarton.us/ext2fs-crash-dump-2.jpg > > > > No actual dump this time either. > > > > I'm happy to test the patch below on Thursday if there is consensus that > > it will work. > > Err, this is a different panic than what you reported earlier. Your disk died > and spewed a bunch of EIO errors. I can look at the locking assertion failure > tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to > handle disks dying gracefully. Are the byte offsets shown in the screenshot within the range of the drive's capacity? They're around the 10.7GB mark, but I have no idea what size disk is being used. The reason I ask is that there have been reported issues in the past where the offsets shown are way outside of the range of the permitted byte offsets of the disk itself (and in some cases even showing a negative number; what is it with people not understanding the difference between signed and unsigned types? Sigh), and I want to make sure this isn't one of those situations. I also don't know if underlying filesystem corruption could cause the problem in question ("filesystem says you should write to block N, which is outside of the permitted range of the device"). Specifically with regards to the I/O errors: I can assist with verifying the disk has a problem, but I forget if smartmontools will work under FreeBSD if the hard disk is attached via umass or not. Doug, if you feel like installing sysutils/smartmontools and providing output from "smartctl -a /dev/da0" -- assuming it works -- I can help you with verifying that. It's not a 100% reliable method, but it's absolutely better than nothing. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 13:57:08 2011 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 A04D51065807; Thu, 3 Feb 2011 13:57:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA38E8FC18; Thu, 3 Feb 2011 13:57:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6541346B17; Thu, 3 Feb 2011 08:57:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75CB18A009; Thu, 3 Feb 2011 08:57:03 -0500 (EST) From: John Baldwin To: Jeremy Chadwick Date: Thu, 3 Feb 2011 07:53:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <20110202222023.GA45401@icarus.home.lan> In-Reply-To: <20110202222023.GA45401@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102030753.55820.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 03 Feb 2011 08:57:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.5 required=4.2 tests=BAYES_00,MAY_BE_FORGED, RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 13:57:08 -0000 On Wednesday, February 02, 2011 5:20:23 pm Jeremy Chadwick wrote: > On Wed, Feb 02, 2011 at 05:04:03PM -0500, John Baldwin wrote: > > On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: > > > I haven't had a chance to test this patch yet, but John's did not work > > > (sorry): > > > > > > http://dougbarton.us/ext2fs-crash-dump-2.jpg > > > > > > No actual dump this time either. > > > > > > I'm happy to test the patch below on Thursday if there is consensus that > > > it will work. > > > > Err, this is a different panic than what you reported earlier. Your disk died > > and spewed a bunch of EIO errors. I can look at the locking assertion failure > > tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to > > handle disks dying gracefully. > > Are the byte offsets shown in the screenshot within the range of the > drive's capacity? They're around the 10.7GB mark, but I have no idea > what size disk is being used. > > The reason I ask is that there have been reported issues in the past > where the offsets shown are way outside of the range of the permitted > byte offsets of the disk itself (and in some cases even showing a > negative number; what is it with people not understanding the difference > between signed and unsigned types? Sigh), and I want to make sure this > isn't one of those situations. I also don't know if underlying > filesystem corruption could cause the problem in question ("filesystem > says you should write to block N, which is outside of the permitted > range of the device"). Just one comment. UFS uses negative block numbers to indicate an indirect block (or some such) as opposed to a direct block of data. It's a purposeful feature that allows one to instantly spot if a problem relates to a direct block vs an indirect block. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 14:01:51 2011 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 6F0E710656A9; Thu, 3 Feb 2011 14:01:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 048D58FC15; Thu, 3 Feb 2011 14:01:50 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p13E1gwc096291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 16:01:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p13E1gGg046315; Thu, 3 Feb 2011 16:01:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p13E1gDi046314; Thu, 3 Feb 2011 16:01:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Feb 2011 16:01:42 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110203140142.GH78089@deviant.kiev.zoral.com.ua> References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <20110202222023.GA45401@icarus.home.lan> <201102030753.55820.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RDS4xtyBfx+7DiaI" Content-Disposition: inline In-Reply-To: <201102030753.55820.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 14:01:51 -0000 --RDS4xtyBfx+7DiaI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 03, 2011 at 07:53:55AM -0500, John Baldwin wrote: > On Wednesday, February 02, 2011 5:20:23 pm Jeremy Chadwick wrote: > > On Wed, Feb 02, 2011 at 05:04:03PM -0500, John Baldwin wrote: > > > On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: > > > > I haven't had a chance to test this patch yet, but John's did not w= ork > > > > (sorry): > > > >=20 > > > > http://dougbarton.us/ext2fs-crash-dump-2.jpg > > > >=20 > > > > No actual dump this time either. > > > >=20 > > > > I'm happy to test the patch below on Thursday if there is consensus= that > > > > it will work. > > >=20 > > > Err, this is a different panic than what you reported earlier. Your = disk died=20 > > > and spewed a bunch of EIO errors. I can look at the locking assertio= n failure=20 > > > tomorrow, but this is a differnt issue. Even UFS needed a good bit o= f work to=20 > > > handle disks dying gracefully. > >=20 > > Are the byte offsets shown in the screenshot within the range of the > > drive's capacity? They're around the 10.7GB mark, but I have no idea > > what size disk is being used. > >=20 > > The reason I ask is that there have been reported issues in the past > > where the offsets shown are way outside of the range of the permitted > > byte offsets of the disk itself (and in some cases even showing a > > negative number; what is it with people not understanding the difference > > between signed and unsigned types? Sigh), and I want to make sure this > > isn't one of those situations. I also don't know if underlying > > filesystem corruption could cause the problem in question ("filesystem > > says you should write to block N, which is outside of the permitted > > range of the device"). >=20 > Just one comment. UFS uses negative block numbers to indicate an indirect > block (or some such) as opposed to a direct block of data. It's a purpos= eful > feature that allows one to instantly spot if a problem relates to a direct > block vs an indirect block. Yes, but the block numbers are negative within the vnode address range, not for the on-disk block numbers. ufs_bmap() shall translate negative vnode block numbers to the positive disk block numbers before buffer is passed down. --RDS4xtyBfx+7DiaI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1KtUYACgkQC3+MBN1Mb4geOwCgiz5UyQzCOIQtrpul14qSa2c2 n9EAmwWwtzKnOI+l8fIhfiUJKdKmjGzk =bmS7 -----END PGP SIGNATURE----- --RDS4xtyBfx+7DiaI-- From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 15:13:22 2011 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 8A5A3106567A for ; Thu, 3 Feb 2011 15:13:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 323588FC18 for ; Thu, 3 Feb 2011 15:13:21 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id 3Sne1g0081wpRvQ5CTDNeE; Thu, 03 Feb 2011 15:13:22 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta18.westchester.pa.mail.comcast.net with comcast id 3TDL1g00W2tehsa3eTDMgU; Thu, 03 Feb 2011 15:13:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BA0E89B422; Thu, 3 Feb 2011 07:13:18 -0800 (PST) Date: Thu, 3 Feb 2011 07:13:18 -0800 From: Jeremy Chadwick To: Kostik Belousov Message-ID: <20110203151318.GA9986@icarus.home.lan> References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <20110202222023.GA45401@icarus.home.lan> <201102030753.55820.jhb@freebsd.org> <20110203140142.GH78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110203140142.GH78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 15:13:22 -0000 On Thu, Feb 03, 2011 at 04:01:42PM +0200, Kostik Belousov wrote: > On Thu, Feb 03, 2011 at 07:53:55AM -0500, John Baldwin wrote: > > On Wednesday, February 02, 2011 5:20:23 pm Jeremy Chadwick wrote: > > > On Wed, Feb 02, 2011 at 05:04:03PM -0500, John Baldwin wrote: > > > > On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: > > > > > I haven't had a chance to test this patch yet, but John's did not work > > > > > (sorry): > > > > > > > > > > http://dougbarton.us/ext2fs-crash-dump-2.jpg > > > > > > > > > > No actual dump this time either. > > > > > > > > > > I'm happy to test the patch below on Thursday if there is consensus that > > > > > it will work. > > > > > > > > Err, this is a different panic than what you reported earlier. Your disk died > > > > and spewed a bunch of EIO errors. I can look at the locking assertion failure > > > > tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to > > > > handle disks dying gracefully. > > > > > > Are the byte offsets shown in the screenshot within the range of the > > > drive's capacity? They're around the 10.7GB mark, but I have no idea > > > what size disk is being used. > > > > > > The reason I ask is that there have been reported issues in the past > > > where the offsets shown are way outside of the range of the permitted > > > byte offsets of the disk itself (and in some cases even showing a > > > negative number; what is it with people not understanding the difference > > > between signed and unsigned types? Sigh), and I want to make sure this > > > isn't one of those situations. I also don't know if underlying > > > filesystem corruption could cause the problem in question ("filesystem > > > says you should write to block N, which is outside of the permitted > > > range of the device"). > > > > Just one comment. UFS uses negative block numbers to indicate an indirect > > block (or some such) as opposed to a direct block of data. It's a purposeful > > feature that allows one to instantly spot if a problem relates to a direct > > block vs an indirect block. > Yes, but the block numbers are negative within the vnode address range, > not for the on-disk block numbers. ufs_bmap() shall translate negative > vnode block numbers to the positive disk block numbers before buffer is > passed down. I'm a bit out of my league here (going entirely off of kernel source code), but this is educational for me as well as (probably) others. The error string being discussed is something like: g_vfs_done():da0s2[WRITE(offset=10727313400, length=131072)]error = 5 The output comes from src/sys/geom/geom_vfs.c, function g_vfs_done(): 68 static void 69 g_vfs_done(struct bio *bip) 70 { ... 84 if (bip->bio_error) { 85 printf("g_vfs_done():"); 86 g_print_bio(bip); 87 printf("error = %d\n", bip->bio_error); 88 } ... g_print_bio() comes from src/sys/geom/geom_io.c, and prints the contents based on what bip->bio_cmd would contain. In this case, I believe it's BIO_DELETE which is getting called (basing this on the case statement output): 759 void 760 g_print_bio(struct bio *bp) 761 { 762 const char *pname, *cmd = NULL; 763 764 if (bp->bio_to != NULL) 765 pname = bp->bio_to->name; 766 else 767 pname = "[unknown]"; 768 769 switch (bp->bio_cmd) { ... 780 case BIO_WRITE: 781 if (cmd == NULL) 782 cmd = "WRITE"; 783 case BIO_DELETE: 784 if (cmd == NULL) 785 cmd = "DELETE"; 786 printf("%s[%s(offset=%jd, length=%jd)]", pname, cmd, 787 (intmax_t)bp->bio_offset, (intmax_t)bp->bio_length); ... The offset and the length are both explicitly casted and printed as signed numbers here. For me anyway, the next question is "what are bio_offset and bio_length defined as?" (indirectly, "why the explicit cast?"). They're both declared as part of struct bio in src/sys/sys/bio.h as shown: 71 struct bio { ... 78 off_t bio_offset; /* Offset into file. */ ... 92 off_t bio_length; /* Like bio_bcount */ ... Since I'm not familiar with the bio stuff, I can't determine if the above printf() statement is actually correct or incorrect. Ultimately, of course, I'm trying to determine if "offset=XXX, length=XXX" actually represent what folks think they would. I'm now thinking the error message indicates something equivalent to "I got EIO when attempting to work on file offset XXX, when writing or reading length XXX bytes, and that file gets expanded to a device name in this case. Or do I have it wrong and the "file" is actually the disk (filesystem) itself? I imagine this is where the vfs stuff comes into play... somehow. *over my head* :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 23:04:52 2011 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 C433D1065694 for ; Thu, 3 Feb 2011 23:04:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2918FC23 for ; Thu, 3 Feb 2011 23:04:52 +0000 (UTC) Received: (qmail 12875 invoked by uid 399); 3 Feb 2011 23:04:51 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Feb 2011 23:04:51 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D4B3492.5060801@FreeBSD.org> Date: Thu, 03 Feb 2011 15:04:50 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D47B954.3010600@FreeBSD.org> <20110202014252.GA1574@earth> <4D49C90C.2090003@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <20110202222023.GA45401@icarus.home.lan> In-Reply-To: <20110202222023.GA45401@icarus.home.lan> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 23:04:52 -0000 On 02/02/2011 14:20, Jeremy Chadwick wrote: > On Wed, Feb 02, 2011 at 05:04:03PM -0500, John Baldwin wrote: >> On Wednesday, February 02, 2011 04:13:48 pm Doug Barton wrote: >>> I haven't had a chance to test this patch yet, but John's did not work >>> (sorry): >>> >>> http://dougbarton.us/ext2fs-crash-dump-2.jpg >>> >>> No actual dump this time either. >>> >>> I'm happy to test the patch below on Thursday if there is consensus that >>> it will work. >> >> Err, this is a different panic than what you reported earlier. Your disk died >> and spewed a bunch of EIO errors. I can look at the locking assertion failure >> tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to >> handle disks dying gracefully. > > Are the byte offsets shown in the screenshot within the range of the > drive's capacity? They're around the 10.7GB mark, but I have no idea > what size disk is being used. It's a USB backup drive which I've partitioned into one FAT32 and one ext2fs. When the crash happened I was copying a 1.1G file from the FAT32 partition to the ext2fs. The ext2fs partition is only 10 G total. df output shows 10399780 1k blocks. There is plenty of room on the ext2fs partition for the file, only about 1.5 G of that partition is currently in use. > The reason I ask is that there have been reported issues in the past > where the offsets shown are way outside of the range of the permitted > byte offsets of the disk itself (and in some cases even showing a > negative number; what is it with people not understanding the difference > between signed and unsigned types? Sigh), and I want to make sure this > isn't one of those situations. I also don't know if underlying > filesystem corruption could cause the problem in question ("filesystem > says you should write to block N, which is outside of the permitted > range of the device"). > > Specifically with regards to the I/O errors: I can assist with verifying > the disk has a problem, but I forget if smartmontools will work under > FreeBSD if the hard disk is attached via umass or not. I didn't think it would, but I tested the theory just to be sure. :) So I'm totally willing to accept the explanation that this second crash is a different bug. I probably will not be able to do it today, but I'm still willing to stress-test John's patch if there is agreement that it's the right way to go. Hopefully it will fare better if it's not a USB disk we're dealing with. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 23:06:34 2011 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 C24E41065670 for ; Thu, 3 Feb 2011 23:06:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 571F18FC15 for ; Thu, 3 Feb 2011 23:06:34 +0000 (UTC) Received: (qmail 14974 invoked by uid 399); 3 Feb 2011 23:06:34 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Feb 2011 23:06:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D4B34F8.3040101@FreeBSD.org> Date: Thu, 03 Feb 2011 15:06:32 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D47B954.3010600@FreeBSD.org> <20110202014252.GA1574@earth> <4D49C90C.2090003@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> In-Reply-To: <201102021704.04274.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 23:06:34 -0000 On 02/02/2011 14:04, John Baldwin wrote: > Err, this is a different panic than what you reported earlier. Your disk died > and spewed a bunch of EIO errors. I can look at the locking assertion failure > tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to > handle disks dying gracefully. Can you defined "died" a bit? :-/ I just plugged it back in and it seems to be working Ok, but it's my backup disk so if I'm looking at a potential failure I'm a bit worried ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Thu Feb 3 23:33:28 2011 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 71ADF106566C for ; Thu, 3 Feb 2011 23:33:28 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id F28D68FC0C for ; Thu, 3 Feb 2011 23:33:27 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p13L9Dst026795 for ; Fri, 4 Feb 2011 08:09:13 +1100 Received: from server.vk2pj.dyndns.org (c220-239-52-50.belrs4.nsw.optusnet.com.au [220.239.52.50]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p13L99wJ027279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Feb 2011 08:09:10 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p13L99AJ043955; Fri, 4 Feb 2011 08:09:09 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p13L99rf043954; Fri, 4 Feb 2011 08:09:09 +1100 (EST) (envelope-from peter) Date: Fri, 4 Feb 2011 08:09:09 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20110203210909.GA28604@server.vk2pj.dyndns.org> References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <20110202222023.GA45401@icarus.home.lan> <201102030753.55820.jhb@freebsd.org> <20110203140142.GH78089@deviant.kiev.zoral.com.ua> <20110203151318.GA9986@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20110203151318.GA9986@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 03 Feb 2011 23:33:28 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Feb-03 07:13:18 -0800, Jeremy Chadwick w= rote: >The offset and the length are both explicitly casted and printed as >signed numbers here. > >For me anyway, the next question is "what are bio_offset and bio_length >defined as?" (indirectly, "why the explicit cast?"). They're both >declared as part of struct bio in src/sys/sys/bio.h as shown: > > 71 struct bio { >... > 78 off_t bio_offset; /* Offset into file. */ >... > 92 off_t bio_length; /* Like bio_bcount */ >... off_t is always a 64-bit signed int and there's no printf(9) length modifier to handle this particular situation (it's typically 'long' on 64-bit archs and 'long long' on 32-bit archs). Instead it's cast to a signed int which is at least as large that does have a suitable length modifier (intmax_t can be printed using %jd). --=20 Peter Jeremy --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1LGXUACgkQ/opHv/APuIfMugCeO07MLbXR438w/Cadukt6L8G8 9LwAoIsx9enpFWLkEPV+hlc63xoOybS1 =ig5f -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 11:55:52 2011 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 C10711065672 for ; Fri, 4 Feb 2011 11:55:52 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1A48FC17 for ; Fri, 4 Feb 2011 11:55:52 +0000 (UTC) Received: from bwex.bally-wulff.de (unknown [192.9.204.106]) by mail2.bally-wulff-berlin.de (Postfix) with ESMTP id CF96699075 for ; Fri, 4 Feb 2011 12:37:55 +0100 (CET) Received: from [192.9.205.177] ([192.9.205.177]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 12:37:56 +0100 Message-ID: <4D4BE50A.7000705@bally-wulff.de> Date: Fri, 04 Feb 2011 12:37:46 +0100 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101213 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2011 11:37:56.0133 (UTC) FILETIME=[F75F0D50:01CBC45F] Subject: building kernel including GEOM_VINUM 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, 04 Feb 2011 11:55:52 -0000 Hi FS lists, I'm Luca and I use FreeBSD for more than one year. And I'm happy for that! I'm using 7.3 and 8.1. I started to use gvinum+geli and everything is fine. But I've a little problem: for a specific update procedure, I need to build a kernel which includes Vinum, without module. I read on FreeBSD handbook that is possible (but not raccomended), but I don't find how... http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-config.html make lint create a file without any options or device related to vinum I've also checked conf/options and there are no reference to vinum. I missed something or GEOM_VINUM is available just as a module? thanks in advance Luca Pizzamiglio From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 13:40:49 2011 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 0D4F2106564A for ; Fri, 4 Feb 2011 13:40:49 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 904568FC1F for ; Fri, 4 Feb 2011 13:40:48 +0000 (UTC) Received: by fxm16 with SMTP id 16so2416972fxm.13 for ; Fri, 04 Feb 2011 05:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=s8M8aMaKJtkB7nhY2HA5YmfXn2oCJU/ych7yCEj6kuQ=; b=I9GUKe9KLBtTC8PWZmWYLxLsUBEcDuVtKIWc8uUhuaAYTBPvipBlehHBa4MsVYJgQh EWROS4rG2VVqs2BDaHoS6y9AAltpt9Ztvuee8BR5cCKf3D6lBxLNeoD8WAHE7IUkCpSl dTmuKmF+rhDyXUOrkRoEToWpZb227Xo0eN46M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=O0FM3xNscza3rCt889cX9Tgt8qam3JUg1dJCoKli0mzZhgKcGc5Sikq4kuWkKRaX/e Mdq65NmGnR2LhxsG+glsMO9Xd22wtFDjLd9gt9TVHKUxuLBFrgL5dC9hZWMO+polQDWx lNM484TK0ozlAl8StQXsGvnfxUSOuCv3DXq/I= Received: by 10.223.78.138 with SMTP id l10mr6149283fak.17.1296825176798; Fri, 04 Feb 2011 05:12:56 -0800 (PST) Received: from ernst.jennejohn.org (p578E1E1A.dip.t-dialin.net [87.142.30.26]) by mx.google.com with ESMTPS id 11sm216162faw.44.2011.02.04.05.12.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 05:12:56 -0800 (PST) Date: Fri, 4 Feb 2011 14:12:54 +0100 From: Gary Jennejohn To: Luca Pizzamiglio Message-ID: <20110204141254.1dd98de8@ernst.jennejohn.org> In-Reply-To: <4D4BE50A.7000705@bally-wulff.de> References: <4D4BE50A.7000705@bally-wulff.de> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: building kernel including GEOM_VINUM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:40:49 -0000 On Fri, 04 Feb 2011 12:37:46 +0100 Luca Pizzamiglio wrote: > I'm Luca and I use FreeBSD for more than one year. And I'm happy for > that! I'm using 7.3 and 8.1. > I started to use gvinum+geli and everything is fine. > But I've a little problem: for a specific update procedure, I need to > build a kernel which includes Vinum, without module. > And why do you need it in the kernel? If you load it from /boot/loader.conf it will be running when the machine enters user mode. Or don't you want to have any modules? > I read on FreeBSD > handbook that is possible (but not raccomended), but I don't find how... > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-config.html > > I missed something or GEOM_VINUM is available just as a module? > It would probably require some major hacking. Apparently gvinum was designed with using it only as a KLD in mind. -- Gary Jennejohn From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 16:34:27 2011 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 331E4106564A for ; Fri, 4 Feb 2011 16:34:27 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id DEF1D8FC17 for ; Fri, 4 Feb 2011 16:34:26 +0000 (UTC) Received: from bwex.bally-wulff.de (unknown [192.9.204.106]) by mail2.bally-wulff-berlin.de (Postfix) with ESMTP id 79B1A99075; Fri, 4 Feb 2011 17:34:25 +0100 (CET) Received: from [192.9.205.177] ([192.9.205.177]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:34:25 +0100 Message-ID: <4D4C2A92.1000104@bally-wulff.de> Date: Fri, 04 Feb 2011 17:34:26 +0100 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101213 Thunderbird/3.1.7 MIME-Version: 1.0 To: gljennjohn@googlemail.com References: <4D4BE50A.7000705@bally-wulff.de> <20110204141254.1dd98de8@ernst.jennejohn.org> In-Reply-To: <20110204141254.1dd98de8@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2011 16:34:25.0656 (UTC) FILETIME=[62C0D780:01CBC489] Cc: freebsd-fs@freebsd.org Subject: Re: building kernel including GEOM_VINUM 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, 04 Feb 2011 16:34:27 -0000 Hi Gray, On 02/04/2011 14:12, Gary Jennejohn wrote: > On Fri, 04 Feb 2011 12:37:46 +0100 > Luca Pizzamiglio wrote: > >> I'm Luca and I use FreeBSD for more than one year. And I'm happy for >> that! I'm using 7.3 and 8.1. >> I started to use gvinum+geli and everything is fine. >> But I've a little problem: for a specific update procedure, I need to >> build a kernel which includes Vinum, without module. >> > > And why do you need it in the kernel? If you load it from /boot/loader.conf > it will be running when the machine enters user mode. Or don't you want to > have any modules? > This is an update procedure that starts with a kernel and mount an image file as filesystem. Now they are not strictly dependent, because the kernel is updated more often. Using modules, I've should update also the image file putting in the updated gvinum_module. It's not a bit deal, but I've read on the handbook that it was possible. >> I read on FreeBSD >> handbook that is possible (but not raccomended), but I don't find how... >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-config.html >> >> I missed something or GEOM_VINUM is available just as a module? >> > > It would probably require some major hacking. Apparently gvinum was > designed with using it only as a KLD in mind. > Is that meanings that there's an error on handbook? How I (or we) could improve it? Best regards, Luca Pizzamiglio From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 17:07:49 2011 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 7D8B8106566C for ; Fri, 4 Feb 2011 17:07:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD408FC08 for ; Fri, 4 Feb 2011 17:07:48 +0000 (UTC) Received: by yxh35 with SMTP id 35so1052812yxh.13 for ; Fri, 04 Feb 2011 09:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=O6u32nPPI1gsqUHwA5ay8hN+qnZxdcPt0y2B1Zwmkgc=; b=klkzQHdtZyE3peJYHDHRcfrXifXTQ0CNF73bl6JRQYFE+385Fst0raZxvS+31G4NqR 4uTwRbRkqqMUCSPA5rD1aIySBXF3tZ26vSRcabIXe47gQQNEKk1EElF+wE2Gvwbcr2Y3 9gBQ2RzwO0nUJuFO1Zxlm/s6D8meAM0W4j6yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jsCU1rEm+mHQ/YPEFLeuNhpLRFDhtrih3HInzpzendWcyyIOkVIbGYIEiSg+n/i0Lt k6nUhNK2yTnwZyDljLOnkVCoGivNzLQh7L3oK38ScVdIdSx2OV7eBz2Mod651JZq8lBK b4MB1kISQ2eGwL3jUDKcSaqWix9A6SPZFy//w= MIME-Version: 1.0 Received: by 10.90.26.11 with SMTP id 11mr9235374agz.91.1296837603423; Fri, 04 Feb 2011 08:40:03 -0800 (PST) Received: by 10.91.111.10 with HTTP; Fri, 4 Feb 2011 08:40:03 -0800 (PST) Date: Fri, 4 Feb 2011 08:40:03 -0800 Message-ID: From: Freddie Cash To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 Subject: geom_sched and ZFS 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, 04 Feb 2011 17:07:49 -0000 Just curious if anyone has played around with geom_sched underneath ZFS, and found it to be extremely worthwhile, or not worth the bother, or if if it should be avoided altogether. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 17:16:55 2011 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 739BA106566C; Fri, 4 Feb 2011 17:16:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 44BF78FC12; Fri, 4 Feb 2011 17:16:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EC17E46B2C; Fri, 4 Feb 2011 12:16:54 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.10]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 267608A01D; Fri, 4 Feb 2011 12:16:54 -0500 (EST) From: John Baldwin To: Doug Barton Date: Fri, 4 Feb 2011 07:59:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <4D4B34F8.3040101@FreeBSD.org> In-Reply-To: <4D4B34F8.3040101@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102040759.51736.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 04 Feb 2011 12:16:54 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=2.1 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06, MAY_BE_FORGED,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 04 Feb 2011 17:16:55 -0000 On Thursday, February 03, 2011 6:06:32 pm Doug Barton wrote: > On 02/02/2011 14:04, John Baldwin wrote: > > Err, this is a different panic than what you reported earlier. Your disk died > > and spewed a bunch of EIO errors. I can look at the locking assertion failure > > tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to > > handle disks dying gracefully. > > Can you defined "died" a bit? :-/ I just plugged it back in and it > seems to be working Ok, but it's my backup disk so if I'm looking at a > potential failure I'm a bit worried ... It's hard to say as the other errors have already scrolled off the screen. If you accidentally bumped the drive so that USB detached it then that would have the same effect. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 17:28:40 2011 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 B9985106566B for ; Fri, 4 Feb 2011 17:28:40 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id E1C388FC21 for ; Fri, 4 Feb 2011 17:28:39 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 76EC2E7598; Fri, 4 Feb 2011 17:28:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=NGy9NO3zzlR5 J2xwTCwEVA6tzI4=; b=hLGJmQ+60zuOE7rWsKLqdpHJibRp3ik/dQVVmEKxNjbj LNlCes5hgrDJP6/PB0QWWcIIUNiHB48Et70TnjqHiB9IfR7j3WtnB+wtdAMrCDe/ Xc9rIWA3msRkvX4wie5ouyhlBnDRE1jAhJ1//TdkizKtPAmVbOGfEb4RlL8kxN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=HWETTj DWE8aHGHimPmWmcqH3ZPxjKENbvVnrS1a3G96zHzo2CAvXc08ix9190K4CK338yV AD6bqSzg4uQlVxIy/9LqQaSlx78f1mvUMjWZmIWlmo8AXWybhaHTacw/qkw2xm5x cZF29iobFpuIES6lT/D25pP0K8y01rDflsBng= Received: from unknown (client-86-23-50-224.brhm.adsl.virginmedia.com [86.23.50.224]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 331B2E7594; Fri, 4 Feb 2011 17:28:38 +0000 (GMT) Date: Fri, 4 Feb 2011 17:28:22 +0000 From: Bruce Cran To: Freddie Cash Message-ID: <20110204172822.00006149@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8cvs9 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Filesystems Subject: Re: geom_sched and ZFS 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, 04 Feb 2011 17:28:40 -0000 On Fri, 4 Feb 2011 08:40:03 -0800 Freddie Cash wrote: > Just curious if anyone has played around with geom_sched underneath > ZFS, and found it to be extremely worthwhile, or not worth the bother, > or if if it should be avoided altogether. ZFS has its own I/O scheduler so shouldn't have any use for geom_sched. See http://www.solarisinternals.com/wiki/index.php/ZFS_Performance for details. -- Bruce Cran From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 17:47:04 2011 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 C24061065696 for ; Fri, 4 Feb 2011 17:47:04 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 501118FC14 for ; Fri, 4 Feb 2011 17:47:03 +0000 (UTC) Received: by fxm16 with SMTP id 16so2660556fxm.13 for ; Fri, 04 Feb 2011 09:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=7l8WGkP7hb8SBBdrzKlTiFuBzls9u5562uyzbDYHHWQ=; b=BkI3d5VUFaitiRk25sY2QYwjvHUELXEqdmzdtumJTvMX5rdAhrYdC0r/aU5I3mO9PN /4OFMYmcVSQJlXoQqzkCCOIY52Md4u6KyZD+bV7CMDNwomj8+1TT2CLc+x5s53h8a/pb 6hTvTxaaCskiQczd5mh3oj5w0w5ZWiKhbTIe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=Hfr6m3pqZqvnXh64ow5aauErhnwqvZ2b3o+aWba0M58Demwl29cy7MuV0cR2ANxrci HW/pJHlWNkMLhu2nOgKSGV+aWmTRlrQE1uGQxXNYpi8C/hsNC+KUu8bb45m1kRFvto7r yZHP/GDUnbBiGVIkKtpyPTLD4JgH1ojYlPYTg= Received: by 10.223.86.140 with SMTP id s12mr11642671fal.145.1296841622385; Fri, 04 Feb 2011 09:47:02 -0800 (PST) Received: from ernst.jennejohn.org (p578E1E1A.dip.t-dialin.net [87.142.30.26]) by mx.google.com with ESMTPS id f24sm348653fak.24.2011.02.04.09.47.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 09:47:01 -0800 (PST) Date: Fri, 4 Feb 2011 18:47:00 +0100 From: Gary Jennejohn To: Luca Pizzamiglio Message-ID: <20110204184700.025fa407@ernst.jennejohn.org> In-Reply-To: <4D4C2A92.1000104@bally-wulff.de> References: <4D4BE50A.7000705@bally-wulff.de> <20110204141254.1dd98de8@ernst.jennejohn.org> <4D4C2A92.1000104@bally-wulff.de> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: building kernel including GEOM_VINUM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 17:47:04 -0000 On Fri, 04 Feb 2011 17:34:26 +0100 Luca Pizzamiglio wrote: > >> I read on FreeBSD > >> handbook that is possible (but not raccomended), but I don't find how... > >> > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-config.html > >> > >> I missed something or GEOM_VINUM is available just as a module? > >> > > > > It would probably require some major hacking. Apparently gvinum was > > designed with using it only as a KLD in mind. > > > > Is that meanings that there's an error on handbook? How I (or we) could > improve it? > I wouldn't exactly call it an error. The statement is that it _could_ be intergrated into the kernel, but it's recommended to use a KLD instead. That's still valid, since it isn't stated the it _is_ integrated into the kernel. Right now gvinum is only available as a KLD. Whether that will ever change I can't even guess at. -- Gary Jennejohn From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 18:19:43 2011 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 868FB10656C0 for ; Fri, 4 Feb 2011 18:19:43 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0778FC15 for ; Fri, 4 Feb 2011 18:19:43 +0000 (UTC) Received: from [192.168.4.138] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id p14HonkK019180 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 4 Feb 2011 10:50:50 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <4D4C3C75.2000803@scsiguy.com> Date: Fri, 04 Feb 2011 10:50:45 -0700 From: "Justin T. Gibbs" Organization: SCSIGuy.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110123 Thunderbird/3.1.8 MIME-Version: 1.0 To: fs@FreeBSD.org Content-Type: multipart/mixed; boundary="------------050803040204080800080206" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (aslan.scsiguy.com [70.89.174.89]); Fri, 04 Feb 2011 10:50:50 -0700 (MST) Cc: Subject: [PATCH] ZFS: Access vdevs by GUIDs when necessary/appropriate. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gibbs@scsiguy.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:19:43 -0000 This is a multi-part message in MIME format. --------------050803040204080800080206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The attached patch addresses three issues: o The Zpool command (via libzfs) does not display vdev GUID information in all cases where it is the only safe way to refer to a vdev. For example, once a vdev is removed, there is no guarantee that it will return via the same devfs node. The Zpool command already returned GUID information for vdevs found to be missing at system boot time. This change does this for vdevs that go missing some time after a pool is initially imported/mounted. o The Zpool command does not allow a vdev to be referenced by GUID for operations such as "online" or "replace". This is especially frustrating when the vdev you wish to replace was "last seen at" a devfs path that is currently owned by an active member of the pool. In this situation I know of no way to properly replace a vdev, or in the case of an online, to insure that the device is associated with the correct in-core vdev metadata. o The ZFS vdev geom provider uses a incomplete heuristic to determine if a vdev open is for a "new device" or one that has been seen/labeled before. This heuristic fails during a "zpool online" operation allowing the open to associate with a geom provider at the "last seen at" device path when a device exists in the system (at a different device path) with a proper match of the pool and vdev GUIDs referenced in the open. These patches are against -current. Checkin comments indicating what I changed and why are also in the attached file. I haven't reviewed the userland aspects of the pending v28 import yet, but I know that the vdev geom changes are appropriate there too. I would appreciate review and comments on these changes before I commit them to -current and -stable. Thanks, Justin --------------050803040204080800080206 Content-Type: text/plain; name="vdev_guids.diffs" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vdev_guids.diffs" Change 477305 by justing@justing-ns1 on 2011/02/03 14:32:58 Allow zpool operations on vdev's specified by GUID. cddl/contrib/opensolaris/cmd/zpool/zpool_main.c: The "zpool status" command reports the "last seen at" device node path when the vdev name is being reported by GUID. Augment this code to assume a GUID is reported when a device goes missing after initial boot in addition to the previous behavior of doing this for devices that weren't seen at boot. cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c: o In zpool_vdev_name(), report recently missing devices by GUID. There is no guarantee they will return at their previous location. o In vdev_to_nvlist_iter(), remove the test for the ZPOOL_CONFIG_NOT_PRESENT vdev attribute before allowing a search by GUID. The search parameter unambiguously indicates the desired search behavior and this test made it impossible to search for an active (or removed but active at boot) device by GUID. Affected files ... ... //depot/SpectraBSD/head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c#5 edit ... //depot/SpectraBSD/head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c#6 edit Differences ... ==== //depot/SpectraBSD/head/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c#5 (text) ==== @@ -1071,7 +1071,8 @@ } if (nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NOT_PRESENT, - ¬present) == 0) { + ¬present) == 0 || + vs->vs_state <= VDEV_STATE_CANT_OPEN) { char *path; verify(nvlist_lookup_string(nv, ZPOOL_CONFIG_PATH, &path) == 0); (void) printf(" was %s", path); ==== //depot/SpectraBSD/head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c#6 (text) ==== @@ -1391,11 +1391,9 @@ verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_GUID, &theguid) == 0); - if (search == NULL && - nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NOT_PRESENT, &present) == 0) { + if (search == NULL) { /* - * If the device has never been present since import, the only - * reliable way to match the vdev is by GUID. + * Search by GUID. */ if (theguid == guid) return (nv); @@ -2396,9 +2394,17 @@ char buf[64]; vdev_stat_t *vs; uint_t vsc; + int have_stats; - if (nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NOT_PRESENT, - &value) == 0) { + have_stats = nvlist_lookup_uint64_array(nv, ZPOOL_CONFIG_STATS, + (uint64_t **)&vs, &vsc) == 0; + + /* + * If the device is not currently present, assume it will not + * come back at the same device path. Display the device by GUID. + */ + if (nvlist_lookup_uint64(nv, ZPOOL_CONFIG_NOT_PRESENT, &value) == 0 || + have_stats != 0 && vs->vs_state <= VDEV_STATE_CANT_OPEN) { verify(nvlist_lookup_uint64(nv, ZPOOL_CONFIG_GUID, &value) == 0); (void) snprintf(buf, sizeof (buf), "%llu", @@ -2412,8 +2418,7 @@ * open a misbehaving device, which can have undesirable * effects. */ - if ((nvlist_lookup_uint64_array(nv, ZPOOL_CONFIG_STATS, - (uint64_t **)&vs, &vsc) != 0 || + if ((have_stats == 0 || vs->vs_state >= VDEV_STATE_DEGRADED) && zhp != NULL && nvlist_lookup_string(nv, ZPOOL_CONFIG_DEVID, &devid) == 0) { Change 477306 by justing@justing-ns1 on 2011/02/03 14:49:16 Modify the geom vdev provider's open behavior so that it will only unconditionally open a device by path if the open is part of a pool create or device add operation, and a search of all known geom provider's label data doesn't yield a device with matching pool and vdev GUIDs. This fixes a bug where the wrong disk could be associated with a vdev's configuration data when device devfs paths change due to insert and remove events. While, ZFS detects this kind of coding mixup and immediately flags the device as faulted before the confusion can cause permanent data loss, a reboot was necessary in order to resurrect the configuration. sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c: o When opening by GUID, require both the pool and vdev GUIDs to match. While it is highly unlikely for two vdevs to have the same vdev GUIDs, the ZFS storage pool allocator only guarantees they are unique within a pool. o Modify the open behavior to: - Open by recorded device path with GUID matching - If that fails, search all geom providers for a device with matching GUIDs. - If that fails and we are opening a "new to a pool configuration" vdev, open by path. - Otherwise fail the open. Affected files ... ... //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c#8 edit Differences ... ==== //depot/SpectraBSD/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c#8 (text) ==== @@ -160,20 +160,26 @@ } } -static uint64_t -nvlist_get_guid(nvlist_t *list) +static void +nvlist_get_guids(nvlist_t *list, uint64_t *pguid, uint64_t *vguid) { nvpair_t *elem = NULL; - uint64_t value; + *vguid = 0; + *pguid = 0; while ((elem = nvlist_next_nvpair(list, elem)) != NULL) { - if (nvpair_type(elem) == DATA_TYPE_UINT64 && - strcmp(nvpair_name(elem), "guid") == 0) { - VERIFY(nvpair_value_uint64(elem, &value) == 0); - return (value); + if (nvpair_type(elem) != DATA_TYPE_UINT64) + continue; + + if (strcmp(nvpair_name(elem), ZPOOL_CONFIG_POOL_GUID) == 0) { + VERIFY(nvpair_value_uint64(elem, pguid) == 0); + } else if (strcmp(nvpair_name(elem), ZPOOL_CONFIG_GUID) == 0) { + VERIFY(nvpair_value_uint64(elem, vguid) == 0); } + + if (*pguid != 0 && *vguid != 0) + break; } - return (0); } static int @@ -211,8 +217,8 @@ return (error); } -static uint64_t -vdev_geom_read_guid(struct g_consumer *cp) +static void +vdev_geom_read_guids(struct g_consumer *cp, uint64_t *pguid, uint64_t *vguid) { struct g_provider *pp; vdev_label_t *label; @@ -220,16 +226,17 @@ size_t buflen; uint64_t psize; off_t offset, size; - uint64_t guid; int error, l, len, iszvol; g_topology_assert_not(); + *pguid = 0; + *vguid = 0; pp = cp->provider; ZFS_LOG(1, "Reading guid from %s...", pp->name); if (g_getattr("ZFS::iszvol", cp, &iszvol) == 0 && iszvol) { ZFS_LOG(1, "Skipping ZVOL-based provider %s.", pp->name); - return (0); + return; } psize = pp->mediasize; @@ -238,7 +245,6 @@ size = sizeof(*label) + pp->sectorsize - ((sizeof(*label) - 1) % pp->sectorsize) - 1; - guid = 0; label = kmem_alloc(size, KM_SLEEP); buflen = sizeof(label->vl_vdev_phys.vp_nvlist); @@ -256,20 +262,21 @@ if (nvlist_unpack(buf, buflen, &config, 0) != 0) continue; - guid = nvlist_get_guid(config); + nvlist_get_guids(config, pguid, vguid); nvlist_free(config); - if (guid != 0) + if (*pguid != 0 && *vguid != 0) break; } kmem_free(label, size); - if (guid != 0) - ZFS_LOG(1, "guid for %s is %ju", pp->name, (uintmax_t)guid); - return (guid); + if (*pguid != 0 && *vguid != 0) + ZFS_LOG(1, "guid for %s is %ju:%ju", pp->name, + (uintmax_t)*pguid, (uintmax_t)*vguid); } struct vdev_geom_find { - uint64_t guid; + uint64_t pool_guid; + uint64_t vdev_guid; struct g_consumer *cp; }; @@ -289,7 +296,8 @@ struct g_geom *gp, *zgp; struct g_provider *pp; struct g_consumer *zcp; - uint64_t guid; + uint64_t pguid; + uint64_t vguid; g_topology_assert(); @@ -315,15 +323,16 @@ continue; } g_topology_unlock(); - guid = vdev_geom_read_guid(zcp); + vdev_geom_read_guids(zcp, &pguid, &vguid); g_topology_lock(); g_access(zcp, -1, 0, 0); g_detach(zcp); - if (guid != ap->guid) + if (pguid != ap->pool_guid || + vguid != ap->vdev_guid) continue; ap->cp = vdev_geom_attach(pp); if (ap->cp == NULL) { - printf("ZFS WARNING: Unable to attach to %s.\n", + ZFS_LOG(1, "ZFS WARNING: Unable to attach to %s.", pp->name); continue; } @@ -338,13 +347,14 @@ } static struct g_consumer * -vdev_geom_attach_by_guid(uint64_t guid) +vdev_geom_attach_by_guid(uint64_t pool_guid, uint64_t vdev_guid) { struct vdev_geom_find *ap; struct g_consumer *cp; ap = kmem_zalloc(sizeof(*ap), KM_SLEEP); - ap->guid = guid; + ap->pool_guid = pool_guid; + ap->vdev_guid = vdev_guid; g_waitfor_event(vdev_geom_attach_by_guid_event, ap, M_WAITOK, NULL); cp = ap->cp; kmem_free(ap, sizeof(*ap)); @@ -352,14 +362,14 @@ } static struct g_consumer * -vdev_geom_open_by_guid(vdev_t *vd) +vdev_geom_open_by_guids(vdev_t *vd) { struct g_consumer *cp; char *buf; size_t len; ZFS_LOG(1, "Searching by guid [%ju].", (uintmax_t)vd->vdev_guid); - cp = vdev_geom_attach_by_guid(vd->vdev_guid); + cp = vdev_geom_attach_by_guid(spa_guid(vd->vdev_spa), vd->vdev_guid); if (cp != NULL) { len = strlen(cp->provider->name) + strlen("/dev/") + 1; buf = kmem_alloc(len, KM_SLEEP); @@ -368,10 +378,12 @@ spa_strfree(vd->vdev_path); vd->vdev_path = buf; - ZFS_LOG(1, "Attach by guid [%ju] succeeded, provider %s.", + ZFS_LOG(1, "Attach by guid [%ju:%ju] succeeded, provider %s.", + (uintmax_t)spa_guid(vd->vdev_spa), (uintmax_t)vd->vdev_guid, vd->vdev_path); } else { - ZFS_LOG(1, "Search by guid [%ju] failed.", + ZFS_LOG(1, "Search by guid [%ju:%ju] failed.", + (uintmax_t)spa_guid(vd->vdev_spa), (uintmax_t)vd->vdev_guid); } @@ -383,7 +395,8 @@ { struct g_provider *pp; struct g_consumer *cp; - uint64_t guid; + uint64_t pguid; + uint64_t vguid; cp = NULL; g_topology_lock(); @@ -393,14 +406,17 @@ cp = vdev_geom_attach(pp); if (cp != NULL && check_guid) { g_topology_unlock(); - guid = vdev_geom_read_guid(cp); + vdev_geom_read_guids(cp, &pguid, &vguid); g_topology_lock(); - if (guid != vd->vdev_guid) { + if (pguid != spa_guid(vd->vdev_spa) || + vguid != vd->vdev_guid) { vdev_geom_detach(cp, 0); cp = NULL; ZFS_LOG(1, "guid mismatch for provider %s: " - "%ju != %ju.", vd->vdev_path, - (uintmax_t)vd->vdev_guid, (uintmax_t)guid); + "%ju:%ju != %ju:%ju.", vd->vdev_path, + (uintmax_t)spa_guid(vd->vdev_spa), + (uintmax_t)vd->vdev_guid, + (uintmax_t)pguid, (uintmax_t)vguid); } else { ZFS_LOG(1, "guid match for provider %s.", vd->vdev_path); @@ -434,22 +450,42 @@ error = 0; /* - * If we're creating pool, just find GEOM provider by its name - * and ignore GUID mismatches. + * Try using the recorded path for this device, but only + * accept it if its label data contains the expected GUIDs. */ - if (vd->vdev_spa->spa_load_state == SPA_LOAD_NONE) + cp = vdev_geom_open_by_path(vd, 1); + if (cp == NULL) { + /* + * The device at vd->vdev_path doesn't have the + * expected GUIDs. The disks might have merely + * moved around so try all other GEOM providers + * to find one with the right GUIDs. + */ + cp = vdev_geom_open_by_guids(vd); + } + + if (cp == NULL && + vd->vdev_prevstate == VDEV_STATE_UNKNOWN && + vd->vdev_spa->spa_load_state == SPA_LOAD_NONE) { + /* + * We are dealing with a vdev that hasn't been previosly + * opened (since boot), and we are not loading an + * existing pool configuration. This looks like a + * vdev add operation to a new or existing pool. + * Assume the user knows what he/she is doing and find + * GEOM provider by its name, ignoring GUID mismatches. + * + * XXPOLICY: It would be safer to only allow a device + * that is devoid of label information to be + * opened in this fashion. This would require + * a new option to the zpool command line tool + * allowing the label information to be wiped + * on a device, and augmented error reporting + * so the user can understand why their request + * failed and the required steps to repurpose + * the device. + */ cp = vdev_geom_open_by_path(vd, 0); - else { - cp = vdev_geom_open_by_path(vd, 1); - if (cp == NULL) { - /* - * The device at vd->vdev_path doesn't have the - * expected guid. The disks might have merely - * moved around so try all other GEOM providers - * to find one with the right guid. - */ - cp = vdev_geom_open_by_guid(vd); - } } if (cp == NULL) { --------------050803040204080800080206-- From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 19:33:52 2011 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 037BD106564A; Fri, 4 Feb 2011 19:33:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96EE98FC08; Fri, 4 Feb 2011 19:33:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p14JXpZS034060; Fri, 4 Feb 2011 19:33:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p14JXpYn034056; Fri, 4 Feb 2011 19:33:51 GMT (envelope-from linimon) Date: Fri, 4 Feb 2011 19:33:51 GMT Message-Id: <201102041933.p14JXpYn034056@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154491: [smbfs] smb_co_lock: recursive lock for object 1 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, 04 Feb 2011 19:33:52 -0000 Old Synopsis: smb_co_lock: recursive lock for object 1 New Synopsis: [smbfs] smb_co_lock: recursive lock for object 1 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 4 19:33:13 UTC 2011 Responsible-Changed-Why: reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=154491 From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 21:21:58 2011 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 BCEFF106566B for ; Fri, 4 Feb 2011 21:21:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 56CBC8FC17 for ; Fri, 4 Feb 2011 21:21:58 +0000 (UTC) Received: (qmail 31826 invoked by uid 399); 4 Feb 2011 21:21:57 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 4 Feb 2011 21:21:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D4C6DF4.2060004@FreeBSD.org> Date: Fri, 04 Feb 2011 13:21:56 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D47B954.3010600@FreeBSD.org> <201102021704.04274.jhb@freebsd.org> <4D4B34F8.3040101@FreeBSD.org> <201102040759.51736.jhb@freebsd.org> In-Reply-To: <201102040759.51736.jhb@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ext2fs crash in -current (r218056) 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, 04 Feb 2011 21:21:58 -0000 On 02/04/2011 04:59, John Baldwin wrote: > On Thursday, February 03, 2011 6:06:32 pm Doug Barton wrote: >> On 02/02/2011 14:04, John Baldwin wrote: >>> Err, this is a different panic than what you reported earlier. Your disk died >>> and spewed a bunch of EIO errors. I can look at the locking assertion failure >>> tomorrow, but this is a differnt issue. Even UFS needed a good bit of work to >>> handle disks dying gracefully. >> >> Can you defined "died" a bit? :-/ I just plugged it back in and it >> seems to be working Ok, but it's my backup disk so if I'm looking at a >> potential failure I'm a bit worried ... > > It's hard to say as the other errors have already scrolled off the screen. There weren't any other errors. I just trimmed the jpeg down to a more manageable level. > If you accidentally bumped the drive so that USB detached it then that would > have the same effect. I don't _think_ I did that, but it's not outside the realm of possibility. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 21:30:10 2011 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 3B3451065672 for ; Fri, 4 Feb 2011 21:30:10 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id A62048FC1F for ; Fri, 4 Feb 2011 21:30:03 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id 3xEU1g0031ap0As5ExW3ti; Fri, 04 Feb 2011 21:30:03 +0000 Received: from koitsu.dyndns.org ([98.248.34.134]) by omta22.westchester.pa.mail.comcast.net with comcast id 3xVz1g0102tehsa3ixW1SZ; Fri, 04 Feb 2011 21:30:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A7B779B427; Fri, 4 Feb 2011 13:29:57 -0800 (PST) Date: Fri, 4 Feb 2011 13:29:57 -0800 From: Jeremy Chadwick To: Bruce Cran Message-ID: <20110204212957.GA9549@icarus.home.lan> References: <20110204172822.00006149@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110204172822.00006149@unknown> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Filesystems Subject: Re: geom_sched and ZFS 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, 04 Feb 2011 21:30:10 -0000 On Fri, Feb 04, 2011 at 05:28:22PM +0000, Bruce Cran wrote: > On Fri, 4 Feb 2011 08:40:03 -0800 > Freddie Cash wrote: > > > Just curious if anyone has played around with geom_sched underneath > > ZFS, and found it to be extremely worthwhile, or not worth the bother, > > or if if it should be avoided altogether. > > ZFS has its own I/O scheduler so shouldn't have any use for geom_sched. > See http://www.solarisinternals.com/wiki/index.php/ZFS_Performance for > details. And furthermore, gsched greatly angers things like sysinstall. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Fri Feb 4 22:49:08 2011 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 CBF8A106566B for ; Fri, 4 Feb 2011 22:49:08 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1368FC15 for ; Fri, 4 Feb 2011 22:49:08 +0000 (UTC) Received: by eyf6 with SMTP id 6so1544075eyf.13 for ; Fri, 04 Feb 2011 14:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=62sBOY7HmPTNL1ijmtvGepetppu44QeJkKL3fEa3xHo=; b=Phqt1QMj0U8HHKdxrQ+MUz6kO4aM0JIOlp0yPBi1nywnz1p6IZ1cvX6r2K9UEaUPs6 7XfHUkig9Blz5h3odhXqCm2WjcJgm3qs5k3phoDl91ZyOqZ8kIxn3iM4HgoDuL7aRBfX B3rEa3y+Z9So7UtQvTNix67dfFs/moGk+dIkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=OxcKEyVyt5p8bngf1YyuJRjPnwa7/Dt2XgsTVQdA5DX5NojkCaxjQerzpxpqy0t1yu b+WItdXoIUalFhUUvzJLBbMo0VmHIESsqhKShE5XRZY3KR5rZQ/fyG7dVdIWnbJIKTYc dEjWUOfhKfZxMdxs9FEhmlTGWEr/viOnZvOjY= Received: by 10.213.32.208 with SMTP id e16mr15784243ebd.35.1296859747309; Fri, 04 Feb 2011 14:49:07 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id x54sm912410eeh.5.2011.02.04.14.49.06 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 14:49:06 -0800 (PST) Date: Sat, 5 Feb 2011 00:48:56 +0200 From: Gleb Kurtsou To: Gary Jennejohn Message-ID: <20110204224856.GA78229@tops.skynet.lt> References: <4D4BE50A.7000705@bally-wulff.de> <20110204141254.1dd98de8@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110204141254.1dd98de8@ernst.jennejohn.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: building kernel including GEOM_VINUM 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, 04 Feb 2011 22:49:08 -0000 On (04/02/2011 14:12), Gary Jennejohn wrote: > On Fri, 04 Feb 2011 12:37:46 +0100 > Luca Pizzamiglio wrote: > > > I'm Luca and I use FreeBSD for more than one year. And I'm happy for > > that! I'm using 7.3 and 8.1. > > I started to use gvinum+geli and everything is fine. > > But I've a little problem: for a specific update procedure, I need to > > build a kernel which includes Vinum, without module. > > > > And why do you need it in the kernel? If you load it from /boot/loader.conf > it will be running when the machine enters user mode. Or don't you want to > have any modules? > > > I read on FreeBSD > > handbook that is possible (but not raccomended), but I don't find how... > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-config.html > > > > I missed something or GEOM_VINUM is available just as a module? > > > > It would probably require some major hacking. Apparently gvinum was > designed with using it only as a KLD in mind. The change it trivial, just add files listed in sys/modules/geom/geom_vinum/Makefile to sys/files. It was also necessary it tweak /sbin/gvinum to check if module loaded during startup to eliminate useless warning (afair). I think original author has forgotten to add option to embed gvinum into the kernel. Unfortunately I'm not able to find the patch I've used (it was a while ago). Thanks, Gleb. > -- > Gary Jennejohn > _______________________________________________ > 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 4 23:55:56 2011 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 432D1106566B for ; Fri, 4 Feb 2011 23:55:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 020388FC0A for ; Fri, 4 Feb 2011 23:55:55 +0000 (UTC) Received: by yie19 with SMTP id 19so1188118yie.13 for ; Fri, 04 Feb 2011 15:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=y/PVXHjJuM/fhK5qxTwdZ9tQEtWtm+zfTtewEjWFO0E=; b=f5ZXikVDuyuEcdhmcY0tk4XbHnZmnmuxg+20HEYLXYQH1ubmIXRnujUr0p/ySh5Lso YIq1IZ6I4HzbztCaPsOs/LLyEjuZTJYmSJIf3YoydbxLNbVBfPY3KcBqMqxt+gKTJU9x dEEvAcneBiFk2o1NCA0OW2/JyQbtkQnGSD1g4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tcYjqnEwS0uKzs74I6b4H9LvY0arnQo39BORJbuVHXYgRzqs3/NheHymUih8oYnoRe QtUEdbq4GzjtSG98Ff3w46sP4ot2QHdPjri5TbKIG53MHRQ5yoYNrNGHjLy77DPCfY8v E6jWKvJTXj0ugm5iQiXn2FxyLYqcuhGQja7D0= MIME-Version: 1.0 Received: by 10.90.75.4 with SMTP id x4mr15602463aga.177.1296863753530; Fri, 04 Feb 2011 15:55:53 -0800 (PST) Received: by 10.90.32.20 with HTTP; Fri, 4 Feb 2011 15:55:53 -0800 (PST) In-Reply-To: <20110204212957.GA9549@icarus.home.lan> References: <20110204172822.00006149@unknown> <20110204212957.GA9549@icarus.home.lan> Date: Fri, 4 Feb 2011 15:55:53 -0800 Message-ID: From: Freddie Cash To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 Subject: Re: geom_sched and ZFS 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, 04 Feb 2011 23:55:56 -0000 On Fri, Feb 4, 2011 at 1:29 PM, Jeremy Chadwick wrote: > On Fri, Feb 04, 2011 at 05:28:22PM +0000, Bruce Cran wrote: >> On Fri, 4 Feb 2011 08:40:03 -0800 >> Freddie Cash wrote: >> >> > Just curious if anyone has played around with geom_sched underneath >> > ZFS, and found it to be extremely worthwhile, or not worth the bother, >> > or if if it should be avoided altogether. >> >> ZFS has its own I/O scheduler so shouldn't have any use for geom_sched. >> See http://www.solarisinternals.com/wiki/index.php/ZFS_Performance for >> details. > > And furthermore, gsched greatly angers things like sysinstall. Yeah, I kinda figured it wouldn't be needed. Just curious if anyone tried it. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Sat Feb 5 09:07:32 2011 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 A819C1065694 for ; Sat, 5 Feb 2011 09:07:32 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31FFA8FC18 for ; Sat, 5 Feb 2011 09:07:31 +0000 (UTC) Received: by bwz12 with SMTP id 12so3431497bwz.13 for ; Sat, 05 Feb 2011 01:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:date:from:to:subject:message-id:in-reply-to :references:reply-to:x-mailer:mime-version:content-type :content-transfer-encoding; bh=ph77yP1uHdoYlJ5pcOFzBkBHEXoYXk9lzmAaGJVSVKY=; b=PMkPSDIgMiSVWcgL2LSC+C4Bw1fyJ51gm55f5CbJo4HeYx4iSvBaEFtlKp66ODhPIC 8L+05T4DxZ60MZXqSXyI7EEBseFVARpqNqL5duTNDdoYwiy7+jxzlNOuZ5Tbi/oyli95 MIuadUqzGwiDpXTvsX29nl/I3Ov0/Ncysy99Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=c/FsWWGQXwSVV7HtUHwQaAXOhYBVuOkYKzgVYpMxyBSIKm8Z0qOiszfPa8v7U5ILFU mXWfubXifYYfb7hpRldTWDIfSF4F7NlovC++tyhTD41owvasjy6JVahfU5hHpyPBK1Mh cEU+5m6ue1cT4G9xzhSUaNmeYvZ9J2t4MjHhU= Received: by 10.204.123.5 with SMTP id n5mr12706332bkr.58.1296896851015; Sat, 05 Feb 2011 01:07:31 -0800 (PST) Received: from ernst.jennejohn.org (p578E220A.dip.t-dialin.net [87.142.34.10]) by mx.google.com with ESMTPS id v1sm875940bkt.17.2011.02.05.01.07.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 01:07:30 -0800 (PST) Date: Sat, 5 Feb 2011 10:07:28 +0100 From: Gary Jennejohn To: freebsd-fs@freebsd.org Message-ID: <20110205100728.46f5ca92@ernst.jennejohn.org> In-Reply-To: <20110204224856.GA78229@tops.skynet.lt> References: <4D4BE50A.7000705@bally-wulff.de> <20110204141254.1dd98de8@ernst.jennejohn.org> <20110204224856.GA78229@tops.skynet.lt> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: building kernel including GEOM_VINUM X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 09:07:32 -0000 On Sat, 5 Feb 2011 00:48:56 +0200 Gleb Kurtsou wrote: > On (04/02/2011 14:12), Gary Jennejohn wrote: > > It would probably require some major hacking. Apparently gvinum was > > designed with using it only as a KLD in mind. > The change it trivial, just add files listed in > sys/modules/geom/geom_vinum/Makefile to sys/files. > It was also necessary it tweak /sbin/gvinum to check if module loaded > during startup to eliminate useless warning (afair). > For someone not used to working with the kernel I'd say that what you describe is major hacking. Especially the modification to gvinum. -- Gary Jennejohn (gj@) From owner-freebsd-fs@FreeBSD.ORG Sat Feb 5 21:14:20 2011 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 7ED4D106566B for ; Sat, 5 Feb 2011 21:14:20 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07CE48FC12 for ; Sat, 5 Feb 2011 21:14:19 +0000 (UTC) Received: by ewy24 with SMTP id 24so1779830ewy.13 for ; Sat, 05 Feb 2011 13:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FWgBe19LNx88NZGWLy1p9T/lH+E/ib6ht0JV5octfOM=; b=ZgQZRPDJOlFylGhRpNMMs31O0+ZZsnqlGWFlCtm+JpKwd/arF2GrI+C0k7CNj45orA ZGG/2AoF0fQHvfIPWdUgyqE8jpVxjd9ResT3mQOagHSJ8oAQEFLeWSJz+8OQYUUnAeQa IW4ODiJhXLMOh0urdOP3WXAT53AkBgda+SXDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=co+Axi+HEmKcPEHLZYYjR+O87/EGmvtVu8YWAo+h01IpVs3o8sL+eUYBlapyUpf1zo jNDBA4HaP0U4i/F4lVotd5EsTV51LAg6eYcz/Vqh2d5d5nDIldMBbU3ppDtV7tPIXe6M J5afvKPJkltkgtwwzWKCMf5TMe6UOebnuoKUY= Received: by 10.213.25.140 with SMTP id z12mr16963683ebb.90.1296940458907; Sat, 05 Feb 2011 13:14:18 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id t50sm1704853eeh.0.2011.02.05.13.14.17 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 13:14:18 -0800 (PST) Date: Sat, 5 Feb 2011 23:14:06 +0200 From: Gleb Kurtsou To: Gary Jennejohn Message-ID: <20110205211405.GA7212@tops.skynet.lt> References: <4D4BE50A.7000705@bally-wulff.de> <20110204141254.1dd98de8@ernst.jennejohn.org> <20110204224856.GA78229@tops.skynet.lt> <20110205100728.46f5ca92@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20110205100728.46f5ca92@ernst.jennejohn.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: building kernel including GEOM_VINUM 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, 05 Feb 2011 21:14:20 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (05/02/2011 10:07), Gary Jennejohn wrote: > On Sat, 5 Feb 2011 00:48:56 +0200 > Gleb Kurtsou wrote: > > On (04/02/2011 14:12), Gary Jennejohn wrote: > > > It would probably require some major hacking. Apparently gvinum was > > > designed with using it only as a KLD in mind. > > The change it trivial, just add files listed in > > sys/modules/geom/geom_vinum/Makefile to sys/files. > > It was also necessary it tweak /sbin/gvinum to check if module loaded > > during startup to eliminate useless warning (afair). > > For someone not used to working with the kernel I'd say that what you > describe is major hacking. Especially the modification to gvinum. The patch attached. Would you test if it's ok in both cases: built-in and module. vinum(4) man page states that loading it as module is preferred, I see no reason for it to still remain so, the text was written in ~1999 and vinum was rewritten on top of geom afterwards. Thanks, Gleb. --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="gvinum-kernel.patch.txt" commit 2200845bcf19dcf410a23429d2f1421060023992 Author: Gleb Kurtsou Date: Sun Feb 6 01:04:09 2011 +0200 Support building kernel with gvinum included diff --git a/sbin/gvinum/gvinum.c b/sbin/gvinum/gvinum.c index f936a58..033a553 100644 --- a/sbin/gvinum/gvinum.c +++ b/sbin/gvinum/gvinum.c @@ -94,8 +94,10 @@ main(int argc, char **argv) char buffer[BUFSIZ], *inputline, *token[GV_MAXARGS]; /* Load the module if necessary. */ - if (kldfind(GVINUMMOD) < 0 && kldload(GVINUMMOD) < 0) - err(1, GVINUMMOD ": Kernel module not available"); + if (modfind(GVINUMMOD) < 0) { + if (kldload(GVINUMKLD) < 0 && modfind(GVINUMMOD) < 0) + err(1, GVINUMKLD ": Kernel module not available"); + } /* Arguments given on the command line. */ if (argc > 1) { @@ -1206,9 +1208,10 @@ gvinum_stop(int argc, char **argv) { int err, fileid; - fileid = kldfind(GVINUMMOD); + fileid = kldfind(GVINUMKLD); if (fileid == -1) { - warn("cannot find " GVINUMMOD); + if (modfind(GVINUMMOD) < 0) + warn("cannot find " GVINUMKLD); return; } @@ -1218,7 +1221,7 @@ gvinum_stop(int argc, char **argv) * event thread will be free for the g_wither_geom() call from * gv_unload(). It's silly, but it works. */ - printf("unloading " GVINUMMOD " kernel module... "); + printf("unloading " GVINUMKLD " kernel module... "); fflush(stdout); if ((err = kldunload(fileid)) != 0 && (errno == EAGAIN)) { sleep(1); @@ -1226,7 +1229,7 @@ gvinum_stop(int argc, char **argv) } if (err != 0) { printf(" failed!\n"); - warn("cannot unload " GVINUMMOD); + warn("cannot unload " GVINUMKLD); return; } diff --git a/sbin/gvinum/gvinum.h b/sbin/gvinum/gvinum.h index d1b45a0..14f7562 100644 --- a/sbin/gvinum/gvinum.h +++ b/sbin/gvinum/gvinum.h @@ -36,4 +36,5 @@ /* $FreeBSD$ */ -#define GVINUMMOD "geom_vinum" +#define GVINUMMOD "g_vinum" +#define GVINUMKLD "geom_vinum" diff --git a/sys/conf/NOTES b/sys/conf/NOTES index dc3d8f1..602cc23 100644 --- a/sys/conf/NOTES +++ b/sys/conf/NOTES @@ -168,6 +168,7 @@ options GEOM_SHSEC # Shared secret. options GEOM_STRIPE # Disk striping. options GEOM_SUNLABEL # Sun/Solaris partitioning options GEOM_UZIP # Read-only compressed disks +options GEOM_VINUM # Vinum logical volume manager options GEOM_VIRSTOR # Virtual storage. options GEOM_VOL # Volume names from UFS superblock options GEOM_ZERO # Performance testing helper. diff --git a/sys/conf/files b/sys/conf/files index 3973bc9..4823fb0 100644 --- a/sys/conf/files +++ b/sys/conf/files @@ -2075,6 +2075,21 @@ geom/raid3/g_raid3_ctl.c optional geom_raid3 geom/shsec/g_shsec.c optional geom_shsec geom/stripe/g_stripe.c optional geom_stripe geom/uzip/g_uzip.c optional geom_uzip +geom/vinum/geom_vinum.c optional geom_vinum +geom/vinum/geom_vinum_create.c optional geom_vinum +geom/vinum/geom_vinum_drive.c optional geom_vinum +geom/vinum/geom_vinum_plex.c optional geom_vinum +geom/vinum/geom_vinum_volume.c optional geom_vinum +geom/vinum/geom_vinum_subr.c optional geom_vinum +geom/vinum/geom_vinum_raid5.c optional geom_vinum +geom/vinum/geom_vinum_share.c optional geom_vinum +geom/vinum/geom_vinum_list.c optional geom_vinum +geom/vinum/geom_vinum_rm.c optional geom_vinum +geom/vinum/geom_vinum_init.c optional geom_vinum +geom/vinum/geom_vinum_state.c optional geom_vinum +geom/vinum/geom_vinum_rename.c optional geom_vinum +geom/vinum/geom_vinum_move.c optional geom_vinum +geom/vinum/geom_vinum_events.c optional geom_vinum geom/virstor/binstream.c optional geom_virstor geom/virstor/g_virstor.c optional geom_virstor geom/virstor/g_virstor_md.c optional geom_virstor diff --git a/sys/conf/options b/sys/conf/options index 440f89f..f311b79 100644 --- a/sys/conf/options +++ b/sys/conf/options @@ -106,6 +106,7 @@ GEOM_SHSEC opt_geom.h GEOM_STRIPE opt_geom.h GEOM_SUNLABEL opt_geom.h GEOM_UZIP opt_geom.h +GEOM_VINUM opt_geom.h GEOM_VIRSTOR opt_geom.h GEOM_VOL opt_geom.h GEOM_ZERO opt_geom.h --uAKRQypu60I7Lcqm--