From owner-freebsd-fs@FreeBSD.ORG Sun Oct 24 00:59:00 2004 Return-Path: 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 D5D6C16A4CE for ; Sun, 24 Oct 2004 00:59:00 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FAFA43D41 for ; Sun, 24 Oct 2004 00:59:00 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [127.0.0.1] (i-99.forrie.net. [192.168.1.99]) by forrie.com with ESMTP id i9O0wpv5085364 for ; Sat, 23 Oct 2004 20:58:54 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <417AFE26.6040205@forrie.com> Date: Sat, 23 Oct 2004 20:58:14 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 0.8 (Windows/20041023) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: XFS for FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 00:59:00 -0000 I've been able to locate some postings that suggested there was an effort to get SGI's XFS ported to FreeBSD -- along with some concerns about licensing (GPL) issues. I'd like to get more information - is there an official project, who's heading it up, etc. etc. Thanks. From owner-freebsd-fs@FreeBSD.ORG Sun Oct 24 01:18:57 2004 Return-Path: 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 13BC916A4F4 for ; Sun, 24 Oct 2004 01:18:57 +0000 (GMT) Received: from f15.mail.ru (f15.mail.ru [194.67.57.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94EFF43D39 for ; Sun, 24 Oct 2004 01:18:56 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f15.mail.ru with local id 1CLX26-000OtR-00; Sun, 24 Oct 2004 05:18:54 +0400 Received: from [24.184.136.70] by win.mail.ru with HTTP; Sun, 24 Oct 2004 05:18:54 +0400 From: Igor Shmukler To: Forrest Aldrich Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.184.136.70] Date: Sun, 24 Oct 2004 05:18:54 +0400 In-Reply-To: <417AFE26.6040205@forrie.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-fs@freebsd.org Subject: Re: XFS for FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 01:18:57 -0000 It's always a good idea to search the archives. I used google. http://lists.freebsd.org/pipermail/freebsd-current/2003-July/005999.html This thread is probably where you want to start. -----Original Message----- From: Forrest Aldrich To: freebsd-fs@freebsd.org Date: Sat, 23 Oct 2004 20:58:14 -0400 Subject: XFS for FreeBSD > > I've been able to locate some postings that suggested there was an > effort to get SGI's XFS ported to FreeBSD -- along with some concerns > about licensing (GPL) issues. > > I'd like to get more information - is there an official project, who's > heading it up, etc. etc. > > > > Thanks. > > > > > _______________________________________________ > 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" > úÁ×ÅÄÉ ÓÅÂÅ ÑÝÉË ÎÁ Mail.ru É ×ÙÉÇÒÁÊ 2 Á×ÔÏÍÏÂÉÌÑ http://20mln.mail.ru From owner-freebsd-fs@FreeBSD.ORG Sun Oct 24 15:43:48 2004 Return-Path: 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 7E42316A4CE for ; Sun, 24 Oct 2004 15:43:48 +0000 (GMT) Received: from mail.cableone.net (scanmail2.cableone.net [24.116.0.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC3643D2F for ; Sun, 24 Oct 2004 15:43:48 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.24-119-122-191.cpe.cableone.net (unverified [24.119.122.25]) by smail2.cableone.net (SurgeMail 1.9b) with ESMTP id 23356900 for multiple; Sun, 24 Oct 2004 08:42:24 -0700 Date: Sun, 24 Oct 2004 10:43:04 -0500 From: Vulpes Velox To: "Marc G. Fournier" Message-ID: <20041024104304.1620e1ab@vixen42.24-119-122-191.cpe.cableone.net> In-Reply-To: <20041023113958.X16873@ganymede.hub.org> References: <20041022174052.4a203268@fennec> <20041023113958.X16873@ganymede.hub.org> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com cc: freebsd-fs@freebsd.org Subject: Re: Unionfs and nullfs question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2004 15:43:48 -0000 On Sat, 23 Oct 2004 11:47:57 -0300 (ADT) "Marc G. Fournier" wrote: > On Fri, 22 Oct 2004, Vulpes Velox wrote: > > > I am guessing the answer, given the big warning in the man for > > both is that this is going to be a no that both are dangerous to > > the data and luck is mainly involved in not having the data > > screwed over, but just wanna check :) > > I run over 200 VPSs over 4 machines with all application data > (installed ports) mounted through unionfs to reduce disk space usage > ... every once in a blue moon, I'll get a crash resulting from a bug > in the unionfs code, but it isn't as bad as it was, say, a year ago > ... but I am running production servers with it. > > There are a few things you can't do right now ... for instance, I > don't have /var union mounted, as FIFO's/sockets tend to > consistently blow it up ... but, my more loaded server looks like: > > # df -t union | wc -l > 73 > # uptime > 11:41AM up 47 days, 22:25, 1 user, load averages: 12.12, 20.67, > 22.46 > > There is an annoying 'bug' in fsck that Don Lewis has been working > on correcting that is very exasperated by unionfs ... namely how the > list of inodes to check is generated. If you, for instance, mount a > blank file systems over top of /usr/ports, and then do a find of > /usr/ports, the blank file system will fill up with a bunch of > directories to 'mirror' ports ... the files don't come through, only > the directories. On a crash, the OS leaves behind a bunch of ZERO > LENGTH DIRECTORIES ... I've had fsck run for 12-14hrs after one of > these, its that messy :( Don has been working on a patch to handle > the ZLDs better, but it hasn't been committed to -stable yet, > pending more testing ... I'm running it live here, but *knock on > wood* haven't had a crash since putting it into place ... Cool, thanks for the info. I eventually decided to go with doing a mount_nfs -o union for it :) >From one of the conversations I found previously, this is suppose to be safer than doing doing a regular mount_unionfs. From owner-freebsd-fs@FreeBSD.ORG Mon Oct 25 00:22:31 2004 Return-Path: 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 BF67E16A4CE for ; Mon, 25 Oct 2004 00:22:31 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 2530843D5E for ; Mon, 25 Oct 2004 00:22:28 +0000 (GMT) (envelope-from lists-freebsd-questions@biaix.org) Received: (qmail 36834 invoked by uid 1000); 25 Oct 2004 00:20:08 -0000 Date: Mon, 25 Oct 2004 02:20:08 +0200 From: Joan Picanyol To: freebsd-stable@freebsd.org Message-ID: <20041025002008.GA36161@grummit.biaix.org> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: freebsd-fs@freebsd.org cc: freebsd-net@freebsd.org Subject: process stuck in nfsfsync state X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 00:22:31 -0000 [please honour Mail-Followup-To:, no need to keep the crosspost] This is a repost of http://docs.FreeBSD.org/cgi/mid.cgi?20041014110752.GA57541, with some additional information. I've updated the client to RC1, and the problem still persists. In short, a 5.3-RC1 client mounting /home off a 4.10-p3 server can't use the NFS fs anymore when trying to start GNOME, since gconfd and gnome-session are in nfsfsync state. Any process accessing the fs hungs, and the console gets full of nfs server grummit:/fs/home/mount: not responding messages, even though the client can still ping the server and other mount points are still available. AFAICT, nfsd and friends are running both on the client and the server, and the client can use RPC properly (checked via rpcinfo). Also, doing 'tcpdump -vv -s 192 port nfs' on the client and the server seems support the hypothesis of a locking issue, since I see a write request for the same fh repeating over and over. The trace of gnome-session is as follows: db> tr 610 sched_switch(c180b4b0,0,1,11d,27b8ea4) at sched_switch+0x190 mi_switch(1,0,c063d701,19d,2) at mi_switch+0x2ac sleepq_switch(c216d23c,c0639f0f,18e,2,da518a5c) at sleepq_switch+0x134 sleepq_wait(c216d23c,0,c063b2f5,db,0) at sleepq_wait+0x41 msleep(c216d23c,c216d210,4d,c1906703,0) at msleep+0x3b5 nfs_flush(c216d210,c17fed00,1,c180b4b0,0) at nfs_flush+0x961 nfs_close(da518b8c,1,c0643a5e,140,c0681da0) at nfs_close+0x7e vn_close(c216d210,2,c17fed00,c180b4b0,c0692c20) at vn_close+0x67 vn_closefile(c1c2b6e8,c180b4b0,c0637a98,829,c1c2b6e8) at vn_closefile+0xc4 fdrop_locked(c1c2b6e8,c180b4b0,c0637a98,768) at fdrop_locked+0xb4 fdrop(c1c2b6e8,c180b4b0,3,c180b4b0,da518c98) at fdrop+0x3c closef(c1c2b6e8,c180b4b0,c0637a98,3e3,0) at closef+0x21c close(c180b4b0,da518d14,4,431,1) at close+0x135 syscall(2f,2f,2f,0,28d38ec0) at syscall+0x272 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x28ca1e6f, esp = 0xbfbfe52c, ebp = 0xbfbfe538 --- I have a debugging kernel and a console attached, feel free to ask for any other information of interest. This is driving me nuts, and I'm surely not the only one using GNOME over NFS, is anyone else seeing this? What exactly is going on? How can I fix it? It might be that the problem appeared going from BETA3 to BETA6, but I've been unable to "downgrade" the workstation; where can I get a copy of BETA3 to test this? tks -- pica From owner-freebsd-fs@FreeBSD.ORG Mon Oct 25 20:09:11 2004 Return-Path: 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 9A45016A4CE for ; Mon, 25 Oct 2004 20:09:11 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ECA643D3F for ; Mon, 25 Oct 2004 20:09:11 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 2FE1712AE5A; Mon, 25 Oct 2004 17:09:08 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 62361-04; Mon, 25 Oct 2004 20:09:08 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by hub.org (Postfix) with ESMTP id C95C512ADDE; Mon, 25 Oct 2004 17:09:07 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id A610139903; Mon, 25 Oct 2004 17:09:09 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 9B72537F43; Mon, 25 Oct 2004 17:09:09 -0300 (ADT) Date: Mon, 25 Oct 2004 17:09:09 -0300 (ADT) From: "Marc G. Fournier" To: Vulpes Velox In-Reply-To: <20041024104304.1620e1ab@vixen42.24-119-122-191.cpe.cableone.net> Message-ID: <20041025170823.J872@ganymede.hub.org> References: <20041022174052.4a203268@fennec> <20041023113958.X16873@ganymede.hub.org> <20041024104304.1620e1ab@vixen42.24-119-122-191.cpe.cableone.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org cc: freebsd-fs@freebsd.org Subject: Re: Unionfs and nullfs question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 20:09:11 -0000 On Sun, 24 Oct 2004, Vulpes Velox wrote: > I eventually decided to go with doing a mount_nfs -o union for it :) > From one of the conversations I found previously, this is suppose to be > safer than doing doing a regular mount_unionfs. I use nfs to 'replace' nullfs for viewing the lower file system of unionfs's ... I find that, under load, I get *alot* of timeouts of the nfs mounts, with 4 nfsd's running ... something you might want to watch out for ... > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 10:03:45 2004 Return-Path: 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 39FCB16A4CF for ; Tue, 26 Oct 2004 10:03:45 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5351443D1F for ; Tue, 26 Oct 2004 10:03:44 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (net.stencil.kaluga.ru [62.148.158.62]) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9QA3dnn021676 for ; Tue, 26 Oct 2004 14:03:41 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.581) sender ; 26 Oct 2004 14:03:41 +0400 Date: Tue, 26 Oct 2004 14:03:39 +0400 From: Pavel Merdine X-Priority: 3 (Normal) Message-ID: <1038372273.20041026140339@merdin.com> To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 10:03:45 -0000 Hello, I'd like to start discussions about panic and fs over again. Since yesterday one of our servers is periodically being hit by various panics. It seems that it relates to only one partition. I thought maybe it's a faulty HDD and copied the content to another HDD. I done it using dd. After one hour the server had panic again: Oct 26 05:11:54 images8 /kernel: mode = 040700, inum = 2382, fs = /mountpount Oct 26 05:11:54 images8 /kernel: panic: ffs_valloc: dup alloc Oct 26 05:11:54 images8 /kernel: Oct 26 05:11:54 images8 /kernel: syncing disks... 49 12 Oct 26 05:11:54 images8 /kernel: done Dispite the line "syncing disks", all disks were not clean after reboot: Oct 26 05:11:56 images8 /kernel: WARNING: R/W mount of /mountp denied. Filesystem is not clean - run fsck I do not mount with -f because softupdates didn't show good results and made system panic more and more times. My question is: Is there any future in FFS, it's panics and non-working softupdates? I dont see any reliability in such system. But what I remember is high reliability of MS NTFS. I didn't see any disk checks after any failure and I didn't experience a file loss. And I didn't see it's popular "blue screen" with an error caused by filesystem code. I think that FreeBSD has no future without a reliable FS and clean code for it. BTW: We user FreeBSD 4.10, I talk about IDE drives. I tried to switch IDE write cache off, but ffs does not work better. Sorry if I wrote too long letter. Our company is just tired of the problems related to all of this. And, by the way, FFS code still have a divide by integer error in dirpref(). I tried to report it two times, I saw it reported in lists, but nobody cares :( . No future. -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 16:36:26 2004 Return-Path: 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 3CD2916A4CF for ; Tue, 26 Oct 2004 16:36:26 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id CE29943D39 for ; Tue, 26 Oct 2004 16:36:18 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 37280 invoked by uid 0); 26 Oct 2004 16:31:17 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 26 Oct 2004 16:31:17 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 1D159130D7B; Wed, 27 Oct 2004 00:36:14 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02249-05; Wed, 27 Oct 2004 00:36:03 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id DB6CF133C3F; Wed, 27 Oct 2004 00:36:01 +0800 (CST) Date: Wed, 27 Oct 2004 00:36:01 +0800 From: Xin LI To: Pavel Merdine Message-ID: <20041026163601.GA2172@frontfree.net> References: <1038372273.20041026140339@merdin.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <1038372273.20041026140339@merdin.com> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #11: Tue Oct 26 14:12:03 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-fs@freebsd.org Subject: Re: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 16:36:26 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Pavel, First off, I'm sorry to hear your terrible story. On Tue, Oct 26, 2004 at 02:03:39PM +0400, Pavel Merdine wrote: > I'd like to start discussions about panic and fs over again. >=20 > Since yesterday one of our servers is periodically being hit by > various panics. It seems that it relates to only one partition. > I thought maybe it's a faulty HDD and copied the content to another > HDD. I done it using dd. After one hour the server had panic again: > Oct 26 05:11:54 images8 /kernel: mode =3D 040700, inum =3D 2382, fs = =3D > /mountpount > Oct 26 05:11:54 images8 /kernel: panic: ffs_valloc: dup alloc > Oct 26 05:11:54 images8 /kernel: > Oct 26 05:11:54 images8 /kernel: syncing disks... 49 12 > Oct 26 05:11:54 images8 /kernel: done It's wrong to use dd'ed disk IMHO. A better solution for your situation might be: - dd(1) the bad disk to a disk having same size. - do a fsck -fy on the copy. - mount the copy read-only - use tar(1) or dump to dump the data out the copy, then restore to another disk. > Dispite the line "syncing disks", all disks were not clean after > reboot: >=20 > Oct 26 05:11:56 images8 /kernel: WARNING: R/W mount of /mountp denied. > Filesystem is not clean - run fsck >=20 > I do not mount with -f because softupdates didn't show good results > and made system panic more and more times. >=20 > My question is: Is there any future in FFS, it's panics and > non-working softupdates? Frankly, the ONLY way to guarantee data integrity is more backups. How can you expect your operating system to run correctly when it is running on defective hardware? > I dont see any reliability in such system. > But what I remember is high reliability of MS NTFS. I didn't see any > disk checks after any failure and I didn't experience a file loss. > And I didn't see it's popular "blue screen" with an error caused by > filesystem code. Accusing other systems is not what we feel beneficial because we don't sell FreeBSD, and our interest is to improve *our* system and make it even better. Nothing but backup can guarantee that you survive from a hardware failure. The intention of panic() in our code is to stop the operating system before it can make more damage. We feel that your data is more important than "pretending to work" but silently damage your data. > I think that FreeBSD has no future without a reliable FS and clean > code for it. There are many efforts focusing the storage system and file system, while we still need more manpower to work on it. > BTW: We user FreeBSD 4.10, I talk about IDE drives. I tried to > switch IDE write cache off, but ffs does not work better. Turning IDE write cache off will give the system more opportunity to survive a system/power failure. It does not necessarily that you need it when you have UPS, and it does not guarantee that you survive a hardware failure. > Sorry if I wrote too long letter. Our company is just tired of the > problems related to all of this. User experience is important, but again, we need more details, manpower. > And, by the way, FFS code still have a divide by integer error in > dirpref(). I tried to report it two times, I saw it reported in > lists, but nobody cares :( . No future. In order to get your problem tracked down, you need to provide more information. A good start is to set a dump area (e.g. if your swap space is bigger than your RAM, then you can use that) and obtain a backtrace then send it to list or send-pr(1). I have some patches agains the FFS code however they are related to file systems that are very big, so I am not sure if it will fix your problem. Instruction on obtaining a backtrace is available at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug.html#KERNELDEBUG-OBTAIN Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBfnzx/cVsHxFZiIoRAvnoAJ4kyVYhcrSnHHxdGExlFCZ1uROiJQCfcECL i6xnxOPTI9yTjJEqTAkIrv4= =QsS/ -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 17:34:15 2004 Return-Path: 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 5D40616A4CF for ; Tue, 26 Oct 2004 17:34:14 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C721443D46 for ; Tue, 26 Oct 2004 17:34:13 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (242.net-144.kaluga.ru [62.148.144.242] (may be forged)) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9QHY9nn051648 for ; Tue, 26 Oct 2004 21:34:10 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.57) sender ; 26 Oct 2004 21:34:10 +0400 Date: Tue, 26 Oct 2004 21:34:09 +0400 From: Pavel Merdine X-Mailer: The Bat! (v3.0.1.33) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <1357841854.20041026213409@merdin.com> To: Xin LI In-Reply-To: <20041026163601.GA2172@frontfree.net> References: <1038372273.20041026140339@merdin.com> <20041026163601.GA2172@frontfree.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 17:34:15 -0000 Hello , Tuesday, October 26, 2004, 8:36:01 PM, you wrote: > Hello, Pavel, > First off, I'm sorry to hear your terrible story. Really? I thought I'm not the only one. ... >> Oct 26 05:11:54 images8 /kernel: panic: ffs_valloc: dup alloc >> Oct 26 05:11:54 images8 /kernel: >> Oct 26 05:11:54 images8 /kernel: syncing disks... 49 12 >> Oct 26 05:11:54 images8 /kernel: done > It's wrong to use dd'ed disk IMHO. A better solution for your situation > might be: I think it's ok in my case, because the drive has no read errors. I dont know why, but it works slowly and causes NFS slowness in it's turn. Maybe it has not a full failure, just a cable, we didn't investigate the problem yet. I now realised that I should have checked the copy first. It looks like working now. ... >> My question is: Is there any future in FFS, it's panics and >> non-working softupdates? > Frankly, the ONLY way to guarantee data integrity is more backups. > How can you expect your operating system to run correctly when it is > running on defective hardware? Sorry, I didn't explain my point thoroughly. I meant non-working softupdates on non-faulty hardware. Press "Reset" on busy server with many drives, mount -f (softupdates mount?) and you will surely get a panic in an hour. >> I dont see any reliability in such system. >> But what I remember is high reliability of MS NTFS. I didn't see any >> disk checks after any failure and I didn't experience a file loss. >> And I didn't see it's popular "blue screen" with an error caused by >> filesystem code. > Accusing other systems is not what we feel beneficial because we don't > sell FreeBSD, and our interest is to improve *our* system and make it > even better. Nothing but backup can guarantee that you survive from a > hardware failure. I wrote that to prove the fact that it's possible to have a reliable filesystem. > The intention of panic() in our code is to stop the operating system > before it can make more damage. We feel that your data is more important > than "pretending to work" but silently damage your data. I know that. But my opinion after looking at the code is that panic()'s are used even in cases when error can be fixed or reported to higher level. Maybe I'm wrong, but NTFS case confirms that it's possible to have no panics in reality. Again, somehow after a panic on ONE file system, other filesystems are not fully synced. The system conplaints that they are dirty after restart. So it seems like one panic lead to corruption of another systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing each time. Background fsck does not work in reality as well, because the system can panic thousand times before errors are fixed. >> I think that FreeBSD has no future without a reliable FS and clean >> code for it. > There are many efforts focusing the storage system and file system, while > we still need more manpower to work on it. What kind of manpower? ... >> Sorry if I wrote too long letter. Our company is just tired of the >> problems related to all of this. > User experience is important, but again, we need more details, manpower. I'm not sure if it is possible to do anything with FFS at all. >> And, by the way, FFS code still have a divide by integer error in >> dirpref(). I tried to report it two times, I saw it reported in >> lists, but nobody cares :( . No future. > In order to get your problem tracked down, you need to provide more > information. A good start is to set a dump area (e.g. if your swap There is no need to track it down. I already described the problem in freebsd-stable. If you look at dirpref(), it becomes clear that 32 bit numbers cannot be used for calculation. I saw a discussion about that in some list on google. ... > Cheers, Thanks. -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 20:06:17 2004 Return-Path: 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 1F62516A4CE for ; Tue, 26 Oct 2004 20:06:17 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2E2F43D39 for ; Tue, 26 Oct 2004 20:06:16 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9QK67t7018640; Tue, 26 Oct 2004 13:06:11 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410262006.i9QK67t7018640@gw.catspoiler.org> Date: Tue, 26 Oct 2004 13:06:07 -0700 (PDT) From: Don Lewis To: freebsd-fs@merdin.com In-Reply-To: <1357841854.20041026213409@merdin.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-fs@FreeBSD.org Subject: Re: Re[2]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 20:06:17 -0000 On 26 Oct, Pavel Merdine wrote: > Sorry, I didn't explain my point thoroughly. I meant non-working > softupdates on non-faulty hardware. Press "Reset" on busy server with > many drives, mount -f (softupdates mount?) and you will surely get a > panic in an hour. mount -f does not enable softupdates. The mount(8) man page says: -f Forces the revocation of write access when trying to downgrade a filesystem mount status from read-write to read-only. Also forces the R/W mount of an unclean filesystem (dangerous; use with caution). In this case, dangerous means that further file system damage and/or a system panic can happen. Softupdates is enabled and disabled with tunefs -n enable and tunefs -n disable on an unmounted file system. From owner-freebsd-fs@FreeBSD.ORG Tue Oct 26 20:25:40 2004 Return-Path: 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 C40AF16A4CE for ; Tue, 26 Oct 2004 20:25:40 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE9443D2F for ; Tue, 26 Oct 2004 20:25:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9QKPXeV018690; Tue, 26 Oct 2004 13:25:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410262025.i9QKPXeV018690@gw.catspoiler.org> Date: Tue, 26 Oct 2004 13:25:33 -0700 (PDT) From: Don Lewis To: freebsd-fs@merdin.com In-Reply-To: <1357841854.20041026213409@merdin.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-fs@FreeBSD.org Subject: Re: Re[2]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 20:25:40 -0000 On 26 Oct, Pavel Merdine wrote: > Again, somehow after a panic on ONE file system, other filesystems are > not fully synced. The system conplaints that they are dirty after > restart. So it seems like one panic lead to corruption of another > systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing > each time. When the OS detects these types of problems, then something (we don't know what) unexpected has happened, so we can no longer trust the state of the machine. If we can't trust the state of the machine, then it is dangerous to sync any of the file systems, because doing so could damage them with corrupt data. > Background fsck does not work in reality as well, because the system > can panic thousand times before errors are fixed. It might be a good idea to force a foreground fsck if the system panics before a background fsck has marked a dirty filesystem clean. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 09:24:24 2004 Return-Path: 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 C38CD16A4CE for ; Wed, 27 Oct 2004 09:24:24 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4B143D2D for ; Wed, 27 Oct 2004 09:24:23 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (net.stencil.kaluga.ru [62.148.158.62]) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9R9OJnn045243 for ; Wed, 27 Oct 2004 13:24:20 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.581) sender ; 27 Oct 2004 13:24:19 +0400 Date: Wed, 27 Oct 2004 13:24:19 +0400 From: Pavel Merdine X-Priority: 3 (Normal) Message-ID: <766160464.20041027132419@merdin.com> To: Don Lewis In-Reply-To: <200410262025.i9QKPXeV018690@gw.catspoiler.org> References: <1357841854.20041026213409@merdin.com> <200410262025.i9QKPXeV018690@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[4]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 09:24:24 -0000 Hello , Wednesday, October 27, 2004, 12:25:33 AM, you wrote: > On 26 Oct, Pavel Merdine wrote: >> Again, somehow after a panic on ONE file system, other filesystems are >> not fully synced. The system conplaints that they are dirty after >> restart. So it seems like one panic lead to corruption of another >> systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing >> each time. > When the OS detects these types of problems, then something (we don't > know what) unexpected has happened, so we can no longer trust the state > of the machine. If we can't trust the state of the machine, then it is > dangerous to sync any of the file systems, because doing so could damage > them with corrupt data. I'm right then. Number of panic()s should be minimum. Because currently one error in one partition leads to corruption of other immediately (providing they do writes often). I think that is not acceptable. I just didn't make fsck, don't shoot me! >> Background fsck does not work in reality as well, because the system >> can panic thousand times before errors are fixed. > It might be a good idea to force a foreground fsck if the system panics > before a background fsck has marked a dirty filesystem clean. What I mean is there is no point having background fsck which can lead to corruption of all system partitions. Explanation: there is not guarantee that panic will not occur before fsck is done; that panic leads to reboot without other filesystems sync, so it'll lead the their corruption. -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 10:56:36 2004 Return-Path: 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 C8FEC16A4CE for ; Wed, 27 Oct 2004 10:56:36 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D69F43D6B for ; Wed, 27 Oct 2004 10:56:36 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9RAuLcT020382; Wed, 27 Oct 2004 03:56:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410271056.i9RAuLcT020382@gw.catspoiler.org> Date: Wed, 27 Oct 2004 03:56:21 -0700 (PDT) From: Don Lewis To: freebsd-fs@merdin.com In-Reply-To: <766160464.20041027132419@merdin.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-fs@FreeBSD.org Subject: Re: Re[4]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 10:56:37 -0000 On 27 Oct, Pavel Merdine wrote: > Hello , > > Wednesday, October 27, 2004, 12:25:33 AM, you wrote: > >> On 26 Oct, Pavel Merdine wrote: > >>> Again, somehow after a panic on ONE file system, other filesystems are >>> not fully synced. The system conplaints that they are dirty after >>> restart. So it seems like one panic lead to corruption of another >>> systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing >>> each time. > >> When the OS detects these types of problems, then something (we don't >> know what) unexpected has happened, so we can no longer trust the state >> of the machine. If we can't trust the state of the machine, then it is >> dangerous to sync any of the file systems, because doing so could damage >> them with corrupt data. > > I'm right then. Number of panic()s should be minimum. Because > currently one error in one partition leads to corruption of other > immediately (providing they do writes often). I think that is not > acceptable. I just didn't make fsck, don't shoot me! The panics only happen when a problem is detected that should never happen. In normal operation, certain operations on a file system may place it temporarily in an inconsistent state, but the data on the disk is changed in a particular order so that if the system crashes in the middle of an operation due to a power failure or system panic, the inconsistencies have certain, known properties such that these inconsistencies can be anticipated and repaired by fsck and the file system can be safely accessed even before the inconsistencies are repaired. It is possible for a file system to sustain types of damage that are not anticipated in case of a power failure. If the disk does write caching, data is likely to be written to the platters in a different order than the file system code expects, so a power failure during a sequence of writes may result in a partial set of writes that put the file system in a corrupt state that it is not possible to automatically repair. It is also possible for the disk to corrupt data other than what is being written. The other file systems will be marked as dirty, but they should not be corrupt. If softupdates is in use, the only inconsistency should be that some blocks and/or inodes make be marked as allocated when they are actually not in use. In this case, the background fsck is able to detect the inconsistency and mark these blocks and/or inodes as being free so that they can be reused. >>> Background fsck does not work in reality as well, because the system >>> can panic thousand times before errors are fixed. > >> It might be a good idea to force a foreground fsck if the system panics >> before a background fsck has marked a dirty filesystem clean. > > What I mean is there is no point having background fsck which can lead > to corruption of all system partitions. Explanation: there is not > guarantee that panic will not occur before fsck is done; that panic > leads to reboot without other filesystems sync, so it'll lead the > their corruption. If all file systems except one were initially in a valid and consistent state and one file system had some sort of damage that caused a system panic, they would all be marked as dirty when the system crashed and rebooted. The only file system that could cause another panic would be the one that was originally corrupt. The only possible inconsistencies in all the other file systems would be those that can be repaired by a background fsck, and accessing these file systems before they have been marked as clean by the background fsck should not result in a panic. There have been bugs that caused system panics when a file system that is undergoing a background fsck has a lot of write activity before the fsck operation finishes. These types of bugs should be tracked down and fixed, though this can be difficult. A system panic in this case makes it *easier* to find the bug. The sooner the system detects a problem and panics, the closer the panic and the debug information that it produces is to the actual software bug. If the file system code just ignored the inconsistencies and tried to keep running, it is quite possible that the file system would be totally trashed and all of its data lost. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 11:20:54 2004 Return-Path: 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 7115116A4CE for ; Wed, 27 Oct 2004 11:20:54 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8470E43D54 for ; Wed, 27 Oct 2004 11:20:53 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (net.stencil.kaluga.ru [62.148.158.62]) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9RBKjnn033154 for ; Wed, 27 Oct 2004 15:20:49 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.581) sender ; 27 Oct 2004 15:20:46 +0400 Date: Wed, 27 Oct 2004 15:20:45 +0400 From: Pavel Merdine X-Priority: 3 (Normal) Message-ID: <162265023.20041027152045@merdin.com> To: Don Lewis In-Reply-To: <200410262006.i9QK67t7018640@gw.catspoiler.org> References: <1357841854.20041026213409@merdin.com> <200410262006.i9QK67t7018640@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Subject: Re[4]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 11:20:54 -0000 Hello , Maybe I was wrong, but looking at the FFS code I see that softupdates does not work without -f : if (fs->fs_clean == 0) { fs->fs_flags |= FS_UNCLEAN; if (ronly || (mp->mnt_flag & MNT_FORCE)) { printf( "WARNING: %s was not properly dismounted\n", fs->fs_fsmnt); } else { printf("WARNING: R/W mount of %s denied. Filesystem is not clean - run fsck\n", fs->fs_fsmnt); error = EPERM; goto out; } } The clean flag does not seem to be affected by softupdates. My practice tells me that fsck is always required after unclean shutdown if I dont use -f. So what is the purpose of softupdates then? I repeat that maybe I'm wrong. But I just didn't see it working. Wednesday, October 27, 2004, 12:06:07 AM, you wrote: > On 26 Oct, Pavel Merdine wrote: >> Sorry, I didn't explain my point thoroughly. I meant non-working >> softupdates on non-faulty hardware. Press "Reset" on busy server with >> many drives, mount -f (softupdates mount?) and you will surely get a >> panic in an hour. > mount -f does not enable softupdates. The mount(8) man page says: > -f Forces the revocation of write access when trying to downgrade a > filesystem mount status from read-write to read-only. Also > forces the R/W mount of an unclean filesystem (dangerous; use > with caution). > In this case, dangerous means that further file system damage and/or a > system panic can happen. > Softupdates is enabled and disabled with > tunefs -n enable > and > tunefs -n disable > on an unmounted file system. -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 11:48:36 2004 Return-Path: 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 5BF1716A4CE for ; Wed, 27 Oct 2004 11:48:36 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6828C43D41 for ; Wed, 27 Oct 2004 11:48:35 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (net.stencil.kaluga.ru [62.148.158.62]) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9RBmVnn052893 for ; Wed, 27 Oct 2004 15:48:32 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.581) sender ; 27 Oct 2004 15:48:32 +0400 Date: Wed, 27 Oct 2004 15:48:31 +0400 From: Pavel Merdine X-Priority: 3 (Normal) Message-ID: <999608774.20041027154831@merdin.com> To: Don Lewis In-Reply-To: <200410271056.i9RAuLcT020382@gw.catspoiler.org> References: <766160464.20041027132419@merdin.com> <200410271056.i9RAuLcT020382@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[6]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 11:48:36 -0000 Hello , Wednesday, October 27, 2004, 2:56:21 PM, you wrote: > On 27 Oct, Pavel Merdine wrote: >> Hello , >> >> Wednesday, October 27, 2004, 12:25:33 AM, you wrote: >> >>> On 26 Oct, Pavel Merdine wrote: >> >>>> Again, somehow after a panic on ONE file system, other filesystems are >>>> not fully synced. The system conplaints that they are dirty after >>>> restart. So it seems like one panic lead to corruption of another >>>> systems. Maybe I'm wrong here too. But I dont see any good in fsck-ing >>>> each time. >> >>> When the OS detects these types of problems, then something (we don't >>> know what) unexpected has happened, so we can no longer trust the state >>> of the machine. If we can't trust the state of the machine, then it is >>> dangerous to sync any of the file systems, because doing so could damage >>> them with corrupt data. >> >> I'm right then. Number of panic()s should be minimum. Because >> currently one error in one partition leads to corruption of other >> immediately (providing they do writes often). I think that is not >> acceptable. I just didn't make fsck, don't shoot me! > The panics only happen when a problem is detected that should never > happen. First of all, they happen. Believe me. I saw them more than ten times on non-faulty disks. > In normal operation, certain operations on a file system may place it > temporarily in an inconsistent state, but the data on the disk is > changed in a particular order so that if the system crashes in the > middle of an operation due to a power failure or system panic, the > inconsistencies have certain, known properties such that these > inconsistencies can be anticipated and repaired by fsck and the file > system can be safely accessed even before the inconsistencies are > repaired. That is in theory. I didn't write to the list if there was no problem at all. > It is possible for a file system to sustain types of damage that are not > anticipated in case of a power failure. If the disk does write caching, > data is likely to be written to the platters in a different order than > the file system code expects, so a power failure during a sequence of > writes may result in a partial set of writes that put the file system in > a corrupt state that it is not possible to automatically repair. It is > also possible for the disk to corrupt data other than what is being > written. Why the file system cannot be repaired on the fly? Is it the filesystem limitation? Why, say, NTFS can repair itself without a blue screen or a disk check? > The other file systems will be marked as dirty, but they should not be > corrupt. If softupdates is in use, the only inconsistency should be > that some blocks and/or inodes make be marked as allocated when they are > actually not in use. In this case, the background fsck is able to > detect the inconsistency and mark these blocks and/or inodes as being > free so that they can be reused. You should agree that there is no guarantee that there will be no panic before fsck finished. In my opinion what you say is theory based on probability theory. Am I right? I see what you mean. If write caching is disabled then softupdates should work fine. I'm wondering then why it is left enabled by default. But I still see problem with fsck. We can hardly afford 40+ minute of fsck each time. Background fsck is not a solution too (because 5.x is not stable and there is no guarantee of reliability). >>>> Background fsck does not work in reality as well, because the system >>>> can panic thousand times before errors are fixed. >> >>> It might be a good idea to force a foreground fsck if the system panics >>> before a background fsck has marked a dirty filesystem clean. >> >> What I mean is there is no point having background fsck which can lead >> to corruption of all system partitions. Explanation: there is not >> guarantee that panic will not occur before fsck is done; that panic >> leads to reboot without other filesystems sync, so it'll lead the >> their corruption. > If all file systems except one were initially in a valid and consistent > state and one file system had some sort of damage that caused a system > panic, they would all be marked as dirty when the system crashed and > rebooted. The only file system that could cause another panic would be > the one that was originally corrupt. The only possible inconsistencies > in all the other file systems would be those that can be repaired by a > background fsck, and accessing these file systems before they have been > marked as clean by the background fsck should not result in a panic. "Should not" is the key phrase. > There have been bugs that caused system panics when a file system that > is undergoing a background fsck has a lot of write activity before the > fsck operation finishes. These types of bugs should be tracked down and > fixed, though this can be difficult. A system panic in this case makes > it *easier* to find the bug. The sooner the system detects a problem > and panics, the closer the panic and the debug information that it > produces is to the actual software bug. If the file system code just > ignored the inconsistencies and tried to keep running, it is quite > possible that the file system would be totally trashed and all of its > data lost. I know what panics are. I just say that a panic should be avoided when possible. Any panic on busy server leads to some loss. Even if a filesystem is checked after reboot, some files can be lost. I'm sure that it's possible to make some actions like fsck does when an error is found. BTW, newfs -g 375000 -h 8000 and mkdir dir1 after that on newly created partition can cause panic as well :) -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 12:48:51 2004 Return-Path: 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 7E51B16A4CE for ; Wed, 27 Oct 2004 12:48:51 +0000 (GMT) Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 6607D43D45 for ; Wed, 27 Oct 2004 12:48:51 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Message-ID: <20041027124851.9989.qmail@web41210.mail.yahoo.com> Received: from [83.129.244.117] by web41210.mail.yahoo.com via HTTP; Wed, 27 Oct 2004 05:48:51 PDT Date: Wed, 27 Oct 2004 05:48:51 -0700 (PDT) From: Arne "Wörner" To: freebsd-fs@freebsd.org In-Reply-To: <999608774.20041027154831@merdin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Re[6]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 12:48:51 -0000 > Why the file system cannot be repaired on the fly? Is it the > filesystem limitation? Why, say, NTFS can repair itself without a blue > screen or a disk check? > I have found some reports about NTFS to be buggy, too, when I searched for '+"turn off write cache" +ide +ata'... I think a fault free source code, that solves a problem like a file system, is quite difficult to produce, especially if someone chose not so common parameters... But I like the idea to track bugs down, where it seems to be reasonable (in some cases, if the source code looks too funny, it would not make so much sense, I think). I cannot really complain about FFS with soft-updates. I observed once, that after a halt with ACPI power-down _and_ with sync (as far as I recall it correctly) my file systems were un-clean (during the reboot the kernel panic'ed, because it felt something (a buf) was already free (as far as I can recall it)). But I was able to fix it by some fsck's in single user mode. Maybe I should mention, that I use three filesystems (root: 500MB, usr: 32GB, opt: 118GB) since several months and not so high avg. disc load (but with some peaks and concurrency) under FreeBSD 5.2-CURRENT-20040408. I think my problem with ACPI power-down happened due to this write cache thing (or is ACPI to wait for the cache flushing? Maybe I pressed the power or reset button... I do not know)? At least I turned off hw.ata.wc (by setting it to zero) today. Now it feels like writing from /dev/zero to a FFS device takes 5-6 times longer, but it feels safer, too... Does somebody know, if FFS works fine with modern hard discs (I do not know, but I could think of a little energy-buffer, that powers the drive until the cache is clean)? Is there a way to make this 2 minutes time window for meta data updates smaller (maybe 10 seconds or so)? I would be glad, if somebody could tell me, how to provoke a ffs-related panic, without choosing funny fs-parameters. Maybe then I could find a way to repeat the problem. Btw.: I cannot enlarge my filesystems... > BTW, newfs -g 375000 -h 8000 and mkdir dir1 after that on newly > created partition can cause panic as well :) > > -- > / Pavel Merdine > > > _______________________________________________ > 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" > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-freebsd-fs@FreeBSD.ORG Wed Oct 27 16:48:13 2004 Return-Path: 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 DB92616A4CE for ; Wed, 27 Oct 2004 16:48:13 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7441143D2F for ; Wed, 27 Oct 2004 16:48:13 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9RGm5DS021247; Wed, 27 Oct 2004 09:48:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410271648.i9RGm5DS021247@gw.catspoiler.org> Date: Wed, 27 Oct 2004 09:48:05 -0700 (PDT) From: Don Lewis To: freebsd-fs@merdin.com In-Reply-To: <162265023.20041027152045@merdin.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-fs@FreeBSD.org Subject: Re: Re[4]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 16:48:14 -0000 On 27 Oct, Pavel Merdine wrote: > Hello , > > Maybe I was wrong, but looking at the FFS code I see that softupdates > does not work without -f : > if (fs->fs_clean == 0) { > fs->fs_flags |= FS_UNCLEAN; > if (ronly || (mp->mnt_flag & MNT_FORCE)) { > printf( "WARNING: %s was not properly dismounted\n", > fs->fs_fsmnt); > } else { > printf("WARNING: R/W mount of %s denied. Filesystem is not clean - run fsck\n", > fs->fs_fsmnt); > error = EPERM; > goto out; > } > } > The clean flag does not seem to be affected by softupdates. > > My practice tells me that fsck is always required after unclean > shutdown if I dont use -f. So what is the purpose of softupdates then? > I repeat that maybe I'm wrong. But I just didn't see it working. This appears to be the code from FreeBSD 4.x, which does not have the background fsck feature, so any unclean file systems must be fsck'ed before they are mounted. This does not depend on whether or not softupdates is enabled. Softupdates in FreeBSD 4.x is primarily just enhances file system write performance. Background fsck also requires the file system to have a snapshot capability so that fsck can run on the snapshot while the file system is mounted and possibly being modifed by other processes on the system. The snapshot feature is only present in FreeBSD 6.x and recent versions of FreeBSD 5.x. The equivalent block of code in FreeBSD 6-CURRENT is: if (fs->fs_clean == 0) { fs->fs_flags |= FS_UNCLEAN; if (ronly || (mp->mnt_flag & MNT_FORCE) || ((fs->fs_flags & FS_NEEDSFSCK) == 0 && (fs->fs_flags & FS_DOSOFTDEP))) { printf( "WARNING: %s was not properly dismounted\n", fs->fs_fsmnt); } else { printf( "WARNING: R/W mount of %s denied. Filesystem is not clean - run fsck\n", fs->fs_fsmnt); error = EPERM; goto out; } if ((fs->fs_pendingblocks != 0 || fs->fs_pendinginodes != 0) && (mp->mnt_flag & MNT_FORCE)) { printf("%s: lost blocks %jd files %d\n", fs->fs_fsmnt, (intmax_t)fs->fs_pendingblocks, fs->fs_pendinginodes); fs->fs_pendingblocks = 0; fs->fs_pendinginodes = 0; } } This code permits the file system to be mounted even if it is unclean as long as softupdates is enabled. From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 11:56:12 2004 Return-Path: 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 0778316A4CE for ; Thu, 28 Oct 2004 11:56:12 +0000 (GMT) Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by mx1.FreeBSD.org (Postfix) with SMTP id B069C43D5E for ; Thu, 28 Oct 2004 11:56:11 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Message-ID: <20041028115611.96139.qmail@web41203.mail.yahoo.com> Received: from [83.129.193.23] by web41203.mail.yahoo.com via HTTP; Thu, 28 Oct 2004 04:56:11 PDT Date: Thu, 28 Oct 2004 04:56:11 -0700 (PDT) From: Arne "Wörner" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1005613650-1098964571=:95408" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: ffs permormance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 11:56:12 -0000 --0-1005613650-1098964571=:95408 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hi! I did some tests on a freshly booted system (FreeBSD 5.2-CURRENT-20040408). I turned off hw.ata.wc via /boot/loader.conf successfully(?). Can somebody tell me, why 'atacontrol(8)' tells me, that "write cache" is enabled (yes)? Sometimes it is disabled (no), but not always. Sometimes atacontrol says, that ad0 has write cache disabled while atacontrol says that ad1 has write cache enabled... Is atacontrol wrong? At least in the beginning big writes to a new file (~64MB) are slow with hw.ata.wc=0 (with hw.ata.wc=1 such writes are fast). The subsequent fsync(1) to that new file did not take much time. But: After a long read (~64MB) from /dev/ad1 the following long write is as fast as with hw.ata.wc=1 before the test (see b.out.bz2). I gathered the sysctl variables (see diff in sc.diff.bz2) Can somebody explain me, why ffs behaves better after a long read? Maybe ffs simulates in kernel memory a hard disc write cache after a long read, so that the writes can be done in a more efficient order? Thank you. Bye Arne __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo --0-1005613650-1098964571=:95408-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 28 15:00:44 2004 Return-Path: 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 3512616A4CF for ; Thu, 28 Oct 2004 15:00:44 +0000 (GMT) Received: from lancia.kaluga.ru (lancia.kaluga.ru [62.148.128.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4676743D1D for ; Thu, 28 Oct 2004 15:00:43 +0000 (GMT) (envelope-from freebsd-fs@merdin.com) Received: from localhost (242.net-144.kaluga.ru [62.148.144.242] (may be forged)) by lancia.kaluga.ru (8.12.10/8.12.10) with ESMTP id i9SF0ckt022539 for ; Thu, 28 Oct 2004 19:00:39 +0400 (MSD) Received: from localhost ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.57) sender ; 28 Oct 2004 19:00:38 +0400 Date: Thu, 28 Oct 2004 19:00:37 +0400 From: Pavel Merdine X-Mailer: The Bat! (v3.0.1.33) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <153168377.20041028190037@merdin.com> To: Don Lewis In-Reply-To: <200410271648.i9RGm5DS021247@gw.catspoiler.org> References: <162265023.20041027152045@merdin.com> <200410271648.i9RGm5DS021247@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[6]: panic again X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 15:00:44 -0000 Hello , Wednesday, October 27, 2004, 8:48:05 PM, you wrote: ... > This appears to be the code from FreeBSD 4.x, which does not have the > background fsck feature, so any unclean file systems must be fsck'ed > before they are mounted. This does not depend on whether or not > softupdates is enabled. Softupdates in FreeBSD 4.x is primarily just > enhances file system write performance. That should have been written in docs several years ago :) . We though we had full softupdates support and never looked at the sources to confirm that. > Background fsck also requires the file system to have a snapshot > ... > This code permits the file system to be mounted even if it is unclean as > long as softupdates is enabled. Thanks a lot for the explanation. Unfortunately, 5.x is not stable enough now for production use. And again, there is no guarantee that a panic will not occur before the check is done. Can I ask you, is there a filesystem that could be considered as substitution of FFS in FreeBSD for better reliability and performance. I mean in terms of compatibility and license. BTW, please fix a bug in dirpref(), it should use 64-bit counters. At least, make sure it does not divide by zero. You can find the details at http://lists.freebsd.org/pipermail/freebsd-stable/2004-August/008563.html -- / Pavel Merdine From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 09:57:34 2004 Return-Path: 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 71CD816A4CE for ; Sat, 30 Oct 2004 09:57:34 +0000 (GMT) Received: from mail.radnet.ru (mail.radnet.ru [62.183.38.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AAAE43D31 for ; Sat, 30 Oct 2004 09:57:33 +0000 (GMT) (envelope-from rsl@radnet.ru) Received: from localhost (localhost.radnet.ru [127.0.0.1]) by mail.radnet.ru (Postfix) with ESMTP id 33A161BE614 for ; Sat, 30 Oct 2004 13:57:31 +0400 (MSD) Received: from mail.radnet.ru ([127.0.0.1]) by localhost (mail.radnet.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87343-04 for ; Sat, 30 Oct 2004 13:57:25 +0400 (MSD) Received: from andc9lch5aeom2 (unknown [62.183.38.237]) by mail.radnet.ru (Postfix) with SMTP id 8C0A71BE484 for ; Sat, 30 Oct 2004 13:57:25 +0400 (MSD) Message-ID: <007c01c4be66$daa19260$0701a8c0@andc9lch5aeom2> From: "PostAdmin" To: Date: Sat, 30 Oct 2004 13:57:23 +0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at radnet.ru Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: can't change the size of the swap X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 09:57:34 -0000 FreeBSD 5-2RELEASE=20 The vinum volume manager. I boot in single user mode # mount -u / # mount /usr # bsdlabel ad0s1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # /dev/ad0s1:=20 8 partitions:=20 # size offset fstype [fsize bsize bps/cpg]=20 a: 6291456 614400 4.2BSD 2048 16384 28552=20 b: 614400 0 swap=20 c: 78156162 0 unused 0 0 # "raw" part, = don't edit=20 d: 1024000 6905856 4.2BSD 2048 16384 64008=20 e: 2097152 7929856 4.2BSD 2048 16384 28552=20 f: 68129154 10027008 4.2BSD 2048 16384 28544=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # bsdlabel -e ad0s1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # /dev/ad0s1:=20 8 partitions:=20 # size offset fstype [fsize bsize bps/cpg]=20 a: 6291456 614400 4.2BSD 2048 16384 28552=20 b: 614119 281 swap = #change c: 78156162 0 unused 0 0 # "raw" part, = don't edit=20 d: 1024000 6905856 4.2BSD 2048 16384 64008=20 e: 2097152 7929856 4.2BSD 2048 16384 28552=20 f: 68129154 10027008 4.2BSD 2048 16384 28544=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D :wq # bsdlabel ad0s1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # /dev/ad0s1:=20 8 partitions:=20 # size offset fstype [fsize bsize bps/cpg]=20 a: 6291456 614400 4.2BSD 2048 16384 28552=20 b: 614400 0 swap=20 c: 78156162 0 unused 0 0 # "raw" part, = don't edit=20 d: 1024000 6905856 4.2BSD 2048 16384 64008=20 e: 2097152 7929856 4.2BSD 2048 16384 28552=20 f: 68129154 10027008 4.2BSD 2048 16384 28544=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Can't change the size of the swap. In what a problem? From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 17:12:24 2004 Return-Path: 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 CDB4116A4CE for ; Sat, 30 Oct 2004 17:12:24 +0000 (GMT) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52FE743D2D for ; Sat, 30 Oct 2004 17:12:24 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.rr.com [24.211.118.154])i9UHCKKj006706 for ; Sat, 30 Oct 2004 13:12:21 -0400 (EDT) Received: from volatile.chemikals.org (morganw@localhost [127.0.0.1]) i9UHCJeR019281 for ; Sat, 30 Oct 2004 13:12:20 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost)i9UHCJVg019278 for ; Sat, 30 Oct 2004 13:12:19 -0400 (EDT) (envelope-from morganw@chemikals.org) X-Authentication-Warning: volatile.chemikals.org: morganw owned process doing -bs Date: Sat, 30 Oct 2004 13:12:19 -0400 (EDT) From: Wesley Morgan To: freebsd-fs@freebsd.org Message-ID: <20041030130911.E18406@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: msdosfs on D70 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 17:12:24 -0000 I can't seem to mount the FAT32 fs created by my D70. Windows and mtools both are able to read it just fine. Has anyone encountered this problem? The output from fdisk and "minfo" are below. Perhaps someone can get this working properly! :) Thanks, WNM sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 63, size 7998417 (3905 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 766/ head 15/ sector 63 bootsector information ====================== banner:"MSDOS5.0" sector size: 512 bytes cluster size: 64 sectors reserved (boot) sectors: 32 fats: 2 max available root directory slots: 0 small size: 0 sectors media descriptor byte: 0xf8 sectors per fat: 0 sectors per track: 63 heads: 16 hidden sectors: 63 big size: 7998417 sectors physical drive id: 0x80 reserved=0x0 dos4=0x29 serial number: 00000000 disk label="NIKON D70 " disk type="FAT32 " Big fatlen=977 Extended flags=0x0000 FS version=0x0000 rootCluster=2 infoSector location=1 backup boot sector=6 Infosector: signature=0x41615252 free clusters=69396 last allocated cluster=2 -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 17:53:40 2004 Return-Path: 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 DCBA516A4EB for ; Sat, 30 Oct 2004 17:53:40 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 603B043D39 for ; Sat, 30 Oct 2004 17:53:40 +0000 (GMT) (envelope-from garycor@comcast.net) Received: from [10.56.78.111] (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (sccrmhc11) with ESMTP id <20041030175335011002rnr4e> (Authid: garycor); Sat, 30 Oct 2004 17:53:35 +0000 Message-ID: <4183D5C2.3050400@comcast.net> Date: Sat, 30 Oct 2004 13:56:18 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20041030130911.E18406@volatile.chemikals.org> In-Reply-To: <20041030130911.E18406@volatile.chemikals.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: msdosfs on D70 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 17:53:41 -0000 Wesley Morgan wrote: > I can't seem to mount the FAT32 fs created by my D70. Windows and mtools > both are able to read it just fine. Has anyone encountered this problem? > The output from fdisk and "minfo" are below. Perhaps someone can get > this working properly! :) Somebody might be able to help you if you explained what a "D70" is... > sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) > start 63, size 7998417 (3905 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 766/ head 15/ sector 63 > bootsector information > ====================== > banner:"MSDOS5.0" > sector size: 512 bytes > cluster size: 64 sectors > reserved (boot) sectors: 32 > fats: 2 > max available root directory slots: 0 > small size: 0 sectors > media descriptor byte: 0xf8 > sectors per fat: 0 > sectors per track: 63 > heads: 16 > hidden sectors: 63 > big size: 7998417 sectors > physical drive id: 0x80 > reserved=0x0 > dos4=0x29 > serial number: 00000000 > disk label="NIKON D70 " > disk type="FAT32 " > Big fatlen=977 > Extended flags=0x0000 > FS version=0x0000 > rootCluster=2 > infoSector location=1 > backup boot sector=6 > > Infosector: > signature=0x41615252 > free clusters=69396 > last allocated cluster=2 > > > From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:07:01 2004 Return-Path: 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 E19FC16A4CE for ; Sat, 30 Oct 2004 18:07:01 +0000 (GMT) Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B2743D46 for ; Sat, 30 Oct 2004 18:07:01 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.rr.com [24.211.118.154])i9UI6gCh008408; Sat, 30 Oct 2004 14:06:43 -0400 (EDT) Received: from volatile.chemikals.org (morganw@localhost [127.0.0.1]) i9UI6g5O019873; Sat, 30 Oct 2004 14:06:42 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost)i9UI6gDB019870; Sat, 30 Oct 2004 14:06:42 -0400 (EDT) (envelope-from morganw@chemikals.org) X-Authentication-Warning: volatile.chemikals.org: morganw owned process doing -bs Date: Sat, 30 Oct 2004 14:06:41 -0400 (EDT) From: Wesley Morgan To: Gary Corcoran In-Reply-To: <4183D5C2.3050400@comcast.net> Message-ID: <20041030140501.U19848@volatile.chemikals.org> References: <20041030130911.E18406@volatile.chemikals.org> <4183D5C2.3050400@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-fs@freebsd.org Subject: Re: msdosfs on D70 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 18:07:02 -0000 On Sat, 30 Oct 2004, Gary Corcoran wrote: > Wesley Morgan wrote: > >> I can't seem to mount the FAT32 fs created by my D70. Windows and mtools >> both are able to read it just fine. Has anyone encountered this problem? >> The output from fdisk and "minfo" are below. Perhaps someone can get this >> working properly! :) > > Somebody might be able to help you if you explained > what a "D70" is... Sorry, slipped my mind. It's a digital camera, a "Nikon D70" as indicated in the disk label. The error is simply: mountmsdosfs(): bad FAT32 filesystem > >> sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) >> start 63, size 7998417 (3905 Meg), flag 80 (active) >> beg: cyl 0/ head 1/ sector 1; >> end: cyl 766/ head 15/ sector 63 >> bootsector information >> ====================== >> banner:"MSDOS5.0" >> sector size: 512 bytes >> cluster size: 64 sectors >> reserved (boot) sectors: 32 >> fats: 2 >> max available root directory slots: 0 >> small size: 0 sectors >> media descriptor byte: 0xf8 >> sectors per fat: 0 >> sectors per track: 63 >> heads: 16 >> hidden sectors: 63 >> big size: 7998417 sectors >> physical drive id: 0x80 >> reserved=0x0 >> dos4=0x29 >> serial number: 00000000 >> disk label="NIKON D70 " >> disk type="FAT32 " >> Big fatlen=977 >> Extended flags=0x0000 >> FS version=0x0000 >> rootCluster=2 >> infoSector location=1 >> backup boot sector=6 >> >> Infosector: >> signature=0x41615252 >> free clusters=69396 >> last allocated cluster=2 >> >> >> > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:18:46 2004 Return-Path: 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 D2EB416A4CE for ; Sat, 30 Oct 2004 18:18:46 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 607C343D2D for ; Sat, 30 Oct 2004 18:18:46 +0000 (GMT) (envelope-from garycor@comcast.net) Received: from [10.56.78.111] (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (rwcrmhc11) with ESMTP id <2004103018183301300bu8hne> (Authid: garycor); Sat, 30 Oct 2004 18:18:43 +0000 Message-ID: <4183DB9B.90104@comcast.net> Date: Sat, 30 Oct 2004 14:21:15 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Morgan References: <20041030130911.E18406@volatile.chemikals.org> <4183D5C2.3050400@comcast.net> <20041030140501.U19848@volatile.chemikals.org> In-Reply-To: <20041030140501.U19848@volatile.chemikals.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org Subject: Re: msdosfs on D70 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 18:18:47 -0000 Wesley Morgan wrote: > On Sat, 30 Oct 2004, Gary Corcoran wrote: > >> Wesley Morgan wrote: >> >>> I can't seem to mount the FAT32 fs created by my D70. Windows and >>> mtools both are able to read it just fine. Has anyone encountered >>> this problem? >>> The output from fdisk and "minfo" are below. Perhaps someone can get >>> this working properly! :) >> >> >> Somebody might be able to help you if you explained >> what a "D70" is... > > > Sorry, slipped my mind. It's a digital camera, a "Nikon D70" as > indicated in the disk label. Oh, okay - so this is presumably a filesystem on a Flash card then? > The error is simply: > > mountmsdosfs(): bad FAT32 filesystem > >> >>> sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) >>> start 63, size 7998417 (3905 Meg), flag 80 (active) >>> beg: cyl 0/ head 1/ sector 1; >>> end: cyl 766/ head 15/ sector 63 If it is Flash, the above says it's (about) a 4GB (3905MB) filesystem. Do you really have a 4GB Flash card? If not, maybe that's why it complains, because of inconsistencies with other values? Can you possibly format it via FreeBSD, then maybe everyone (OSes) will be happy? Sorry, can't help you beyond this... Gary >>> bootsector information >>> ====================== >>> banner:"MSDOS5.0" >>> sector size: 512 bytes >>> cluster size: 64 sectors >>> reserved (boot) sectors: 32 >>> fats: 2 >>> max available root directory slots: 0 >>> small size: 0 sectors >>> media descriptor byte: 0xf8 >>> sectors per fat: 0 >>> sectors per track: 63 >>> heads: 16 >>> hidden sectors: 63 >>> big size: 7998417 sectors >>> physical drive id: 0x80 >>> reserved=0x0 >>> dos4=0x29 >>> serial number: 00000000 >>> disk label="NIKON D70 " >>> disk type="FAT32 " >>> Big fatlen=977 >>> Extended flags=0x0000 >>> FS version=0x0000 >>> rootCluster=2 >>> infoSector location=1 >>> backup boot sector=6 >>> >>> Infosector: >>> signature=0x41615252 >>> free clusters=69396 >>> last allocated cluster=2 >>> >>> >>> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > From owner-freebsd-fs@FreeBSD.ORG Sat Oct 30 18:55:23 2004 Return-Path: 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 2B14916A4CF for ; Sat, 30 Oct 2004 18:55:23 +0000 (GMT) Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4EA043D41 for ; Sat, 30 Oct 2004 18:55:22 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.rr.com [24.211.118.154])i9UIt9Ch005961; Sat, 30 Oct 2004 14:55:09 -0400 (EDT) Received: from volatile.chemikals.org (morganw@localhost [127.0.0.1]) i9UIt8tc020393; Sat, 30 Oct 2004 14:55:08 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost)i9UIt869020390; Sat, 30 Oct 2004 14:55:08 -0400 (EDT) (envelope-from morganw@chemikals.org) X-Authentication-Warning: volatile.chemikals.org: morganw owned process doing -bs Date: Sat, 30 Oct 2004 14:55:08 -0400 (EDT) From: Wesley Morgan To: Gary Corcoran In-Reply-To: <4183DB9B.90104@comcast.net> Message-ID: <20041030144903.S19848@volatile.chemikals.org> References: <20041030130911.E18406@volatile.chemikals.org> <4183D5C2.3050400@comcast.net><4183DB9B.90104@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-fs@freebsd.org Subject: Re: msdosfs on D70 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2004 18:55:23 -0000 On Sat, 30 Oct 2004, Gary Corcoran wrote: > Wesley Morgan wrote: > >> On Sat, 30 Oct 2004, Gary Corcoran wrote: >> >>> Wesley Morgan wrote: >>> >>>> I can't seem to mount the FAT32 fs created by my D70. Windows and >>>> mtools both are able to read it just fine. Has anyone encountered this >>>> problem? >>>> The output from fdisk and "minfo" are below. Perhaps someone can get >>>> this working properly! :) >>> >>> >>> Somebody might be able to help you if you explained >>> what a "D70" is... >> >> >> Sorry, slipped my mind. It's a digital camera, a "Nikon D70" as indicated >> in the disk label. > > Oh, okay - so this is presumably a filesystem on a Flash card then? It's on a Hitachi 4gb microdrive (not one of the "white" drives, either). >> The error is simply: >> >> mountmsdosfs(): bad FAT32 filesystem >> >>> >>>> sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) >>>> start 63, size 7998417 (3905 Meg), flag 80 (active) >>>> beg: cyl 0/ head 1/ sector 1; >>>> end: cyl 766/ head 15/ sector 63 > > If it is Flash, the above says it's (about) a 4GB (3905MB) filesystem. > Do you really have a 4GB Flash card? If not, maybe that's > why it complains, because of inconsistencies with other values? > Can you possibly format it via FreeBSD, then maybe everyone > (OSes) will be happy? Sorry, can't help you beyond this... > > Gary > >>>> bootsector information >>>> ====================== >>>> banner:"MSDOS5.0" >>>> sector size: 512 bytes >>>> cluster size: 64 sectors >>>> reserved (boot) sectors: 32 >>>> fats: 2 >>>> max available root directory slots: 0 >>>> small size: 0 sectors >>>> media descriptor byte: 0xf8 >>>> sectors per fat: 0 >>>> sectors per track: 63 >>>> heads: 16 >>>> hidden sectors: 63 >>>> big size: 7998417 sectors >>>> physical drive id: 0x80 >>>> reserved=0x0 >>>> dos4=0x29 >>>> serial number: 00000000 >>>> disk label="NIKON D70 " >>>> disk type="FAT32 " >>>> Big fatlen=977 >>>> Extended flags=0x0000 >>>> FS version=0x0000 >>>> rootCluster=2 >>>> infoSector location=1 >>>> backup boot sector=6 >>>> >>>> Infosector: >>>> signature=0x41615252 >>>> free clusters=69396 >>>> last allocated cluster=2 >>>> >>>> >>>> >>> >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>> >> > -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!