From owner-freebsd-fs Sun Jun 16 14:24:16 2002 Delivered-To: freebsd-fs@freebsd.org Received: from moya.lambermont.dyndns.org (e165253.upc-e.chello.nl [213.93.165.253]) by hub.freebsd.org (Postfix) with ESMTP id 24F4D37B41C; Sun, 16 Jun 2002 14:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by moya.lambermont.dyndns.org (Postfix) with ESMTP id 81CE236413; Sun, 16 Jun 2002 23:24:03 +0200 (CEST) Received: by moya.lambermont.dyndns.org (Postfix, from userid 1001) id CC39536405; Sun, 16 Jun 2002 23:24:01 +0200 (CEST) Date: Sun, 16 Jun 2002 23:24:01 +0200 To: freebsd-stable@freebsd.org Cc: freebsd-fs@freebsd.org Subject: fdisk seems broken for slices above cyl 1023 Message-ID: <20020616232401.C91106@moya.lambermont.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: hans@lambermont.dyndns.org (Hans Lambermont) X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm battling with fdisk on a 20 GB disk with 4 slices. This is the disk: ad0: 19077MB [38760/16/63] at ata0-master UDMA100 On FreeBSD 4.6-RC #1: Sun Jun 16 2002 Fdisk translates the geometry to : cylinders=2584 heads=240 sectors/track=63 (15120 blks/cyl) This disk was partitioned during sysinstal in 4 slices: /dev/ad0s1 Suspend to Disk, 0.3 GB /dev/ad0s2 FreeBSD slice 1, 8.3 GB /dev/ad0s3 FreeBSD slice 2, 8.3 GB /dev/ad0s4 other, 2.4 GB fdisk -i shows: ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=2584 heads=240 sectors/track=63 (15120 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=2584 heads=240 sectors/track=63 (15120 blks/cyl) 240*63 = 15120 sectors/cyl Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 160,(Suspend to Disk) start 63, size 604737 (295 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 39/ head 239/ sector 63 The data for partition 2 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 604800, size 16768080 (8187 Meg), flag 80 (active) beg: cyl 40/ head 0/ sector 1; end: cyl 1023/ head 239/ sector 63 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 17372880, size 16768080 (8187 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 239/ sector 63 The data for partition 4 is: sysid 6,(Primary 'big' DOS (> 32MB)) start 34140960, size 4929120 (2406 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 239/ sector 63 Note that in slice 2 the 1023 cylinder is crossed, from here on all begin/end cylinder stuff is corrupt (all set to 1023). So I calculated (*sweat*) the right start/end cylinders, heads and sectors. This is what it should have been: s1 start 63, size 604737 beg: cyl 0 head 1 sector 1 (0*15120 + 1*63 + 1-1 = 63) end: cyl 39 head 239 sector 63 (39*15120 + 239*63 + 63-1 = 604799) s2 start 604800, size 16768080 beg: cyl 40 head 0 sector 1 (40*15120 + 0*63 + 1-1 = 604800) end: cyl 1148 head 239 sector 63 (1148*15120 + 239*63 + 63-1 = 17372879) s3 start 17372880, size 16768080 beg: cyl 1149 head 0 sector 1 (1149*15120 + 0*63 + 1-1 = 17372880) end: cyl 2257 head 239 sector 63 (2257*15120 + 239*63 + 63-1 = 34140959) s4 start 34140960, size 4929120 beg: cyl 2258 head 0 sector 1 (2258*15120 + 0*63 + 1-1 = 34140960) end: cyl 2583 head 239 sector 63 (2583*15120 + 239*63 + 63-1 = 39070079) I wanted to change the sysid of slice 4, for this I have to fix all corrupt start/end settings first, because the whole table is written and not just the new sysid. So here is the first slice with corrupt begin/end settings: fdisk -u, select slice 2, try to fix the corrupt end cylinder from 1023 to 1148 : sysid 165,(FreeBSD/NetBSD/386BSD) start 604800, size 16768080 (8187 Meg), flag 80 (active) beg: cyl 40/ head 0/ sector 1; end: cyl 1023/ head 239/ sector 63 Do you want to change it? [n] y Supply a decimal value for "sysid (165=FreeBSD)" [165] Supply a decimal value for "start" [604800] Supply a decimal value for "size" [16768080] Explicitly specify beg/end address ? [n] sysid 165,(FreeBSD/NetBSD/386BSD) start 604800, size 16768080 (8187 Meg), flag 80 (active) beg: cyl 40/ head 0/ sector 1; end: cyl 124/ head 239/ sector 63 what ?! 124 ? This is not correct, so : Are we happy with this entry? [n] n Supply a decimal value for "sysid (165=FreeBSD)" [165] Supply a decimal value for "start" [604800] Supply a decimal value for "size" [16768080] Explicitly specify beg/end address ? [n] y Supply a decimal value for "beginning cylinder" [40] Supply a decimal value for "beginning head" [0] Supply a decimal value for "beginning sector" [1] Supply a decimal value for "ending cylinder" [124] 1148 Supply a decimal value for "ending head" [239] Supply a decimal value for "ending sector" [63] sysid 165,(FreeBSD/NetBSD/386BSD) start 604800, size 16768080 (8187 Meg), flag 80 (active) beg: cyl 40/ head 0/ sector 1; end: cyl 124/ head 239/ sector 63 Still 124 ?! This is seriously wrong. This looks like an fdisk bug to me. Any help is appreciated. Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 16:32:42 2002 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 08B3137B41D; Sun, 16 Jun 2002 16:32:36 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id CFB0281457; Mon, 17 Jun 2002 09:02:33 +0930 (CST) Date: Mon, 17 Jun 2002 09:02:33 +0930 From: Greg 'groggy' Lehey To: Hans Lambermont Cc: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: fdisk seems broken for slices above cyl 1023 Message-ID: <20020616233233.GC56375@wantadilla.lemis.com> References: <20020616232401.C91106@moya.lambermont.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020616232401.C91106@moya.lambermont.dyndns.org> User-Agent: Mutt/1.3.99i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sunday, 16 June 2002 at 23:24:01 +0200, Hans Lambermont wrote: > Hi, > > I'm battling with fdisk on a 20 GB disk with 4 slices. > > This is the disk: > ad0: 19077MB [38760/16/63] at ata0-master UDMA100 > On FreeBSD 4.6-RC #1: Sun Jun 16 2002 > Fdisk translates the geometry to : cylinders=2584 heads=240 > sectors/track=63 (15120 blks/cyl) > > This disk was partitioned during sysinstal in 4 slices: > /dev/ad0s1 Suspend to Disk, 0.3 GB > /dev/ad0s2 FreeBSD slice 1, 8.3 GB > /dev/ad0s3 FreeBSD slice 2, 8.3 GB > /dev/ad0s4 other, 2.4 GB > (etc) > Still 124 ?! > > This is seriously wrong. This looks like an fdisk bug to me. Yes, correct. fdisk truncates the cylinder number to 10 bits. I looked at the code a couple of days ago, but it's such a mess that the best thing to do would be to throw it away and start again, possibly importing something from NetBSD or OpenBSD. > Any help is appreciated. Don't talk about cylinders with fdisk. It works OK with LBA mode (start and end sector). Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 17: 6:17 2002 Delivered-To: freebsd-fs@freebsd.org Received: from dc-mx03.cluster1.charter.net (dc-mx03.cluster1.charter.net [209.225.8.13]) by hub.freebsd.org (Postfix) with ESMTP id 8433D37B407; Sun, 16 Jun 2002 17:06:14 -0700 (PDT) Received: from [24.217.145.63] (HELO there) by dc-mx03.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 27375458; Sun, 16 Jun 2002 20:06:10 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Dave Uhring To: Greg 'groggy' Lehey , Hans Lambermont Subject: Re: fdisk seems broken for slices above cyl 1023 Date: Sun, 16 Jun 2002 19:06:13 -0500 X-Mailer: KMail [version 1.3.2] Cc: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org References: <20020616232401.C91106@moya.lambermont.dyndns.org> <20020616233233.GC56375@wantadilla.lemis.com> In-Reply-To: <20020616233233.GC56375@wantadilla.lemis.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-ID: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sunday 16 June 2002 06:32 pm, Greg 'groggy' Lehey wrote: > > Yes, correct. fdisk truncates the cylinder number to 10 bits. I > looked at the code a couple of days ago, but it's such a mess that > the best thing to do would be to throw it away and start again, > possibly importing something from NetBSD or OpenBSD. The fdisk utility from both NetBSD and OpenBSD have been unable to=20 recognize any drive larger than 1024 cylinders in my experience. I=20 would recommend you use them before importing any of their code. The only fdisk utility which I have found to work consistently well=20 with large drives is the one used in the Linux distros. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 17:14:49 2002 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 1DE8E37B43B; Sun, 16 Jun 2002 17:14:45 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 0550981457; Mon, 17 Jun 2002 09:44:41 +0930 (CST) Date: Mon, 17 Jun 2002 09:44:40 +0930 From: Greg 'groggy' Lehey To: Dave Uhring Cc: Hans Lambermont , freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: fdisk seems broken for slices above cyl 1023 Message-ID: <20020617001440.GE56375@wantadilla.lemis.com> References: <20020616232401.C91106@moya.lambermont.dyndns.org> <20020616233233.GC56375@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sunday, 16 June 2002 at 19:06:13 -0500, Dave Uhring wrote: > On Sunday 16 June 2002 06:32 pm, Greg 'groggy' Lehey wrote: > >> >> Yes, correct. fdisk truncates the cylinder number to 10 bits. I >> looked at the code a couple of days ago, but it's such a mess that >> the best thing to do would be to throw it away and start again, >> possibly importing something from NetBSD or OpenBSD. > > The fdisk utility from both NetBSD and OpenBSD have been unable to > recognize any drive larger than 1024 cylinders in my experience. I > would recommend you use them before importing any of their code. "Please test before committing" :-) Yes, I had certainly planned to do that. > The only fdisk utility which I have found to work consistently well > with large drives is the one used in the Linux distros. It's unlikely that we'll import that due to license considerations. My consideration of the other BSD fdisks is that they might be a better starting point. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 18:36:42 2002 Delivered-To: freebsd-fs@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 901F637B41A; Sun, 16 Jun 2002 18:36:35 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g5H1aYY29878; Sun, 16 Jun 2002 19:36:34 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g5H1aWG65173; Sun, 16 Jun 2002 19:36:33 -0600 (MDT) (envelope-from imp@village.org) Date: Sun, 16 Jun 2002 19:34:50 -0600 (MDT) Message-Id: <20020616.193450.124991810.imp@village.org> To: grog@FreeBSD.ORG Cc: hans@lambermont.dyndns.org, freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: fdisk seems broken for slices above cyl 1023 From: "M. Warner Losh" In-Reply-To: <20020616233233.GC56375@wantadilla.lemis.com> References: <20020616232401.C91106@moya.lambermont.dyndns.org> <20020616233233.GC56375@wantadilla.lemis.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: <20020616233233.GC56375@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : On Sunday, 16 June 2002 at 23:24:01 +0200, Hans Lambermont wrote: : > Hi, : > : > I'm battling with fdisk on a 20 GB disk with 4 slices. : > : > This is the disk: : > ad0: 19077MB [38760/16/63] at ata0-master UDMA100 : > On FreeBSD 4.6-RC #1: Sun Jun 16 2002 : > Fdisk translates the geometry to : cylinders=2584 heads=240 : > sectors/track=63 (15120 blks/cyl) : > : > This disk was partitioned during sysinstal in 4 slices: : > /dev/ad0s1 Suspend to Disk, 0.3 GB : > /dev/ad0s2 FreeBSD slice 1, 8.3 GB : > /dev/ad0s3 FreeBSD slice 2, 8.3 GB : > /dev/ad0s4 other, 2.4 GB : > (etc) : > Still 124 ?! : > : > This is seriously wrong. This looks like an fdisk bug to me. : : Yes, correct. fdisk truncates the cylinder number to 10 bits. I : looked at the code a couple of days ago, but it's such a mess that the : best thing to do would be to throw it away and start again, possibly : importing something from NetBSD or OpenBSD. This is not a bug, but rather the correct way to set things up with pc hardware. The MBR requires stupid things like this :-(. I'd love to import another fdisk too, ours really is a mess. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 20:40:17 2002 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 49BF837B406; Sun, 16 Jun 2002 20:40:05 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA00580; Mon, 17 Jun 2002 13:40:01 +1000 Date: Mon, 17 Jun 2002 13:44:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Greg 'groggy' Lehey" Cc: Hans Lambermont , , Subject: Re: fdisk seems broken for slices above cyl 1023 In-Reply-To: <20020616233233.GC56375@wantadilla.lemis.com> Message-ID: <20020617125915.H3073-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 17 Jun 2002, Greg 'groggy' Lehey wrote: > On Sunday, 16 June 2002 at 23:24:01 +0200, Hans Lambermont wrote: > > Hi, > > > > I'm battling with fdisk on a 20 GB disk with 4 slices. > > > > This is the disk: > > ad0: 19077MB [38760/16/63] at ata0-master UDMA100 > > On FreeBSD 4.6-RC #1: Sun Jun 16 2002 > > Fdisk translates the geometry to : cylinders=2584 heads=240 > > sectors/track=63 (15120 blks/cyl) > > > > This disk was partitioned during sysinstal in 4 slices: > > /dev/ad0s1 Suspend to Disk, 0.3 GB > > /dev/ad0s2 FreeBSD slice 1, 8.3 GB > > /dev/ad0s3 FreeBSD slice 2, 8.3 GB > > /dev/ad0s4 other, 2.4 GB > > (etc) > > Still 124 ?! > > > > This is seriously wrong. This looks like an fdisk bug to me. This is correct and not a bug. C/H/S values in fdisk tables are limited to 10/8/6 bits, respectively, so the best tha can be done with a 'C' value larger than 1023 is truncate it mod 1024. FreeBSD's fdisk(8) does this. However, over the last few years, some bad hacks for clipping the CHS values have become less nonstandard, and are required to satisfy some broken BIOSes. Your original fdisk entries (not shown above) seem to have been created by an fdisk that supports this. IIRC, the starting CHS for partitions starting on a cylinder > 1023 are 1023/254/63, and the ending CHS is 1023/[actual H]/[actual S]. The starting head number must be 254, not the maximum representable head number of 255, to work around other bugs in other or the same broken BIOSes. > Yes, correct. fdisk truncates the cylinder number to 10 bits. I > looked at the code a couple of days ago, but it's such a mess that the > best thing to do would be to throw it away and start again, possibly > importing something from NetBSD or OpenBSD. No thanks. Why is unaudited grass always considered greener by those who don't use it? I know that the 1988 Minix fdisk is better because I wrote most of it, and even early Linux command line fdisks are better because they apparently obtained a lot from the Minix one, but copyright and political considerations prevented importing these even before there was a FreeBSD fdisk with different features to clobber. > > Any help is appreciated. > > Don't talk about cylinders with fdisk. It works OK with LBA mode > (start and end sector). CHS must be set correctly for booting on some systems. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jun 16 21:51:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 4BC2A37B404; Sun, 16 Jun 2002 21:51:13 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5H4naV7022032; Mon, 17 Jun 2002 06:49:36 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Greg 'groggy' Lehey" Cc: Hans Lambermont , freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: fdisk seems broken for slices above cyl 1023 In-Reply-To: Your message of "Mon, 17 Jun 2002 09:02:33 +0930." <20020616233233.GC56375@wantadilla.lemis.com> Date: Mon, 17 Jun 2002 06:49:36 +0200 Message-ID: <22031.1024289376@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020616233233.GC56375@wantadilla.lemis.com>, "Greg 'groggy' Lehey" writes: >> This is seriously wrong. This looks like an fdisk bug to me. > >Yes, correct. fdisk truncates the cylinder number to 10 bits. I >looked at the code a couple of days ago, but it's such a mess that the >best thing to do would be to throw it away and start again, possibly >importing something from NetBSD or OpenBSD. This answer is wrong in every important aspect: The cylinder field is only 10 bits wide in the MBR, so fdisk can't help but truncate the cylinder field. NetBSD or OpenBSD fdisk are no better than ours. George Cox is working on "libwhisk" which will supposedly take care of fdisk, disklabel, libdisk and sysinstall once done. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jun 17 0:53: 7 2002 Delivered-To: freebsd-fs@freebsd.org Received: from moya.lambermont.dyndns.org (e165253.upc-e.chello.nl [213.93.165.253]) by hub.freebsd.org (Postfix) with ESMTP id A689D37B41D; Mon, 17 Jun 2002 00:52:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by moya.lambermont.dyndns.org (Postfix) with ESMTP id 0B6C236413; Mon, 17 Jun 2002 09:52:43 +0200 (CEST) Received: by moya.lambermont.dyndns.org (Postfix, from userid 1001) id 4B71F36405; Mon, 17 Jun 2002 09:52:41 +0200 (CEST) Date: Mon, 17 Jun 2002 09:52:41 +0200 To: Bruce Evans Cc: freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: fdisk seems broken for slices above cyl 1023 Message-ID: <20020617095241.A51682@moya.lambermont.dyndns.org> References: <20020616233233.GC56375@wantadilla.lemis.com> <20020617125915.H3073-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020617125915.H3073-100000@gamplex.bde.org>; from bde@zeta.org.au on Mon, Jun 17, 2002 at 01:44:41PM +1000 From: hans@lambermont.dyndns.org (Hans Lambermont) X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > On Mon, 17 Jun 2002, Greg 'groggy' Lehey wrote: > > This is correct and not a bug. C/H/S values in fdisk tables are limited > to 10/8/6 bits, respectively, so the best tha can be done with a 'C' > value larger than 1023 is truncate it mod 1024. Ok, this makes sense. > FreeBSD's fdisk(8) does this. However, over the last few years, some > bad hacks for clipping the CHS values have become less nonstandard, > and are required to satisfy some broken BIOSes. Your original fdisk > entries (not shown above) seem to have been created by an fdisk that > supports this. That's interesting then. This disk was labeled by the install procedure from 4.5-R ! So I assume that the same fdisk is responsible for this. > On Mon, 17 Jun 2002, Greg 'groggy' Lehey wrote: > > Don't talk about cylinders with fdisk. It works OK with LBA mode > > (start and end sector). Are you saying that I can ignore the cyl stuff completely ? I can just write a cyl-overlapping table with the right start/end sector stuff ? Should I set all start/end cylinders above 1023 to 1023 to be safe ? > CHS must be set correctly for booting on some systems. Then I'm in luck, the 3th slice is still bootable :) Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 7:41:32 2002 Delivered-To: freebsd-fs@freebsd.org Received: from lockdown.spectrum.fearmuffs.net (c164-147.pro.thalamus.se [212.31.164.147]) by hub.freebsd.org (Postfix) with ESMTP id 98D0337B40B for ; Wed, 19 Jun 2002 07:41:11 -0700 (PDT) Received: from lockdown.spectrum.fearmuffs.net (localhost.spectrum.fearmuffs.net [127.0.0.1]) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3) with ESMTP id g5JEfBvb001888 for ; Wed, 19 Jun 2002 16:41:11 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Received: (from redpixel@localhost) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3/Submit) id g5JEfBeo001887 for freebsd-fs@FreeBSD.org; Wed, 19 Jun 2002 16:41:11 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Date: Wed, 19 Jun 2002 16:41:11 +0200 From: Martin Faxer To: freebsd-fs@FreeBSD.org Subject: a bunch of questions Message-ID: <20020619144111.GA1352@lockdown.spectrum.fearmuffs.net> Mail-Followup-To: freebsd-fs@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.99i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hello! i'm trying to make some sense of vfs and here comes a mail with basically (as the subject says) a bunch of questions: 1) why is it preferred to do the permissions checking in the actual file system specific code instead of vfs_[n]mount()? what i mean is that eg. the ffs code does a permissions check in the !superuser case to see if the user has the necessary permissions on the device (ffs_vfsops.c:ffs_mount()). at the same time vfs_[n]mount() does a permissions check to make sure that the user owns the directory he/she is attempting to mount... why is it split up ? 2) in the statfs() code the f_fsid is zeroed out in the !superuser case. after some searching and cross-checking with OpenBSD i'm lead to believe that this is because of a potential NFS insecurity if any user is able to see the f_fsid. does anybody know more about this ? can a check be added like: if (suser(td) != 0 && strcmp(sp->f_fstypename, "nfs") == 0) ? for what it's worth, NetBSD doesn't appear to zero it out so i guess it can't be that serious... 3) can the vnode lock be of type LK_SHARED when i'm doing a VOP_OPEN() operation with only FREAD (and not FWRITE) set ? 4) what does the flags argument to VOP_UNLOCK() mean ? is it something like "resulting flags" ? (i understand what it means in the VOP_LOCK()/vn_lock() case, but i find it a little bit weird in the VOP_UNLOCK() case.) 5) when i call bread() i'm supposed to hold the vnode lock, right ? i have discussed this loosely with Robert Watson and that's the impression i got. 6) after having called bread(), should i lock it in some way before inspecting the contents of the buffer ? as far as i can tell the ufs/ffs code doesn't do this, at least not in the mount case, but i'm not quite sure if that's correct or simply works because you don't modify the superblock so often. i'm actively reading through the code and understanding more and more for each line, but it's not easy to make sense of everything right away, especially not when you're just a junior kernel hacker like me. i would greatly appreciate some answers to these questions and i believe it will really clear things up, even if only somebody else says what i already know. :) thanks in advance, Martin Faxйr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 8: 4:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1481637B406 for ; Wed, 19 Jun 2002 08:04:08 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g5JF2GIj012748; Wed, 19 Jun 2002 17:02:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Martin Faxer Cc: freebsd-fs@FreeBSD.ORG Subject: Re: a bunch of questions In-Reply-To: Your message of "Wed, 19 Jun 2002 16:41:11 +0200." <20020619144111.GA1352@lockdown.spectrum.fearmuffs.net> Date: Wed, 19 Jun 2002 17:02:16 +0200 Message-ID: <12747.1024498936@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020619144111.GA1352@lockdown.spectrum.fearmuffs.net>, Martin Faxe r writes: >hello! > >i'm trying to make some sense of vfs and here comes a mail with >basically (as the subject says) a bunch of questions: > >1) why is it preferred to do the permissions checking in the > actual file system specific code instead of vfs_[n]mount()? Because not all filesystems need or indeed want the same permissions checks. Some filesystems don't even have a device (DEVFS, procfs, unionfs etc) >2) in the statfs() code the f_fsid is zeroed out in the !superuser > case. after some searching and cross-checking with OpenBSD i'm > lead to believe that this is because of a potential NFS insecurity > if any user is able to see the f_fsid. does anybody know more > about this ? can a check be added like: I belive it is because of the NFS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 10:21:40 2002 Delivered-To: freebsd-fs@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id 9379537B436; Wed, 19 Jun 2002 10:21:16 -0700 (PDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g5JHKol13547; Wed, 19 Jun 2002 10:20:50 -0700 (PDT) Date: Wed, 19 Jun 2002 10:20:50 -0700 From: JJ Behrens To: Dave Uhring , "Greg 'groggy' Lehey" , Hans Lambermont , .freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: fdisk seems broken for slices above cyl 1023 Message-ID: <20020619102050.B16914@alicia.nttmcl.com> References: <20020616232401.C91106@moya.lambermont.dyndns.org> <20020616233233.GC56375@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from duhring@charter.net on Sun, Jun 16, 2002 at 07:06:13PM -0500 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The fdisk utility from both NetBSD and OpenBSD have been unable to > recognize any drive larger than 1024 cylinders in my experience. I > would recommend you use them before importing any of their code. > > The only fdisk utility which I have found to work consistently well > with large drives is the one used in the Linux distros. Hmm, perhaps I am misunderstanding you, so I welcome your corrections. However, OpenBSD was successfully able to partition my large drive using LBA. Although the user interface did not work successfully, the partitioning was successful, and I was able to dual-boot FreeBSD and OpenBSD on my laptop. Nonetheless, I agree with you that Linux's fdisk is orders of magnitude nicer. Best Regards, -jj -- Users of C++ should consider hanging themselves rather than shooting their legs off--it's best not to use C++ simply as a better C. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 16:24:57 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mail.nebulatech.com (nebulatech.com [63.203.53.131]) by hub.freebsd.org (Postfix) with ESMTP id 014AE37B408; Wed, 19 Jun 2002 16:24:39 -0700 (PDT) Received: from mail.ru ([210.172.90.115]) by mail.nebulatech.com (Netscape Messaging Server 3.5) with SMTP id 323; Wed, 19 Jun 2002 16:18:04 -0700 From: NOVIKOV To: "" <> Subject: ФИЛЬМ "Горец" с МаКлаудом имеет реальную основу!!!! Reply-To: vppzqn@mailru.com X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Thu, 20 Jun 2002 03:23:01 +0400 Message-ID: <20020619231738671.AAA449.323@mail.ru> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Теперь это ты можешь знать!!! Как всегда человек думает ,что чудеса не для него.!? Моя история и моя жизнь теперь открыта для тебя: http://multimail.ru/people/novikov Что ж,удивись, не мне,а тому,что это можешь быть и ТЫ! Да, ты можешь жить так долго и здоровым,что сам еще не знаешь! Мне сейчас 73 года, а на самом деле не дашь и 45! (см. мои фото) Я расскажу как сделать себя молодым с любого возраста, даже если ты уже готовишься к самому плохому -к смерти. Приветствую тебя мой будущий друг. Сергей Новиков. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 17:25:59 2002 Delivered-To: freebsd-fs@freebsd.org Received: from viola.sinor.ru (viola.sinor.ru [217.70.106.9]) by hub.freebsd.org (Postfix) with ESMTP id 4CF5B37B411; Wed, 19 Jun 2002 17:25:43 -0700 (PDT) Received: from p98.tc1.snt.ru (p98.tc1.snt.ru [217.70.126.98]) by viola.sinor.ru (8.9.3/8.9.3) with ESMTP id HAA21225; Thu, 20 Jun 2002 07:24:22 +0700 Date: Thu, 20 Jun 2002 07:26:41 +0700 (NOVST) From: "Semen A. Ustimenko" X-X-Sender: semenu@def.the.net To: Joseph Scott Cc: Boris Popov , , Subject: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) In-Reply-To: <20020614064339.K3828-100000@def.the.net> Message-ID: <20020620070637.P3227-100000@def.the.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! Sorry for not fully investigated reply. There is no other problem in UFS, than that it hides the problem because it allows recursive lock to happen instead of ``locking against myself'' panic. The kern/37270 problem is in NULLFS. Step-by-step: NULLFS disregard LK_DRAIN flag. This means that the vnode may be successfully vclean()ed while some process was just sitting in vrele()->VOP_LOCK()->null_lock()->lockmgr(vp->v_vnlock) The above is exactly what leads to deadlock reported in PR, because when the lockmgr() exits, the nullfs vnode is already destroyed! Even though VOP_INACTIVE() is called, it can't unload the shared v_vnlock :( If anybody have ideas about how to fix this, please do not hesitate to share, but I can prevent you, that as soon as you begin to honor the LK_DRAIN flag, you immediately hit the deadlock I reported some time before. (IMHO, you don't hit it cause you usually win the race, but LK_DRAIN is born to loose it) Bye! On Sat, 15 Jun 2002, Semen A. Ustimenko wrote: > Hi! > > On Thu, 13 Jun 2002, Joseph Scott wrote: > > > On Thu, 13 Jun 2002, Semen Ustimenko wrote: > > > > # semenu 2002/06/13 10:30:40 PDT > > # > > # Modified files: > > # sys/fs/nullfs null_vnops.c > > # Log: > > # Fix wrong locking in null_inactive and null_reclaim. This makes nullfs > > # relatively working back. > > # > > # Reviewed by: mckusick, bp > > > > Any chance that this fix addresses PR kern/38107 (Panic on > > nullfs) or kern/37270 (nullfs broken by locking changes)? Unfortunately I > > don't understand what's involved here. These were the only two PR that > > mentioned nullfs that looked like they might be related to this commit. > > > Partially... > > kern/37270: This patch fixes the bug introduced in r1.51, but not the > problem with SHARED_LOOKUP. > > kern/38107: The panic is because v_rdev get dereferenced. It's not quite > clear to me how to create shadow vnode for spec vnode, neither if it is > necessary at all. > > I've just verified your method to deadlock, and it worked nicely (I mean > deadlocked nicely :). Here is what I found: > > When looking up the DOTDOT, in vfs_cache_lookup(), we VOP_UNLOCK() > parent directory, this is quite right... But the directory remains locked, > because it was recursively locked! This leads to deadlock... > > UFS allows the vnodes to be recursively locked and it seems that > softupdates require this. UFS gurus? > > Bye! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jun 19 22:44:27 2002 Delivered-To: freebsd-fs@freebsd.org Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by hub.freebsd.org (Postfix) with ESMTP id 1116437B40E; Wed, 19 Jun 2002 22:44:22 -0700 (PDT) Received: by yello.shallow.net (Postfix, from userid 1001) id 861C52A6B; Thu, 20 Jun 2002 15:44:13 +1000 (EST) Date: Thu, 20 Jun 2002 15:44:13 +1000 From: Joshua Goodall To: "Semen A. Ustimenko" Cc: Joseph Scott , Boris Popov , freebsd-fs@FreeBSD.org, jeff@FreeBSD.org Subject: Re: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) Message-ID: <20020620054413.GA82672@roughtrade.net> References: <20020614064339.K3828-100000@def.the.net> <20020620070637.P3227-100000@def.the.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020620070637.P3227-100000@def.the.net> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Semen, It's probably worth appending to 37270, then; my original diagnoses confused the 1.51 bugs with the drain bugs during an investigation of the LOOKUP_SHARED problems and clarity would be appreciated from someone with more VFS clue than I can currently bring on board. Regards Joshua On Thu, Jun 20, 2002 at 07:26:41AM +0700, Semen A. Ustimenko wrote: > Hi! > > Sorry for not fully investigated reply. There is no other problem in UFS, > than that it hides the problem because it allows recursive lock to happen > instead of ``locking against myself'' panic. > > The kern/37270 problem is in NULLFS. Step-by-step: > > NULLFS disregard LK_DRAIN flag. This means that the vnode may be > successfully vclean()ed while some process was just sitting in > vrele()->VOP_LOCK()->null_lock()->lockmgr(vp->v_vnlock) > > The above is exactly what leads to deadlock reported in PR, because when > the lockmgr() exits, the nullfs vnode is already destroyed! Even though > VOP_INACTIVE() is called, it can't unload the shared v_vnlock :( > > If anybody have ideas about how to fix this, please do not hesitate to > share, but I can prevent you, that as soon as you begin to honor the > LK_DRAIN flag, you immediately hit the deadlock I reported some time > before. (IMHO, you don't hit it cause you usually win the race, but > LK_DRAIN is born to loose it) > > Bye! > > On Sat, 15 Jun 2002, Semen A. Ustimenko wrote: > > > Hi! > > > > On Thu, 13 Jun 2002, Joseph Scott wrote: > > > > > On Thu, 13 Jun 2002, Semen Ustimenko wrote: > > > > > > # semenu 2002/06/13 10:30:40 PDT > > > # > > > # Modified files: > > > # sys/fs/nullfs null_vnops.c > > > # Log: > > > # Fix wrong locking in null_inactive and null_reclaim. This makes nullfs > > > # relatively working back. > > > # > > > # Reviewed by: mckusick, bp > > > > > > Any chance that this fix addresses PR kern/38107 (Panic on > > > nullfs) or kern/37270 (nullfs broken by locking changes)? Unfortunately I > > > don't understand what's involved here. These were the only two PR that > > > mentioned nullfs that looked like they might be related to this commit. > > > > > Partially... > > > > kern/37270: This patch fixes the bug introduced in r1.51, but not the > > problem with SHARED_LOOKUP. > > > > kern/38107: The panic is because v_rdev get dereferenced. It's not quite > > clear to me how to create shadow vnode for spec vnode, neither if it is > > necessary at all. > > > > I've just verified your method to deadlock, and it worked nicely (I mean > > deadlocked nicely :). Here is what I found: > > > > When looking up the DOTDOT, in vfs_cache_lookup(), we VOP_UNLOCK() > > parent directory, this is quite right... But the directory remains locked, > > because it was recursively locked! This leads to deadlock... > > > > UFS allows the vnodes to be recursively locked and it seems that > > softupdates require this. UFS gurus? > > > > Bye! > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-fs" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- "Running makeworld fast is important to me. Anything longer than 5-10 minutes is too long, since it is not reasonable to check every commit using makeworld if it takes longer." - Bruce Evans, ultimate guardian of build stability. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jun 20 4:19:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from lockdown.spectrum.fearmuffs.net (c164-147.pro.thalamus.se [212.31.164.147]) by hub.freebsd.org (Postfix) with ESMTP id 568CB37B401 for ; Thu, 20 Jun 2002 04:18:59 -0700 (PDT) Received: from lockdown.spectrum.fearmuffs.net (localhost.spectrum.fearmuffs.net [127.0.0.1]) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3) with ESMTP id g5KBIuXD001057; Thu, 20 Jun 2002 13:18:57 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Received: (from redpixel@localhost) by lockdown.spectrum.fearmuffs.net (8.12.3/8.12.3/Submit) id g5KBIskW001056; Thu, 20 Jun 2002 13:18:54 +0200 (CEST) (envelope-from gmh003532@brfmasthugget.se) Date: Thu, 20 Jun 2002 13:18:53 +0200 From: Martin Faxer To: Poul-Henning Kamp Cc: freebsd-fs@FreeBSD.ORG Subject: Re: a bunch of questions Message-ID: <20020620111853.GA638@lockdown.spectrum.fearmuffs.net> Mail-Followup-To: Poul-Henning Kamp , freebsd-fs@FreeBSD.ORG References: <20020619144111.GA1352@lockdown.spectrum.fearmuffs.net> <12747.1024498936@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12747.1024498936@critter.freebsd.dk> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002.06.19 17:02:16 +0000, Poul-Henning Kamp wrote: > In message <20020619144111.GA1352@lockdown.spectrum.fearmuffs.net>, Martin Faxe > r writes: > > > >1) why is it preferred to do the permissions checking in the > > actual file system specific code instead of vfs_[n]mount()? > > Because not all filesystems need or indeed want the same > permissions checks. > > Some filesystems don't even have a device (DEVFS, procfs, unionfs etc) very true. sorry for not using my brain :) > >2) in the statfs() code the f_fsid is zeroed out in the !superuser > > case. after some searching and cross-checking with OpenBSD i'm > > lead to believe that this is because of a potential NFS insecurity > > if any user is able to see the f_fsid. does anybody know more > > about this ? can a check be added like: > > I belive it is because of the NFS. yes. looks like it's some NFS issue indeed. i wonder if a check that only enabled the f_fsid clearing in the !NFS case would be desired (like the one i described in the original e-mail.) by the way, another issue that i didn't address in my original e-mail that i've thought a little bit about is the f_type member that is returned by struct statfs. it would appear to me as if the f_type member is assigned (at least in the ufs/ffs code) to be vfc_typenum in ffs_statfs(). vfc_typenum is assigned in vfs_register() like this: vfc->vfc_typenum = maxvfsconf++; thus, it looks like f_type is actually a pretty random value, depending on in which order the different file systems get loaded. a friend on irc said that on an old Ultrix system it was actually assigned to mean something, and there was a "reverse lookup" table for mapping f_type to a string with the file system name. i wonder why this was dropped, as it seems to be pretty useless now. (although f_fstypename probably delivers the same functionality it's always nice to be able to check what file system it is without doing a strcmp().) thanks for your answers! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message