From owner-freebsd-fs Sun Feb 20 2:50:58 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4256337BA8E; Sun, 20 Feb 2000 02:50:56 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id DAA22031; Sun, 20 Feb 2000 03:19:39 -0800 (PST) Date: Sun, 20 Feb 2000 03:19:38 -0800 From: Alfred Perlstein To: fs@freebsd.org Cc: mckusick@freebsd.org Subject: changing mount options still can cause damage? Message-ID: <20000220031938.D21720@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is it true that we can still cause major damage to filesystems that are moved from read-only to read-write or noasync <-> async? From the mount manpage: -- BUGS It is possible for a corrupted file system to cause a crash. Switching a filesystem back and forth between asynchronous and normal op- eration or between read/write and read/only access using ``mount -u'' may gradually bring about severe filesystem corruption. -- The first bug is understandable, but personally I've never seen the second happen, is this still a real problem? If not I'd like to remove it. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Feb 20 9:36:16 2000 Delivered-To: freebsd-fs@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 02A7E37BCD5 for ; Sun, 20 Feb 2000 09:36:03 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 10350 invoked from network); 20 Feb 2000 17:35:59 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 20 Feb 2000 17:35:59 -0000 Date: Mon, 21 Feb 2000 04:35:55 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Mike Dracopoulos Cc: freebsd-fs@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: duplicate blocks in shared ext2 partition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 19 Feb 2000, Mike Dracopoulos wrote: > I am running both FreeBSD and Linux sharing an ext2 /home (on a > dedicated disk). > > Occasionally (say once every month or two), FreeBSD complains on > bootup about /home and asks to run fsck on it. Here is a record of > what happened last time: The system must have crashed while the filesystem was mounted rw for FreeBSD to notice the problem at boot time. After a crash it is normal for fsck to find some problems, especially for async-mounted filesystems. FreeBSD's ext2fs doesn't support async mounting, but it cheats and forces async operation in some cases (mainly for inode writes). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 21 8: 0:36 2000 Delivered-To: freebsd-fs@freebsd.org Received: from altair.origenbio.com (altair.origenbio.com [216.30.62.130]) by hub.freebsd.org (Postfix) with ESMTP id 0B18A37B923 for ; Mon, 21 Feb 2000 08:00:34 -0800 (PST) (envelope-from dmartin@origen.com) Received: from origen.com (dubhe.origen [192.168.0.5]) by altair.origenbio.com (8.9.3/8.9.3) with ESMTP id KAA10678 for ; Mon, 21 Feb 2000 10:00:32 -0600 (CST) (envelope-from dmartin@origen.com) Message-ID: <38B16119.77FEA83D@origen.com> Date: Mon, 21 Feb 2000 10:00:25 -0600 From: Richard Martin X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: CD-R rewrite mount Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know how to mount CD-R CDs after multiple rewrites? I can mount the CD with mount_cd9660 -s 0 /dev/cd0c /cdrom after the first write, but it will not automatically (or otherwise) find the volume table after the first write. the same CD mounts fine on Linux and NT read-only CD readers, and the above command mounts the first write table just fine. Thanks, -- Richard Martin dmartin@origen.com OriGen, inc. Tel: +1 512 474 7278 2525 Hartford Rd. Fax: +1 512 708 8522 Austin, TX 78703 http://www.formed.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 21 8:15:52 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.ariadne-t.gr (mail.ariadne-t.gr [143.233.30.3]) by hub.freebsd.org (Postfix) with SMTP id AF58337B5AB for ; Mon, 21 Feb 2000 08:15:35 -0800 (PST) (envelope-from mdraco@math.uoa.gr) Received: (qmail 27206 invoked from network); 21 Feb 2000 16:15:31 -0000 Received: from ppp5c1.dialup.ariadne-t.gr (HELO comet.db.org) (143.233.100.5) by mail.ariadne-t.gr with SMTP; 21 Feb 2000 16:15:31 -0000 Received: from localhost (mike@localhost) by comet.db.org (8.9.3/8.9.3) with ESMTP id SAA00405; Mon, 21 Feb 2000 18:16:59 +0200 (EET) (envelope-from mike@comet.db.org) Date: Mon, 21 Feb 2000 18:16:59 +0200 (EET) From: Mike Dracopoulos To: Bruce Evans Cc: Mike Dracopoulos , freebsd-fs@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: duplicate blocks in shared ext2 partition In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Feb 2000, Bruce Evans wrote: > On Sat, 19 Feb 2000, Mike Dracopoulos wrote: > > > I am running both FreeBSD and Linux sharing an ext2 /home (on a > > dedicated disk). > > > > Occasionally (say once every month or two), FreeBSD complains on > > bootup about /home and asks to run fsck on it. Here is a record of > > what happened last time: > > The system must have crashed while the filesystem was mounted rw for > FreeBSD to notice the problem at boot time. After a crash it is normal > for fsck to find some problems, especially for async-mounted filesystems. > FreeBSD's ext2fs doesn't support async mounting, but it cheats and > forces async operation in some cases (mainly for inode writes). > Nope, it wasn't a post-crash fsck. The morning after the second of the two files involved was created, FreeBSD booted OK and worked for a few hours, then I booted to Linux just to check something (no /home access at all) and no complaints. It was immediately after that while booting FreeBSD for the 2nd time that I got the message, so I went back to Linux which also picked it up and attempted to fsck. The only recent "crash" I had was with netscape once, and then I didn't even have to kill X, just the shell that started it. I am running 3.4-STABLE and both files with the duplicate blocks were created from FreeBSD. A friend of mine with a similar configuration also mentioned having similar problems. Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 21 16:37:35 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id 0B81F37B529 for ; Mon, 21 Feb 2000 16:37:24 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id QAA18690; Mon, 21 Feb 2000 16:00:52 -0800 (PST) Message-Id: <200002220000.QAA18690@flamingo.McKusick.COM> To: Alfred Perlstein Subject: Re: changing mount options still can cause damage? Cc: fs@freebsd.org In-reply-to: Your message of "Sun, 20 Feb 2000 03:19:38 PST." <20000220031938.D21720@fw.wintelcom.net> Date: Mon, 21 Feb 2000 16:00:51 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Date: Sun, 20 Feb 2000 03:19:38 -0800 From: Alfred Perlstein To: fs@freebsd.org Cc: mckusick@freebsd.org Subject: changing mount options still can cause damage? Is it true that we can still cause major damage to filesystems that are moved from read-only to read-write or noasync <-> async? >From the mount manpage: -- BUGS It is possible for a corrupted file system to cause a crash. Switching a filesystem back and forth between asynchronous and normal operation or between read/write and read/only access using ``mount -u'' may gradually bring about severe filesystem corruption. -- The first bug is understandable, but personally I've never seen the second happen, is this still a real problem? If not I'd like to remove it. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Switching between read-only and read-write should never cause filesystem corruption. Running async can certainly lead to corruption if the system crashes. There is an indeterminate period of time after the system has been switched from async to sync before it will be stable again, but that period will rarely be more than a minute or two. The act of switching between sync and async should not cause corruption. It is just the inherent risk of corruption while running async. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 21 17:18:36 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C2CCB37B53D; Mon, 21 Feb 2000 17:18:33 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id RAA21012; Mon, 21 Feb 2000 17:44:44 -0800 (PST) Date: Mon, 21 Feb 2000 17:44:44 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: fs@freebsd.org, jkh@freebsd.org Subject: Re: changing mount options still can cause damage? Message-ID: <20000221174444.W21720@fw.wintelcom.net> References: <20000220031938.D21720@fw.wintelcom.net> <200002220000.QAA18690@flamingo.McKusick.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200002220000.QAA18690@flamingo.McKusick.COM>; from mckusick@flamingo.McKusick.COM on Mon, Feb 21, 2000 at 04:00:51PM -0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Kirk McKusick [000221 16:30] wrote: > Date: Sun, 20 Feb 2000 03:19:38 -0800 > From: Alfred Perlstein > To: fs@freebsd.org > Cc: mckusick@freebsd.org > Subject: changing mount options still can cause damage? > > Is it true that we can still cause major damage to filesystems that > are moved from read-only to read-write or noasync <-> async? > > >From the mount manpage: > > -- > BUGS > It is possible for a corrupted file system to cause a crash. > > Switching a filesystem back and forth between asynchronous and > normal operation or between read/write and read/only access > using ``mount -u'' may gradually bring about severe filesystem > corruption. > -- > > The first bug is understandable, but personally I've never seen the > second happen, is this still a real problem? > > If not I'd like to remove it. > > thanks, > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > Switching between read-only and read-write should never cause filesystem > corruption. Running async can certainly lead to corruption if the > system crashes. There is an indeterminate period of time after the > system has been switched from async to sync before it will be stable > again, but that period will rarely be more than a minute or two. The > act of switching between sync and async should not cause corruption. > It is just the inherent risk of corruption while running async. > > Kirk McKusick Then I vote to remove it, there's no reason we should be slandering ourselves in our own manpages, the async option already describes the dangers pretty clearly. May I axe it? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 21 17:20:44 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id DC68D37B565; Mon, 21 Feb 2000 17:20:41 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id RAA18831; Mon, 21 Feb 2000 17:16:10 -0800 (PST) Message-Id: <200002220116.RAA18831@flamingo.McKusick.COM> To: Alfred Perlstein Subject: Re: changing mount options still can cause damage? Cc: fs@freebsd.org, jkh@freebsd.org In-reply-to: Your message of "Mon, 21 Feb 2000 17:44:44 PST." <20000221174444.W21720@fw.wintelcom.net> Date: Mon, 21 Feb 2000 17:16:09 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Date: Mon, 21 Feb 2000 17:44:44 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: fs@freebsd.org, jkh@freebsd.org Subject: Re: changing mount options still can cause damage? * Kirk McKusick [000221 16:30] wrote: > > Switching between read-only and read-write should never cause filesystem > corruption. Running async can certainly lead to corruption if the > system crashes. There is an indeterminate period of time after the > system has been switched from async to sync before it will be stable > again, but that period will rarely be more than a minute or two. The > act of switching between sync and async should not cause corruption. > It is just the inherent risk of corruption while running async. > > Kirk McKusick Then I vote to remove it, there's no reason we should be slandering ourselves in our own manpages, the async option already describes the dangers pretty clearly. May I axe it? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] As far as I am concerned, you can axe it. ~Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 12:42: 5 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 5C8D437B705; Tue, 22 Feb 2000 12:41:58 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id VAA13235; Tue, 22 Feb 2000 21:41:56 +0100 (CET) (envelope-from asmodai) Date: Tue, 22 Feb 2000 21:41:56 +0100 From: Jeroen Ruigrok van der Werven To: freebsd-current@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Panic (ffs) #2 Message-ID: <20000222214156.A13189@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organisation: bART Internet Services B.V. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org And here we are again. This time on another disk: dev = #amrd/0x20004, block = 2048, fs = /news/spool panic: ffs_blkfree: freeing free block Debugger("panic") Stopped at Debugger+0x35: movb $0,in_Debugger.372 db> trace Debugger(c01e7ee3) at Debugger+0x35 panic(c01f27e0,c01f27c0,c1ccc894,800,c1d0d0d4) at panic+0x70 ffs_blkfree(c1db6d00,800,2000,0,d98cfe44) at ffs_blkfree+0x1dd ffs_indirtrunc(c1db6d00,fffffff4,10bab0,ffffffff,0,d98cfd84) at ffs_indirtrunc+0x219 ffs_truncate(d8c79da0,0,0,0,c1d4d700) at ffs_truncate+0x6fd ufs_setattr(d98cfec8,d98cff3c,c0171857,d98cfec8,d98b52a0) at ufs_setattr+0x1ce ufs_vnoperate(d98cfec8,d98b52a0,c0206bac,d98cff80,d8c79da0) at ufs_vnoperate+0x15 ftruncate(d98b52a0,d98cff80,8098900,bfbff608,bfbf741f) at ftruncate+0x113 syscall(2f,280a002f,bfbf002f,bfbf741f,bfbff608) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x26 Dumping the 512 MB to disk now. See my previous Panic (ffs) mail on CURRENT for a almost exact problem. No soft-updates. Two different disks on two different controllers now. Current from 21 Feb. -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 12:54:33 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (Postfix) with ESMTP id C472037B78B; Tue, 22 Feb 2000 12:54:28 -0800 (PST) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id PAA21722; Tue, 22 Feb 2000 15:54:23 -0500 (EST) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id PAA08695; Tue, 22 Feb 2000 15:54:21 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.9.3/8.6.9) id PAA87131; Tue, 22 Feb 2000 15:54:21 -0500 (EST) Date: Tue, 22 Feb 2000 15:54:21 -0500 (EST) From: Thomas David Rivers Message-Id: <200002222054.PAA87131@lakes.dignus.com> To: asmodai@bart.nl, freebsd-current@FreeBSD.ORG Subject: Re: Panic (ffs) #2 Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <20000222214156.A13189@lucifer.bart.nl> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > And here we are again. > > This time on another disk: > > dev = #amrd/0x20004, block = 2048, fs = /news/spool > panic: ffs_blkfree: freeing free block > Debugger("panic") > Stopped at Debugger+0x35: movb $0,in_Debugger.372 > db> trace > Debugger(c01e7ee3) at Debugger+0x35 > panic(c01f27e0,c01f27c0,c1ccc894,800,c1d0d0d4) at panic+0x70 > ffs_blkfree(c1db6d00,800,2000,0,d98cfe44) at ffs_blkfree+0x1dd Aha! The Dave Rivers' memorial panic rears its ugly head! This is exactly the panic's I reported years ago; but we've never been able to track down... [Even the same block number I believe] You may want to scan the archives to read more about my investigations; which never went anywhere... (sigh) I describe a way to reproduce it on some versions of FreeBSD, you might want to see if you can get a reliable reproduction, etc... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 13:56:17 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id D14B237B747; Tue, 22 Feb 2000 13:55:51 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id WAA13862; Tue, 22 Feb 2000 22:55:43 +0100 (CET) (envelope-from asmodai) Date: Tue, 22 Feb 2000 22:55:43 +0100 From: Jeroen Ruigrok van der Werven To: Thomas David Rivers Cc: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Panic (ffs) #2 Message-ID: <20000222225542.A13664@lucifer.bart.nl> References: <20000222214156.A13189@lucifer.bart.nl> <200002222054.PAA87131@lakes.dignus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200002222054.PAA87131@lakes.dignus.com>; from rivers@dignus.com on Tue, Feb 22, 2000 at 03:54:21PM -0500 Organisation: bART Internet Services B.V. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000222 21:55], Thomas David Rivers (rivers@dignus.com) wrote: >> >> And here we are again. >> >> This time on another disk: >> >> dev = #amrd/0x20004, block = 2048, fs = /news/spool >> panic: ffs_blkfree: freeing free block >> Debugger("panic") >> Stopped at Debugger+0x35: movb $0,in_Debugger.372 >> db> trace >> Debugger(c01e7ee3) at Debugger+0x35 >> panic(c01f27e0,c01f27c0,c1ccc894,800,c1d0d0d4) at panic+0x70 >> ffs_blkfree(c1db6d00,800,2000,0,d98cfe44) at ffs_blkfree+0x1dd > > Aha! The Dave Rivers' memorial panic rears its ugly head! > > This is exactly the panic's I reported years ago; but we've never > been able to track down... [Even the same block number I believe] Well, at this rate I can drop debugs on the lists at a rate of one per day. > You may want to scan the archives to read more about my investigations; If they were up. Thank god I have some personal archives... Hope I'll get some info from them. > which never went anywhere... (sigh) I describe a way to reproduce > it on some versions of FreeBSD, you might want to see if you can > get a reliable reproduction, etc... Hah, reliable reproduction, try to let the box stay up for a day or two, bang. So far in this existance of the box, I have had 4 ffs panics and 1 tcp... If this were a debug box I'd say ok, well cool... But this is in fact a machine so close to the RC of 4.0 that I am not sure I want to run production servers on it. Add to that mix that I am a b-rated coder, just learning about gdb, and on filesystem level and even dumber than (insert locally dumb idiot here). Then the logical step might be to say, well, then the hardware must be faulty... No way Jose... I have tested this box in every way possible, even detected incorrect CAS/RAS latency settings on the box in the BIOS for the memory. Anyways: [root@tyr] (4) # gdb -k /kernel.debug vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 2625536 initial pcb at 21c9e0 panicstr: from debugger panic messages: --- panic: ffs_blkfree: freeing free block panic: from debugger Uptime: 39m4s amrd0: still open, can't shutdown dumping to dev #da/0x20001, offset 524312 dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 ! 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:304 #1 0xc0143d61 in panic (fmt=0xc01e27f4 "from debugger") at ../../kern/kern_shutdown.c:554 #2 0xc01244e1 in db_panic (addr=-1071886047, have_addr=0, count=-1, modif=0xd8b7fb88 "") at ../../ddb/db_command.c:433 #3 0xc0124481 in db_command (last_cmdp=0xc02042fc, cmd_table=0xc020415c, aux_cmd_tablep=0xc021905c) at ../../ddb/db_command.c:333 #4 0xc0124546 in db_command_loop () at ../../ddb/db_command.c:455 #5 0xc012665f in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71 #6 0xc01c4ec5 in kdb_trap (type=3, code=0, regs=0xd8b7fc90) at ../../i386/i386/db_interface.c:158 #7 0xc01d05f4 in trap (frame={tf_fs = -1072431088, tf_es = -701956080, tf_ds = -701956080, tf_edi = -838037504, tf_esi = 256, tf_ebp = -659030824, tf_isp = -659030852, tf_ebx = -1071700000, tf_edx = 0, tf_ecx = 1021, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071886047, tf_cs = 8, tf_eflags = 582, tf_esp = -1071668385, tf_ss = -1071743261}) at ../../i386/i386/trap.c:549 #8 0xc01c5121 in Debugger (msg=0xc01e7ee3 "panic") at machine/cpufunc.h:64 #9 0xc0143d58 in panic (fmt=0xc01f27e0 "ffs_blkfree: freeing free block") at ../../kern/kern_shutdown.c:552 #10 0xc0195c61 in ffs_blkfree (ip=0xc1d92200, bno=6560, size=8192) at ../../ufs/ffs/ffs_alloc.c:1337 #11 0xc0197be1 in ffs_truncate (vp=0xd8d11fe0, length=0, flags=0, cred=0x0, p=0xd8b320c0) at ../../ufs/ffs/ffs_inode.c:337 #12 0xc019c8e6 in ufs_inactive (ap=0xd8b7feb8) at ../../ufs/ufs/ufs_inode.c:84 #13 0xc01a1985 in ufs_vnoperate (ap=0xd8b7feb8) at ../../ufs/ufs/ufs_vnops.c:2283 #14 0xc016d0ae in vput (vp=0xd8d11fe0) at vnode_if.h:794 #15 0xc01703b9 in unlink (p=0xd8b320c0, uap=0xd8b7ff80) at ../../kern/vfs_syscalls.c:1421 #16 0xc01d0e96 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = 134721536, tf_ebp = -1077945076, tf_isp = -659030060, tf_ebx = 134750720, tf_edx = 134750812, tf_ecx = 0, tf_eax = 10, tf_trapno = 7, tf_err = 2, tf_eip = 134533504, tf_cs = 31, tf_eflags = 647, tf_esp = -1077945120, tf_ss = 47}) at ../../i386/i386/trap.c:1073 #17 0xc01c57c6 in Xint0x80_syscall () #18 0x80482c3 in ?? () #19 0x80480f9 in ?? () (kgdb) up 10 #10 0xc0195c61 in ffs_blkfree (ip=0xc1d92200, bno=6560, size=8192) at ../../ufs/ffs/ffs_alloc.c:1337 1337 panic("ffs_blkfree: freeing free block"); More info will be coming shortly... As usual, advice, hints, tips (on how to maintain my sanity for example) are highly appreciated. -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands el: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 14:55: 3 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id EA8C437B574; Tue, 22 Feb 2000 14:54:57 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id XAA14248; Tue, 22 Feb 2000 23:54:53 +0100 (CET) (envelope-from asmodai) Date: Tue, 22 Feb 2000 23:54:53 +0100 From: Jeroen Ruigrok van der Werven To: Thomas David Rivers Cc: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Panic (ffs) #2 Message-ID: <20000222235453.A14224@lucifer.bart.nl> References: <20000222214156.A13189@lucifer.bart.nl> <200002222054.PAA87131@lakes.dignus.com> <20000222225542.A13664@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000222225542.A13664@lucifer.bart.nl>; from asmodai@bart.nl on Tue, Feb 22, 2000 at 10:55:43PM +0100 Organisation: bART Internet Services B.V. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org *sigh* ignore the gdb output of this one... it was the old one. =( /var/crash was too full. -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 18:31:31 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id D966837B889; Tue, 22 Feb 2000 18:31:24 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA20265; Tue, 22 Feb 2000 19:30:52 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpdAAAfraGGN; Tue Feb 22 19:30:47 2000 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id TAA27823; Tue, 22 Feb 2000 19:30:44 -0700 (MST) From: Terry Lambert Message-Id: <200002230230.TAA27823@usr07.primenet.com> Subject: Re: changing mount options still can cause damage? To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Date: Wed, 23 Feb 2000 02:30:44 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein), fs@FreeBSD.ORG, jkh@FreeBSD.ORG In-Reply-To: <200002220116.RAA18831@flamingo.McKusick.COM> from "Kirk McKusick" at Feb 21, 2000 05:16:09 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > * Kirk McKusick [000221 16:30] wrote: > > Switching between read-only and read-write should never cause filesystem > > corruption. Running async can certainly lead to corruption if the > > system crashes. There is an indeterminate period of time after the > > system has been switched from async to sync before it will be stable > > again, but that period will rarely be more than a minute or two. The > > act of switching between sync and async should not cause corruption. > > It is just the inherent risk of corruption while running async. > > > > Kirk McKusick > > Then I vote to remove it, there's no reason we should be slandering > ourselves in our own manpages, the async option already describes > the dangers pretty clearly. > > May I axe it? > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > As far as I am concerned, you can axe it. > > ~Kirk If you do, the information will no longer be correct. Kirk said that: There is an indeterminate period of time after the system has been switched from async to sync before it will be stable again, but that period will rarely be more than a minute or two. But he didn't say why. The problem is that the vnodes containing the buffer cache for the devices themselves contain dirty data which has not been written out. Even if the filesystem was sync'ed out (it is), this dirty data can be a problem, if you switched from read-write to read-only, particularly, if you then crash, with the clean bit set in the superblock, but dirty buffers applicable to the FS still hanging around. This is really part and parcel with the stacking layer backing object cache coherency problem, which comes from the cached data on the underlying FS being clean and the upper level stuff being dirty: an inversion of the backing device vnode problem. I think you should correct the man page, noting the actual cause of the problem, rather than nuking it and making people think that life is all rosy, and that there isn't a bugaboo waiting to bite them on the arse. We haven't lied to people about async being dangerous in the past, we shouldn't lie to them about switching from read/write to read-only being dangerous for other reasons, either. Ideally, we would force a sync to have completed before returning, and force all the buffers out. This incoherency, incidently, is the same reason you have to unmount, tune, and remount to enable soft updates. I think that we could perhaps resolve this by suggesting a workaround of an unmount of the read/write, followed by a mount of the read-only, at least until the underlying update code is changed to be upper level code that calls the unmount/mount primitives itself. The reason it is as it is appears to be to enable update mounts in cases where file or directory handles are currently open and thus need to (A) survive across the update and (B) not prevent the update because the filesystem is considered "busy". This could probably be fixed by making the unmount in the unmount/mount sequence take an argument of "with intent to remount", or even "and then remount" (making it call the mount for remounting itself). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 18:45: 2 2000 Delivered-To: freebsd-fs@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id 14A8537B849; Tue, 22 Feb 2000 18:44:59 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id SAA22016; Tue, 22 Feb 2000 18:32:25 -0800 (PST) Message-Id: <200002230232.SAA22016@flamingo.McKusick.COM> To: Terry Lambert Subject: Re: changing mount options still can cause damage? Cc: bright@wintelcom.net (Alfred Perlstein), fs@freebsd.org, jkh@freebsd.org In-reply-to: Your message of "Wed, 23 Feb 2000 02:30:44 GMT." <200002230230.TAA27823@usr07.primenet.com> Date: Tue, 22 Feb 2000 18:32:25 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A downgrade from read-write to read-only does a complete flush of the filesystem before setting the clean bit in the superblock. So, even if you have been running async before or even during the period that you do the downgrade to read-only, you will not trash the filesystem. I do not believe that you are lying to anybody by deleting the commentary about cycling between read-only and read-write. Appropriate warnings about async are called for, however the only warning necessary about cycling between sync and async is that the danger of async does not go away for several minutes after you have cycled to sync. ~Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 22 20:17:14 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CB66937B7C2; Tue, 22 Feb 2000 20:17:02 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id UAA02433; Tue, 22 Feb 2000 20:46:11 -0800 (PST) Date: Tue, 22 Feb 2000 20:46:11 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: Terry Lambert , fs@freebsd.org, jkh@freebsd.org Subject: Re: changing mount options still can cause damage? Message-ID: <20000222204610.I21720@fw.wintelcom.net> References: <200002230230.TAA27823@usr07.primenet.com> <200002230232.SAA22016@flamingo.McKusick.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200002230232.SAA22016@flamingo.McKusick.COM>; from mckusick@flamingo.McKusick.COM on Tue, Feb 22, 2000 at 06:32:25PM -0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Kirk McKusick [000222 19:14] wrote: > A downgrade from read-write to read-only does a complete flush > of the filesystem before setting the clean bit in the superblock. > So, even if you have been running async before or even during > the period that you do the downgrade to read-only, you will > not trash the filesystem. I do not believe that you are lying > to anybody by deleting the commentary about cycling between > read-only and read-write. Appropriate warnings about async are > called for, however the only warning necessary about cycling > between sync and async is that the danger of async does not > go away for several minutes after you have cycled to sync. > > ~Kirk You're saying the exact opposite of what Bruce and Luoqi said, they both say that updating the mount from async -> noasync/sync is safe because of the flush_files call. Looking at the code you seem right... ("ffs/ffs_vfsops.c" line 186 of 1283) if (mp->mnt_flag & MNT_UPDATE) { ump = VFSTOUFS(mp); fs = ump->um_fs; devvp = ump->um_devvp; err = 0; ronly = fs->fs_ronly; /* MNT_RELOAD might change this */ if (ronly == 0 && (mp->mnt_flag & MNT_RDONLY)) { flags = WRITECLOSE; if (mp->mnt_flag & MNT_FORCE) flags |= FORCECLOSE; if (mp->mnt_flag & MNT_SOFTDEP) { err = softdep_flushfiles(mp, flags, p); } else { err = ffs_flushfiles(mp, flags, p); } ronly = 1; } It sure looks like it forces the structures to disk because ffs_flushfiles calls VOP_FSYNC on the filesystem dev vp. Which I would assume fixes up link counts for inodes possibly opened, but deleted before the the filesystem is set to read-only. ufs_close calls ufs_itimes which avoids attempting to update the inode access time if the fs is readonly, so does ufs_inactive. However the async -> noasync/sync doesn't do the same (fsync the device vp), shouldn't it, and if it did, wouldn't that fix the problem? It's not like doing a fsync on the whole filesystem at that point would be a common occurance. I think you're correct however I'm assuming you've seen the case brought up by Bruce and Luoqi, specifically the unlink and downgrade to read-only. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 23 6:36:35 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 011C437B8C5; Wed, 23 Feb 2000 06:36:31 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id PAA21449; Wed, 23 Feb 2000 15:36:29 +0100 (CET) (envelope-from asmodai) Date: Wed, 23 Feb 2000 15:36:29 +0100 From: Jeroen Ruigrok van der Werven To: freebsd-current@freebsd.org Cc: freebsd-fs@freebsd.org, mckusick@freebsd.org Subject: Panic #3 (ffs) Message-ID: <20000223153629.H18964@lucifer.bart.nl> Reply-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organisation: bART Internet Services B.V. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org *sigh* I think I am going to give up my job and become a buddhist monk... start = 0, len = 2646, fs = /news panic: ffs_alloccg: map corrupted Debugger("panic") Stopped at Debugger+0x35: movb $0,in_Debugger.372 db> trace Debugger(c01e7ee3) at Debugger+0x35 panic(c01f28bf,c01f28a0,0,a56,c1d0d8d4) at panic+0x70 ffs_mapsearch(c1d0d800,ccd49000,5d2a8,1,b) at ffs_mapsearch+0x143 ffs_alloccg(c1da7700,b,5d2a8,400) at ffs_alloccg+0x21a ffs_hashalloc(c1da7700,b,5d2a8,400,c0194cb8) at ffs_hashalloc+0x23 ffs_alloc(c1da7700,b,5d2a8,400,c1d38280) at ffs_alloc+0xad ffs_balloc(d8a1ce68,d8a4c200,c1d6a180,3,d8b74ba0) at ffs_balloc+0x456 ffs_write(d8a1cea0,d6299a80,4c,c1d6a180,c0201d00) at ffs_write+0x319 vn_write(c1d6a180,d8a1ceec,c1d38280,0,d6299a80) at vn_write+0xda dofilewrite(d6299a80,c1d6a180,18,280c4000,4c) at dofilewrite+0x91 write(d6299a80,d8a1cf80,280ad140,280ad140,280c404d) at write+0x33 syscall(280c002f,280a002f,bfbf002f,280c404d,280ad140) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x26 -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 23 11:30:49 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 4917E37B9D2 for ; Wed, 23 Feb 2000 11:30:39 -0800 (PST) (envelope-from karsten@rohrbach.de) Received: (qmail 2451 invoked by uid 1000); 23 Feb 2000 19:30:37 -0000 Date: Wed, 23 Feb 2000 20:30:37 +0100 From: "Karsten W. Rohrbach" To: freebsd-current@FreeBSD.ORG, asmodai@bart.nl Cc: freebsd-fs@FreeBSD.ORG, mckusick@FreeBSD.ORG Subject: Re: Panic #3 (ffs) Message-ID: <20000223203037.A2298@rohrbach.de> Reply-To: karsten@rohrbach.de References: <20000223153629.H18964@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000223153629.H18964@lucifer.bart.nl>; from asmodai@bart.nl on Wed, Feb 23, 2000 at 03:36:29PM +0100 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org which megaraid adapter do you use in this box (hw, fw ver, bios ver, cntl-m ver)... i've seen those panics on our old news box when there where errors on the scsi busses which did not get detected properly. mainly termination issues *sigh* /k Jeroen Ruigrok van der Werven(asmodai@bart.nl)@Wed, Feb 23, 2000 at 03:36:29PM +0100: > *sigh* > > I think I am going to give up my job and become a buddhist monk... > > start = 0, len = 2646, fs = /news > panic: ffs_alloccg: map corrupted > Debugger("panic") > Stopped at Debugger+0x35: movb $0,in_Debugger.372 > db> trace > Debugger(c01e7ee3) at Debugger+0x35 > panic(c01f28bf,c01f28a0,0,a56,c1d0d8d4) at panic+0x70 > ffs_mapsearch(c1d0d800,ccd49000,5d2a8,1,b) at ffs_mapsearch+0x143 > ffs_alloccg(c1da7700,b,5d2a8,400) at ffs_alloccg+0x21a > ffs_hashalloc(c1da7700,b,5d2a8,400,c0194cb8) at ffs_hashalloc+0x23 > ffs_alloc(c1da7700,b,5d2a8,400,c1d38280) at ffs_alloc+0xad > ffs_balloc(d8a1ce68,d8a4c200,c1d6a180,3,d8b74ba0) at ffs_balloc+0x456 > ffs_write(d8a1cea0,d6299a80,4c,c1d6a180,c0201d00) at ffs_write+0x319 > vn_write(c1d6a180,d8a1ceec,c1d38280,0,d6299a80) at vn_write+0xda > dofilewrite(d6299a80,c1d6a180,18,280c4000,4c) at dofilewrite+0x91 > write(d6299a80,d8a1cf80,280ad140,280ad140,280c404d) at write+0x33 > syscall(280c002f,280a002f,bfbf002f,280c404d,280ad140) at syscall+0x176 > Xint0x80_syscall() at Xint0x80_syscall+0x26 > > -- > Jeroen Ruigrok van der Werven Network- and systemadministrator > bART Internet Services / > BSD: Technical excellence at its best VIA NET.WORKS Netherlands > Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- > Hugh Hefner is a virgin. http://www.webmonster.de http://www.apache.de http://www.splatterworld.de (NIC-HDL KR433/KR11-RIPE) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 23 11:38: 6 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id CAD7237B908; Wed, 23 Feb 2000 11:38:01 -0800 (PST) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id UAA24256; Wed, 23 Feb 2000 20:37:55 +0100 (CET) (envelope-from asmodai) Date: Wed, 23 Feb 2000 20:37:55 +0100 From: Jeroen Ruigrok van der Werven To: "Karsten W. Rohrbach" Cc: freebsd-current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG, mckusick@FreeBSD.ORG Subject: Re: Panic #3 (ffs) Message-ID: <20000223203755.A24240@lucifer.bart.nl> References: <20000223153629.H18964@lucifer.bart.nl> <20000223203037.A2298@rohrbach.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000223203037.A2298@rohrbach.de>; from karsten@rohrbach.de on Wed, Feb 23, 2000 at 08:30:37PM +0100 Organisation: bART Internet Services B.V. Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000223 20:35], Karsten W. Rohrbach (karsten@rohrbach.de) wrote: >which megaraid adapter do you use in this box (hw, fw ver, bios ver, >cntl-m ver)... > >i've seen those panics on our old news box when there where errors on >the scsi busses which did not get detected properly. mainly termination >issues *sigh* amr0: mem 0xe3000000-0xe300ffff irq 10 at device 10.1 on pci0 amr0: firmware EH61 bios 1.31 16MB memory amrd0: on amr0 amrd0: 35040MB (71761920 sectors) RAID 0 (optimal) And I receive the panics on BOTH the array and the normal da disks. I know the termination is correct. -- Jeroen Ruigrok van der Werven Network- and systemadministrator bART Internet Services / BSD: Technical excellence at its best VIA NET.WORKS Netherlands Tel: +31 - (0) 10 - 240 39 70 http://www.bart.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 24 5:58:40 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B8F6837BBC4; Thu, 24 Feb 2000 05:58:29 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA12804; Fri, 25 Feb 2000 01:02:06 +1100 Date: Fri, 25 Feb 2000 00:57:42 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Alfred Perlstein Cc: Kirk McKusick , Terry Lambert , fs@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: changing mount options still can cause damage? In-Reply-To: <20000222204610.I21720@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 22 Feb 2000, Alfred Perlstein wrote: > * Kirk McKusick [000222 19:14] wrote: > > ... Appropriate warnings about async are > > called for, however the only warning necessary about cycling > > between sync and async is that the danger of async does not > > go away for several minutes after you have cycled to sync. > > > > ~Kirk > > You're saying the exact opposite of what Bruce and Luoqi said, > they both say that updating the mount from async -> noasync/sync > is safe because of the flush_files call. > > Looking at the code you seem right... > However the async -> noasync/sync doesn't do the same (fsync the > device vp), shouldn't it, and if it did, wouldn't that fix the > problem? It's not like doing a fsync on the whole filesystem > at that point would be a common occurance. Copying the code in sync() and changing MNT_NOWAIT to MNT_WAIT in it should work, modulo locking problems. This applies to both async -> noasync and nosync -> sync. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Feb 26 23:28:35 2000 Delivered-To: freebsd-fs@freebsd.org Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148]) by hub.freebsd.org (Postfix) with ESMTP id BD70B37B5EC; Sat, 26 Feb 2000 23:28:26 -0800 (PST) (envelope-from julian@elischer.org) Received: from jules.elischer.org (reggae-02-150.nv.iinet.net.au [203.59.91.150]) by popserver-02.iinet.net.au (8.9.3/8.9.3) with SMTP id PAA32228; Sun, 27 Feb 2000 15:28:52 +0800 Message-ID: <38B8D0DE.167EB0E7@elischer.org> Date: Sat, 26 Feb 2000 23:23:10 -0800 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 4.0-CURRENT i386) MIME-Version: 1.0 To: fs@freebsd.org Cc: current@freebsd.org Subject: UDF/DVD support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have been hired to add UDF/DVD-R support to FreeBSD I will be spending the next few weeks basically doing research but would like to hear from anyone who is already working in these areas. This may impact un the following areas: SCSI subsystem ATA subsystem Filesystems Raw/Block(sic) device interface Encryption/security stuff. Julian -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message