From owner-freebsd-fs Sun Oct 6 19:54:26 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956F937B401; Sun, 6 Oct 2002 19:54:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E40C943E65; Sun, 6 Oct 2002 19:54:23 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g972rqOo011449; Sun, 6 Oct 2002 22:53:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 6 Oct 2002 22:53:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Dima Dorfman , fs@FreeBSD.ORG, mux@FreeBSD.ORG Subject: Re: Retrieving filesystem-specific mount parameters from the kernel In-Reply-To: <9511.1033808190@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: > In message <20021005064810.GF26530@trit.org>, Dima Dorfman writes: > >[ rwatson cc'd because I want him to be aware of this possible abuse > > of extended attributes. ] > > > >It is occasionally desirable to display filesystem-specific mount > >parameters in the output of mount(8). For example, it would be useful > >if one could tell whether an NFS mount was tcp or udp, v2 or v3, etc.; > >likewise, it would be useful if one could tell which ruleset is > >associated with a particular devfs mount. This kind of information is > >traditionally included in 'struct statfs', but this doesn't scale well > >(since it requires breaking the ABI whenever we add a new filesystem) > >and doesn't work at all for third-party filesystems. I propose for > >the filesystem to export this information via an extended attribute > >(idea courtesy of Boris Popov). This is entirely backwards and > >forwards compatible, and is easy to implement even in third-party > >filesystems. > > I am not at all thrilled by this. > > First off, mux@'s new mount facility is very flexible and extensible to > when it comes to mount options, and none of the information you mention > above are unable to use that facility, in fact it could be argued that > they should specifically use it. > > Second, I think this is simply not the kind of information which > extended attributes should be used for. Extended attributes are used to > store additional administrative information about a particular vnode, > not to report how the vnode is used or configured. I tend to agree -- without nmount(), extended attributes might very well be the best way to export this information. However, with nmount(), we now have the ability to export arbitrary mount meta-data using a flexible interface, and that's probably the way we should be handling NFS mountpoint meta-data. That said, we definitely need this general capability: we just don't get enough useful information out of the current information export interfaces. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 7 11: 1:29 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00B4F37B404 for ; Mon, 7 Oct 2002 11:01:29 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A098143E3B for ; Mon, 7 Oct 2002 11:01:28 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g97I1SCo085184 for ; Mon, 7 Oct 2002 11:01:28 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g97I1S0N085171 for fs@freebsd.org; Mon, 7 Oct 2002 11:01:28 -0700 (PDT) Date: Mon, 7 Oct 2002 11:01:28 -0700 (PDT) Message-Id: <200210071801.g97I1S0N085171@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: fs@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2000/10/06] kern/21807 fs [patches] Make System attribute correspon 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 7 16:52:48 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9752737B401; Mon, 7 Oct 2002 16:52:46 -0700 (PDT) Received: from client1.solarflare.com (client1.solarflare.com [216.237.3.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1D7C43E6A; Mon, 7 Oct 2002 16:52:23 -0700 (PDT) (envelope-from dima@trit.org) Received: from vagabond.solarflarecom.com (vagabond [10.20.40.41]) by client1.solarflare.com (8.12.1/8.12.1) with ESMTP id g97NpwWJ004149; Mon, 7 Oct 2002 16:51:58 -0700 (PDT) Received: from vagabond.solarflarecom.com (localhost [127.0.0.1]) by vagabond.solarflarecom.com (8.12.6/8.12.5) with ESMTP id g97Nq0cQ054869; Mon, 7 Oct 2002 23:52:00 GMT (envelope-from dima@trit.org) Received: (from dima@localhost) by vagabond.solarflarecom.com (8.12.6/8.12.6/Submit) id g97Npwlq054868; Mon, 7 Oct 2002 23:51:58 GMT X-Authentication-Warning: vagabond.solarflarecom.com: dima set sender to dima@trit.org using -f Date: Mon, 7 Oct 2002 23:51:58 +0000 From: Dima Dorfman To: Robert Watson Cc: Poul-Henning Kamp , fs@freebsd.org, mux@freebsd.org Subject: Re: Retrieving filesystem-specific mount parameters from the kernel Message-ID: <20021007235157.GA25653@trit.org> References: <9511.1033808190@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Robert Watson wrote: > > On Sat, 5 Oct 2002, Poul-Henning Kamp wrote: > > > In message <20021005064810.GF26530@trit.org>, Dima Dorfman writes: > > >[ rwatson cc'd because I want him to be aware of this possible abuse > > > of extended attributes. ] > > > > > >It is occasionally desirable to display filesystem-specific mount > > >parameters in the output of mount(8). For example, it would be useful > > >if one could tell whether an NFS mount was tcp or udp, v2 or v3, etc.; > > >likewise, it would be useful if one could tell which ruleset is > > >associated with a particular devfs mount. This kind of information is > > >traditionally included in 'struct statfs', but this doesn't scale well > > >(since it requires breaking the ABI whenever we add a new filesystem) > > >and doesn't work at all for third-party filesystems. I propose for > > >the filesystem to export this information via an extended attribute > > >(idea courtesy of Boris Popov). This is entirely backwards and > > >forwards compatible, and is easy to implement even in third-party > > >filesystems. > > > > I am not at all thrilled by this. > > > > First off, mux@'s new mount facility is very flexible and extensible to > > when it comes to mount options, and none of the information you mention > > above are unable to use that facility, in fact it could be argued that > > they should specifically use it. I'm somewhat confused by this. As far as I can tell, nmount(2) passes mount options *into* the kernel, and I'm trying to get that information *out* of the kernel. If you're talking about exporting the information in mnt_opt through some other interface (such as mine), then I agree that it is a good idea, and actually considered implementing that as a "default" action if the filesystem didn't override it (e.g., vfs_stdgetextattr() that exports the information in mnt_opt). It is not sufficient to *just* do this, however, since some of the information we may want to export is not something that would be passed in via nmount(2) (e.g., devfs ruleset number, or something else which may change during runtime). For this reason, I explicitly did not call what I'm exporting mount "options", but rather "parameters" (I realize that "option" and "parameter" are very close in meaning--I just wanted a different word). > > Second, I think this is simply not the kind of information which > > extended attributes should be used for. Extended attributes are used to > > store additional administrative information about a particular vnode, > > not to report how the vnode is used or configured. > > I tend to agree -- without nmount(), extended attributes might very well > be the best way to export this information. However, with nmount(), we > now have the ability to export arbitrary mount meta-data using a flexible > interface, and that's probably the way we should be handling NFS > mountpoint meta-data. Again, I'm confused about how one should use nmount(2) to export data out of the kernel. Looking at the prototype, this doesn't look like it's possible, but if I missed something, I'd be grateful if someone would set me on the right track (source or documentation references would be helpful). Thanks, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 7 21:40: 5 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 306FE37B446 for ; Mon, 7 Oct 2002 21:40:00 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66C0043E3B for ; Mon, 7 Oct 2002 21:39:59 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from pegasus.cs.rpi.edu (pegasus.cs.rpi.edu [128.213.12.48]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA47721; Tue, 8 Oct 2002 00:39:53 -0400 (EDT) Received: from pegasus.cs.rpi.edu (crossd@localhost) by pegasus.cs.rpi.edu (8.11.6+Sun/8.9.3) with ESMTP id g984drE16529; Tue, 8 Oct 2002 00:39:53 -0400 (EDT) Message-Id: <200210080439.g984drE16529@pegasus.cs.rpi.edu> X-Authentication-Warning: pegasus.cs.rpi.edu: crossd owned process doing -bs To: bright@mu.org Cc: freebsd-fs@freebsd.org, guptar@cs.rpi.edu Subject: UFS, Inode question Date: Tue, 08 Oct 2002 00:39:52 -0400 From: "David E. Cross" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In our Journalling work we just hit a "hmmmm" point where we aren't sure if we've accounted for a certain case. That case is in the point of inode allocation.... to be specific "how (on disk) is an inode marked for allocation" Our current method independently stores inode allocation and linking as discrete events. The problem arises if one is committed without the other (think an inopportune break point in the disk-journal vs. in-core journal.) That could lead to an inode being allocated, but not actually referenced. What does the system do with an inode with a reference count of 0, is that a free inode (on the "free list"). Or can it still be an unreferenced inode? If it can be unreferenced then we need to rethink some things here as the entire point is to avoid fsck. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 7 21:53:16 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F0837B401 for ; Mon, 7 Oct 2002 21:53:15 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id F332D43E8A for ; Mon, 7 Oct 2002 21:53:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0110.cvx22-bradley.dialup.earthlink.net ([209.179.198.110] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ymMk-0005yN-00; Mon, 07 Oct 2002 21:53:06 -0700 Message-ID: <3DA2646B.45D024AB@mindspring.com> Date: Mon, 07 Oct 2002 21:51:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David E. Cross" Cc: freebsd-fs@freebsd.org, guptar@cs.rpi.edu Subject: Re: UFS, Inode question References: <200210080439.g984drE16529@pegasus.cs.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "David E. Cross" wrote: > Our current method independently stores inode allocation > and linking as discrete events. The problem arises if one is committed > without the other (think an inopportune break point in the disk-journal > vs. in-core journal.) That could lead to an inode being allocated, but not > actually referenced. > > What does the system do with an inode with a reference count of 0, is that > a free inode (on the "free list"). Or can it still be an unreferenced inode? > If it can be unreferenced then we need to rethink some things here as the > entire point is to avoid fsck. These answers are for "fsck -y"; for manual fsck, the answers will depend on your interaction with the fsck program... Unreferenced inodes are not free unless they are marked free in the bitmap. A fsck will mark the free, if they have a zero reference count. An inode with no directory references, but a postive reference count is assumed to have lost its directory entry, and is linked into the lost+found directory. An inode with a zero reference count, but a directory reference to it is assumed to have been a failure during create, and is removed (a failure during delete would leave a positive reference count, and either a directory entry, or no directory entry; in the former case, "the file is there"; the latter case is already covered). The one thing you should be careful of here is to increase and commit the link count change to the inode before making the referencing directory entry (UFS does this already). Actually, every place soft updates creates a dependency, you could create a log entry, and you'd pretty much be "done"... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Oct 7 22:14: 3 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3558537B401 for ; Mon, 7 Oct 2002 22:14:03 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 724FF43E8A for ; Mon, 7 Oct 2002 22:14:02 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from pegasus.cs.rpi.edu (pegasus.cs.rpi.edu [128.213.12.48]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA48911; Tue, 8 Oct 2002 01:13:59 -0400 (EDT) Received: from pegasus.cs.rpi.edu (crossd@localhost) by pegasus.cs.rpi.edu (8.11.6+Sun/8.9.3) with ESMTP id g985Dxn16691; Tue, 8 Oct 2002 01:13:59 -0400 (EDT) Message-Id: <200210080513.g985Dxn16691@pegasus.cs.rpi.edu> X-Authentication-Warning: pegasus.cs.rpi.edu: crossd owned process doing -bs To: Terry Lambert Cc: "David E. Cross" , freebsd-fs@freebsd.org, guptar@cs.rpi.edu, crossd@cs.rpi.edu Subject: Re: UFS, Inode question In-Reply-To: Message from Terry Lambert of "Mon, 07 Oct 2002 21:51:55 PDT." <3DA2646B.45D024AB@mindspring.com> References: <200210080439.g984drE16529@pegasus.cs.rpi.edu> <3DA2646B.45D024AB@mindspring.com> Date: Tue, 08 Oct 2002 01:13:58 -0400 From: "David E. Cross" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Would, under any circumstances, an inode with 0 reference count, and not linked in any directory, with no blocks in any of its block-allocation fields be a filesystem error? -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 8 0:38:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2E4637B401 for ; Tue, 8 Oct 2002 00:38:17 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D7B843E8A for ; Tue, 8 Oct 2002 00:38:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0058.cvx21-bradley.dialup.earthlink.net ([209.179.192.58] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yowY-0001qz-00; Tue, 08 Oct 2002 00:38:15 -0700 Message-ID: <3DA28B20.9845BE56@mindspring.com> Date: Tue, 08 Oct 2002 00:37:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David E. Cross" Cc: freebsd-fs@freebsd.org, guptar@cs.rpi.edu Subject: Re: UFS, Inode question References: <200210080439.g984drE16529@pegasus.cs.rpi.edu> <3DA2646B.45D024AB@mindspring.com> <200210080513.g985Dxn16691@pegasus.cs.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "David E. Cross" wrote: > Would, under any circumstances, an inode with 0 reference count, and not > linked in any directory, with no blocks in any of its block-allocation fields > be a filesystem error? What do you mean "error"? Yes, fsck will complain about it, and yes, it should never happen in normal operation, particularly following a successful, normal shotdown, in which the FS clean bit gets set. I think "man clri" would be helpful to you at this point; you may also want to play around with running it on an FS you don't care about to see what happens... try it with several hard links to the inode being cleared, and try it with only one. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Oct 11 7:58:46 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB1AA37B404; Fri, 11 Oct 2002 07:58:35 -0700 (PDT) Received: from mail0.lsil.com (mail0.lsil.com [147.145.40.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4500043E9E; Fri, 11 Oct 2002 07:58:35 -0700 (PDT) (envelope-from emoore@lsil.com) Received: from mhbs.lsil.com (mhbs.lsil.com [147.145.31.100]) by mail0.lsil.com (8.12.4/8.12.4) with ESMTP id g9BEpbHv001486; Fri, 11 Oct 2002 07:58:33 -0700 (PDT) Received: from atl1.se.lsil.com by mhbs.lsil.com with ESMTP; Fri, 11 Oct 2002 07:58:30 -0700 Received: by EXA-ATLANTA.se.lsil.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 10:58:29 -0400 Message-Id: <0E3FA95632D6D047BA649F95DAB60E5701529093@EXA-ATLANTA.se.lsil.com> From: "Moore, Eric Dean" To: dillon@FreeBSD.ORG, bde@FreeBSD.ORG, alc@FreeBSD.ORG Cc: developers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: buf_daemon - system freeze pulling power - help Date: Fri, 11 Oct 2002 10:58:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have installed freebsd 4.6 onto a IDE drive connected to motherboard ide controller. A second hard drive is connected another controller and mounted with UFS file system. On the 2nd drive I'm run heavy IO for several minutes, then pull power to this drive to simulate hard error situation( a real test case requested by our customer). Within 5 minutes the system freezes. When I mean freeze, the system doesn't respond to any keyboard actions. The only thing the keyboard recognizes is CNTR^ALT^ESC; e.g. ddb or gdb. I have replicated this issue on several different platforms, so I don't think its hardware dependent. As this doesn't freeze system for same hardware under Linux, the customer would expect this to work as well under freebsd. Please note, I have placed a 2nd drive(which power is pulled during heavy IO) to different controllers, both IDE drives and SCSI drives, and it freezes in all cases. I see it occur with both CAM and Block device drivers under freebsd. The mide driver is a driver I'm developing for our IDE controller. (1) aic7899W ( loading the ahc driver - CAM driver ) (2) any AMI megaraid controller ( loading amr driver, compiled to expose logical drives through CAM interface ) (3) any AMI megaraid controller ( loading amr driver, compiled to expose logical drives using amrd block interface ) (3) ide controller CMD649 ( loading the atapi driver built into freebsd - Block driver ) (4) ide controller CMD649 ( loading my mide soft raid driver - CAM driver ) I have been conversing with Justin Gibb's - he suggested that I return CAM_SEL_TIMEOUT; when I do that I get the "Invalidate Pack" message in the da driver, then the system hangs for any controller I use. I'm able to go into gdb or ddb. The problem seems to be in the buf_daemon. See below are three different stack traces ( occurred three diff times). --------------------------------------------------------- Stack trace exhibit #1 ( using gdb ) #1 0xc0342da2 in scgetc (sc=0xc0450a20, flags=0x2) at ../../dev/syscons/syscons.c:3149 #2 0xc033f615 in sckbdevent (thiskbd=0xc04495e0, event=0x0, arg=0xc0450a20) at ../../dev/syscons/syscons.c:616 #3 0xc0336fee in atkbd_intr (kbd=0xc04495e0, arg=0x0) at ../../dev/kbd/atkbd.c:462 #4 0xc0365078 in atkbd_isa_intr (arg=0xc04495e0) at ../../isa/atkbd_isa.c:140 #5 0xc03534a3 in pmap_qremove (va=0xcaa66000, count=0x10) at machine/cpufunc.h:281 #6 0xc0213508 in cluster_callback (bp=0xc6842f94) at ../../kern/vfs_cluster.c:525 #7 0xc021133c in biodone (bp=0xc6842f94) at ../../kern/vfs_bio.c:2698 #8 0xc0133e73 in dastrategy (bp=0xc6842f94) at ../../cam/scsi/scsi_da.c:752 #9 0xc01f3675 in diskstrategy (bp=0xc6842f94) at ../../kern/subr_disk.c:251 #10 0xc02224a0 in spec_strategy (ap=0xcd39ee6c) at ../../miscfs/specfs/spec_vnops.c:479 #11 0xc0221ec9 in spec_vnoperate (ap=0xcd39ee6c) at ../../miscfs/specfs/spec_vnops.c:119 #12 0xc02f84d1 in ufs_vnoperatespec (ap=0xcd39ee6c) at ../../ufs/ufs/ufs_vnops.c:2440 #13 0xc02f7dd1 in ufs_strategy (ap=0xcd39eeb0) at vnode_if.h:944 #14 0xc02f84a1 in ufs_vnoperate (ap=0xcd39eeb0) at ../../ufs/ufs/ufs_vnops.c:2422 #15 0xc020ef9a in bwrite (bp=0xc6842f94) at vnode_if.h:944 #16 0xc02146c2 in vop_stdbwrite (ap=0xcd39eeec) at ../../kern/vfs_default.c:331 #17 0xc021451d in vop_defaultop (ap=0xcd39eeec) at ../../kern/vfs_default.c:150 #18 0xc02f84a1 in ufs_vnoperate (ap=0xcd39eeec) at ../../ufs/ufs/ufs_vnops.c:2422 #19 0xc020f2ea in bawrite (bp=0xc6842f94) at vnode_if.h:1193 #20 0xc0213d8b in cluster_wbuild (vp=0xcde6e0c0, size=0x2000, start_lbn=0x1e2, len=0x10) at ../../kern/vfs_cluster.c:945 #21 0xc020fe4c in vfs_bio_awrite (bp=0xc689622c) at ../../kern/vfs_bio.c:1453 #22 0xc0210596 in flushbufqueues () at ../../kern/vfs_bio.c:1889 #23 0xc021042d in buf_daemon () at ../../kern/vfs_bio.c:1814 --------------------------------------------------------- Stack trace exhibit #2 ( using gdb ) n lockmgr (lkp=0xc6843a1c, flags=0x10002, interlkp=0xc0450fe4, p=0xcc300920) at ../../kern/kern_lock.c:355 #7 0xc0306769 in initpbuf (bp=0xc68439f4) at ../../sys/buf.h:286 #8 0xc030680e in getpbuf (pfreecnt=0xc040672c) at ../../vm/vm_pager.c:401 #9 0xc02139e8 in cluster_wbuild (vp=0xcde60700, size=0x4000, start_lbn=0xd4, len=0x4) at ../../kern/vfs_cluster.c:785 #10 0xc020fe4c in vfs_bio_awrite (bp=0xc685e5ec) at ../../kern/vfs_bio.c:1453 #11 0xc0210596 in flushbufqueues () at ../../kern/vfs_bio.c:1889 #12 0xc021042d in buf_daemon () at ../../kern/vfs_bio.c:1814 --------------------------------------------------------- Stack trace exhibit #3 ( using ddb ) vm_page_set_validclean vm_page_set_valid vfs_busy_pages bwrite vop_stdbwrite vop_defaulttop ufs_vnoperate bawrite cluster_wbuild vfs_bio_awrite flushbufqueues buf_daemon fork_trampoline Eric Moore > RAID Storage Adapters Division > LSI Logic Corporation > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Oct 12 8:22:32 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 010CF37B401 for ; Sat, 12 Oct 2002 08:22:29 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient80-218-16-13.hispeed.ch [80.218.16.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A14DB43E42 for ; Sat, 12 Oct 2002 08:22:27 -0700 (PDT) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from MAIL.NetScum.DynDNS.dK (ipv6.NetScum.dyndns.dk [2002:50da:100d:0:250:daff:fe21:edca]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id g9CFMM700456 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sat, 12 Oct 2002 17:22:23 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by MAIL.NetScum.DynDNS.dK (8.11.6/SMI-4.1-R00T0WNED) id g9CFMMt00455; Sat, 12 Oct 2002 17:22:22 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Sat, 12 Oct 2002 17:22:22 +0200 (CEST) Message-Id: <200210121522.g9CFMMt00455@MAIL.NetScum.DynDNS.dK> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave To: freebsd-fs@freebsd.org Subject: Re: UFS2 panic (and other issues) at mount with unusual `newfs' values X-Hacked: via telnet to your port 25, what else? References: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk> X-Internet-Access-Provided-By: CABAL MODEM (all hail CABAL) X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [IPv6-only address above; strip the obvious for IPv4-only mail] About three months ago, I bothered both this list and -current with a message, and I've finally gotten around to taking a closer look at it, keeping it in -fs this time. I wrote: > It seems that any -f fsize value larger than 8192 given to `newfs' > creates a UFS2 filesystem that causes a panic when mounted, even > #15 0xc0297772 in ffs_mount (mp=0xc1918400, path=0xc1922180 "/mnt", data=---Can' > t read userspace from dump, or kernel process--- Adding some debuggery makes it appear that the real crash occurs in sys/ufs/ffs/ffs_vfsops.c in ffs_mountfs() right here: /* XXX DEBUG */ printf("ffs_mountfs: checkpoint 9\n"); bcopy(bp->b_data, ump->um_fs, (u_int)fs->fs_sbsize); /* XXX DEBUG */ printf("ffs_mountfs: checkpoint 10\n"); This should be line 690, plus or minus a few, in 14.Sep 1.190 revision of this (last one I tried to build). First question: with UFS2, what should the values for sbsize be, so I know if the above line is at fault, or if the numbers I give below indicate a problem elsewhere, like in newfs or something? So, I was having some thoughts about sbsize, after looking at a few messages about problems others had had, and then making a dump of the filesystem I've newfs'ed but can't mount: bash-2.05a# /FreeBSD-CURRENT/sbin/dumpfs /dev/ad2s1e magic 19540119 (UFS2) time Fri Oct 11 19:18:03 2002 offset 2 id [ 3da707cb 453cdc9d ] ncg 8 size 2513070 blocks 2513001 bsize 65536 shift 16 mask 0xffff0000 fsize 32768 shift 15 mask 0xffff8000 ^^^^^ frag 2 shift 1 fsbtodb 6 minfree 0% optim space symlinklen 120 maxbsize 65536 maxbpg 8192 maxcontig 2 contigsumsize 2 nbfree 1256499 ndir 1 nifree 4093 nffree 2 bpg 174097 fpg 348194 ipg 512 nindir 8192 inopb 256 maxfilesize 36033195603132415 sbsize 32768 cgsize 65536 csaddr 12 cssize 0 ^^^^^ sblkno 4 cblkno 6 iblkno 8 dblkno 12 cgrotor 0 fmod 0 ronly 0 clean 1 flags soft-updates Using `gdb' on the earlier panic I had showed then the fsize and sbsize values were both 16384. As noted, with fsize of 8192 I had no problems. Now, using dumpfs on a -stable-created filesystem, with which I've had no problem, shows something different: magic 11954 (UFS1) time Sat Oct 12 15:47:53 2002 id [ 3c2e1d34 7670e862 ] ncg 8 size 2818586 blocks 2818485 bsize 65536 shift 16 mask 0xffff0000 fsize 16384 shift 14 mask 0xffffc000 ^^^^^ frag 4 shift 2 fsbtodb 5 minfree 8% optim time symlinklen 60 maxbpg 16384 maxcontig 1 contigsumsize 0 nbfree 59237 ndir 5 nifree 3929 nffree 13 cpg 2968 bpg 94976 fpg 379904 ipg 512 nindir 16384 inopb 512 nspf 32 maxfilesize 2882479694122844 15 sbsize 8192 cgsize 65536 cgoffset 128 cgmask 0xffffffff ^^^^ csaddr 16 cssize 16384 rotdelay 0ms rps 60 trackskew 0 interleave 1 nsect 4096 npsect 4096 spc 4096 sblkno 4 cblkno 8 iblkno 12 dblkno 16 cgrotor 3 fmod 0 ronly 0 clean 0 flags soft-updates In other words, is the problem in the bcopy() line, or something that it works on, or is the problem in the filesystem I created which gets an sbsize value larger than 8k? Of course, if someone proposes a patch, I'll be happy to test it. As mentioned earlier, it's trivial to invoke the panic with any fs frag size larger than 8k, with UFS2. I haven't tried to see if I can create a fs like the UFS1 above under -current, but that idea occurred to me as a test just for fun. thanks, barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Oct 12 16:30:24 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776BC37B401 for ; Sat, 12 Oct 2002 16:30:23 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B40743EAC for ; Sat, 12 Oct 2002 16:30:23 -0700 (PDT) (envelope-from pete@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g9CNUM3C082128 for ; Sat, 12 Oct 2002 16:30:22 -0700 (PDT) (envelope-from pete@isilon.com) Date: Sat, 12 Oct 2002 16:30:22 -0700 (PDT) From: Peter Godman To: freebsd-fs@freebsd.org Subject: ufs_update and waitfor flag Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org An application running on my system is doing basically: fd = open(file) read(fd, ...) fsync(fd) close(fd) My root filesystem is mounted sync,noatime, but this sequence of operations still results in a bwrite during fsync in ufs_update. This seems to be the result of the following code in ufs_update: int ffs_update(vp, waitfor) struct vnode *vp; int waitfor; { struct fs *fs; struct buf *bp; struct inode *ip; int error; ufs_itimes(vp); ip = VTOI(vp); /* vvvvvvvvvvvv ?? */ if ((ip->i_flag & IN_MODIFIED) == 0 && waitfor == 0) return (0); ip->i_flag &= ~(IN_LAZYMOD | IN_MODIFIED); ... The relevant part here is the "waitfor == 0" in the bailout check. Though the flags on the inode do not indicate that the inode is modified, the fact that we wish to wait for the operation to complete results a write happening here that otherwise wouldn't have. Do other people read this code the same way? Is this desired or expected behaviour? What would happen if I commented out the check for waitfor == 0 at this point? Anyone know why this check is there? Most likely I will modify the application in question, but would like to know whether this code should change too. Thanks! Peter Godman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message