From owner-freebsd-fs Sun Jan 10 09:11:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12518 for freebsd-fs-outgoing; Sun, 10 Jan 1999 09:11:57 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12509 for ; Sun, 10 Jan 1999 09:11:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA27906 for ; Sun, 10 Jan 1999 18:11:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA39194 for fs@freebsd.org; Sun, 10 Jan 1999 18:11:18 +0100 (MET) Date: Sun, 10 Jan 1999 18:11:18 +0100 From: Eivind Eklund To: fs@FreeBSD.ORG Subject: Finding a lost FS Message-ID: <19990110181118.F25747@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org An error during some build experiments made disklabel run against the wrong disk, overwriting just the label before quitting. Have anybody got any good starters for how to recover the information on where the FS on that disk is located? I'm presently just running fsck -n -b against the disk, looking for alternate superblocks with good checksums. This has also uncovered at least one bug in fsck (it gives a bus error when scanning the bogus 'file system' described by one of those superblocks), so it is probably an exercise I should do more regularly... Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jan 11 14:05:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08107 for freebsd-fs-outgoing; Mon, 11 Jan 1999 14:05:59 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08083; Mon, 11 Jan 1999 14:05:40 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA02065; Mon, 11 Jan 1999 15:05:01 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd002023; Mon Jan 11 15:04:51 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA01127; Mon, 11 Jan 1999 15:04:50 -0700 (MST) From: Terry Lambert Message-Id: <199901112204.PAA01127@usr05.primenet.com> Subject: Re: Finding a lost FS To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Mon, 11 Jan 1999 22:04:50 +0000 (GMT) Cc: fs@FreeBSD.ORG In-Reply-To: <19990110181118.F25747@bitbox.follo.net> from "Eivind Eklund" at Jan 10, 99 06:11:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > An error during some build experiments made disklabel run against the > wrong disk, overwriting just the label before quitting. Have anybody > got any good starters for how to recover the information on where the > FS on that disk is located? > > I'm presently just running fsck -n -b against the disk, > looking for alternate superblocks with good checksums. This has also > uncovered at least one bug in fsck (it gives a bus error when scanning > the bogus 'file system' described by one of those superblocks), so it > is probably an exercise I should do more regularly... Did you blow the label on the other disk, or just the superblock for the FS in question? If you blew the label, you have to recreate it correctly, since fsck is for checking FS's, not disklabel's that define where FS's start. If you blew the superblock, try 32767; it's common to most FS's that are large enough. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jan 11 14:27:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10685 for freebsd-fs-outgoing; Mon, 11 Jan 1999 14:27:00 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10669 for ; Mon, 11 Jan 1999 14:26:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id XAA08558; Mon, 11 Jan 1999 23:26:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA58181; Mon, 11 Jan 1999 23:25:59 +0100 (MET) Date: Mon, 11 Jan 1999 23:25:58 +0100 From: Eivind Eklund To: Terry Lambert Cc: fs@FreeBSD.ORG Subject: Re: Finding a lost FS Message-ID: <19990111232558.W40114@bitbox.follo.net> References: <19990110181118.F25747@bitbox.follo.net> <199901112204.PAA01127@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901112204.PAA01127@usr05.primenet.com>; from Terry Lambert on Mon, Jan 11, 1999 at 10:04:50PM +0000 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 11, 1999 at 10:04:50PM +0000, Terry Lambert wrote: > > An error during some build experiments made disklabel run against the > > wrong disk, overwriting just the label before quitting. Have anybody > > got any good starters for how to recover the information on where the > > FS on that disk is located? > > > > I'm presently just running fsck -n -b against the disk, > > looking for alternate superblocks with good checksums. This has also > > uncovered at least one bug in fsck (it gives a bus error when scanning > > the bogus 'file system' described by one of those superblocks), so it > > is probably an exercise I should do more regularly... > > Did you blow the label on the other disk, or just the superblock for > the FS in question? Label :-( > If you blew the label, you have to recreate it correctly, since fsck > is for checking FS's, not disklabel's that define where FS's start. I did that just to find the alternate superblocks, hoping to be able to use their location to give me a clue to the correct labelling of the disk. That has not quite worked yet :-( Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jan 11 16:09:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23769 for freebsd-fs-outgoing; Mon, 11 Jan 1999 16:09:00 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA23760; Mon, 11 Jan 1999 16:08:52 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA17420; Tue, 12 Jan 1999 10:38:17 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id KAA30894; Tue, 12 Jan 1999 10:38:16 +1030 (CST) Date: Tue, 12 Jan 1999 10:38:16 +1030 From: Greg Lehey To: Eivind Eklund Cc: fs@FreeBSD.ORG Subject: Re: Finding a lost FS Message-ID: <19990112103816.G8886@freebie.lemis.com> References: <19990110181118.F25747@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990110181118.F25747@bitbox.follo.net>; from Eivind Eklund on Sun, Jan 10, 1999 at 06:11:18PM +0100 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 10 January 1999 at 18:11:18 +0100, Eivind Eklund wrote: > An error during some build experiments made disklabel run against the > wrong disk, overwriting just the label before quitting. Have anybody > got any good starters for how to recover the information on where the > FS on that disk is located? In the days where I did this for a living, we wrote a number of programs to scan disks for likely-looking magic numbers. I'd expect that would work here as well. Go through at 4kB offsets and look for superblocks. It'll take an hour or two to write the program, but people will be grateful forever. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jan 11 16:57:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00262 for freebsd-fs-outgoing; Mon, 11 Jan 1999 16:57:10 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00247; Mon, 11 Jan 1999 16:57:03 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA21621; Mon, 11 Jan 1999 17:56:25 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd021491; Mon Jan 11 17:56:16 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA22622; Mon, 11 Jan 1999 17:56:06 -0700 (MST) From: Terry Lambert Message-Id: <199901120056.RAA22622@usr08.primenet.com> Subject: Re: Finding a lost FS To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Tue, 12 Jan 1999 00:56:05 +0000 (GMT) Cc: tlambert@primenet.com, fs@FreeBSD.ORG In-Reply-To: <19990111232558.W40114@bitbox.follo.net> from "Eivind Eklund" at Jan 11, 99 11:25:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > An error during some build experiments made disklabel run against the > > > wrong disk, overwriting just the label before quitting. Have anybody > > > got any good starters for how to recover the information on where the > > > FS on that disk is located? > > > > > > I'm presently just running fsck -n -b against the disk, > > > looking for alternate superblocks with good checksums. This has also > > > uncovered at least one bug in fsck (it gives a bus error when scanning > > > the bogus 'file system' described by one of those superblocks), so it > > > is probably an exercise I should do more regularly... > > > > Did you blow the label on the other disk, or just the superblock for > > the FS in question? > > Label :-( > > > If you blew the label, you have to recreate it correctly, since fsck > > is for checking FS's, not disklabel's that define where FS's start. > > I did that just to find the alternate superblocks, hoping to be able > to use their location to give me a clue to the correct labelling of > the disk. That has not quite worked yet :-( Ah. You need to search for the FFS "magic number", which will be in the first superblock of each FS partition. You only need to look at cylinder boundaries (if you were careful), and it's a pretty quick scan. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jan 14 17:56:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23358 for freebsd-fs-outgoing; Thu, 14 Jan 1999 17:56:44 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23350 for ; Thu, 14 Jan 1999 17:56:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id CAA28528 for ; Fri, 15 Jan 1999 02:55:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA00486 for fs@freebsd.org; Fri, 15 Jan 1999 02:55:30 +0100 (MET) Date: Fri, 15 Jan 1999 02:55:29 +0100 From: Eivind Eklund To: fs@FreeBSD.ORG Subject: Mount bogosity Message-ID: <19990115025529.A362@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org root(eetest)--# chroot buildstage sh -c 'mount /dev/wd2a /mnt' root(eetest)--# umount buildstage/mnt umount: buildstage/mnt: not currently mounted root(eetest)--# chroot buildstage sh -c 'umount /mnt' This does NOT look correct. I couldn't find any way to unmount the FS without repeating the chroot. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jan 14 18:29:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27451 for freebsd-fs-outgoing; Thu, 14 Jan 1999 18:29:16 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27435 for ; Thu, 14 Jan 1999 18:29:15 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA21672; Thu, 14 Jan 1999 18:27:59 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id SAA28749; Thu, 14 Jan 1999 18:27:58 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA27492; Thu, 14 Jan 1999 18:27:57 -0800 (PST) From: Don Lewis Message-Id: <199901150227.SAA27492@salsa.gv.tsc.tdk.com> Date: Thu, 14 Jan 1999 18:27:57 -0800 In-Reply-To: Eivind Eklund "Mount bogosity" (Jan 15, 2:55am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Eivind Eklund , fs@FreeBSD.ORG Subject: Re: Mount bogosity Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 15, 2:55am, Eivind Eklund wrote: } Subject: Mount bogosity } root(eetest)--# chroot buildstage sh -c 'mount /dev/wd2a /mnt' } root(eetest)--# umount buildstage/mnt } umount: buildstage/mnt: not currently mounted } root(eetest)--# chroot buildstage sh -c 'umount /mnt' } } This does NOT look correct. I couldn't find any way to unmount the FS } without repeating the chroot. umount /dev/wd2a? This stuff is kind of bogus. If you do a mount while chrooted, the full path to the mount point isn't recorded, so mount only displays the partial path. How are you supposed to find the mount point again? It would be nice if the path to the chroot directory was preserved so that the full path could be recorded in the kernel, but this sort of goes against the grain of the Unix philosophy. Even with the full path name in the mount table, you can still mess things up by renaming one of the intermediate directories ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jan 14 20:21:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11602 for freebsd-fs-outgoing; Thu, 14 Jan 1999 20:21:27 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11595 for ; Thu, 14 Jan 1999 20:21:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id FAA00173; Fri, 15 Jan 1999 05:20:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA01296; Fri, 15 Jan 1999 05:20:08 +0100 (MET) Date: Fri, 15 Jan 1999 05:20:08 +0100 From: Eivind Eklund To: Don Lewis Cc: fs@FreeBSD.ORG Subject: Re: Mount bogosity Message-ID: <19990115052007.B362@bitbox.follo.net> References: <199901150227.SAA27492@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901150227.SAA27492@salsa.gv.tsc.tdk.com>; from Don Lewis on Thu, Jan 14, 1999 at 06:27:57PM -0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 14, 1999 at 06:27:57PM -0800, Don Lewis wrote: > On Jan 15, 2:55am, Eivind Eklund wrote: > } Subject: Mount bogosity > } root(eetest)--# chroot buildstage sh -c 'mount /dev/wd2a /mnt' > } root(eetest)--# umount buildstage/mnt > } umount: buildstage/mnt: not currently mounted > } root(eetest)--# chroot buildstage sh -c 'umount /mnt' > } > } This does NOT look correct. I couldn't find any way to unmount the FS > } without repeating the chroot. > > umount /dev/wd2a? Doesn't work. It complains about not being able to find the mountpoint. > This stuff is kind of bogus. If you do a mount while chrooted, the > full path to the mount point isn't recorded, so mount only displays > the partial path. How are you supposed to find the mount point again? > > It would be nice if the path to the chroot directory was preserved so > that the full path could be recorded in the kernel, but this sort of > goes against the grain of the Unix philosophy. > > Even with the full path name in the mount table, you can still mess > things up by renaming one of the intermediate directories ... Yeah. I don't really know a good way of handling it - I just thought I'd note that it is bogus so somebody else could think about it, too :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jan 15 05:49:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15820 for freebsd-fs-outgoing; Fri, 15 Jan 1999 05:49:57 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA15815 for ; Fri, 15 Jan 1999 05:49:54 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id IAA25489; Fri, 15 Jan 1999 08:48:20 -0500 (EST) Date: Fri, 15 Jan 1999 08:48:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Don Lewis cc: Eivind Eklund , fs@FreeBSD.ORG Subject: Re: Mount bogosity In-Reply-To: <199901150227.SAA27492@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Jan 1999, Don Lewis wrote: > This stuff is kind of bogus. If you do a mount while chrooted, the > full path to the mount point isn't recorded, so mount only displays > the partial path. How are you supposed to find the mount point again? > > It would be nice if the path to the chroot directory was preserved so > that the full path could be recorded in the kernel, but this sort of > goes against the grain of the Unix philosophy. > > Even with the full path name in the mount table, you can still mess > things up by renaming one of the intermediate directories ... Having a 'full path name' for an arbitrary file at a useful time (prior or after its vnode lookup) would be great for a number of applications (well, kernel features :) that need to report to the user. This includes auditing support, where having a name guaranteed unique at the time where it is used. Also useful, but possibly more prone to pain, would be a vnode->name facility. Posix.1e auditing references filenames in the audit records, hence my interest at this point. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jan 15 14:24:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23615 for freebsd-fs-outgoing; Fri, 15 Jan 1999 14:24:17 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23610 for ; Fri, 15 Jan 1999 14:24:15 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA08893; Fri, 15 Jan 1999 15:24:13 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd008576; Fri Jan 15 15:24:00 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA13705; Fri, 15 Jan 1999 15:23:37 -0700 (MST) From: Terry Lambert Message-Id: <199901152223.PAA13705@usr04.primenet.com> Subject: Re: Mount bogosity To: robert+freebsd@cyrus.watson.org Date: Fri, 15 Jan 1999 22:23:35 +0000 (GMT) Cc: Don.Lewis@tsc.tdk.com, eivind@yes.no, fs@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jan 15, 99 08:48:19 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Having a 'full path name' for an arbitrary file at a useful time (prior or > after its vnode lookup) would be great for a number of applications > (well, kernel features :) that need to report to the user. This includes > auditing support, where having a name guaranteed unique at the time where > it is used. Also useful, but possibly more prone to pain, would be a > vnode->name facility. > > Posix.1e auditing references filenames in the audit records, hence my > interest at this point. You have to change the way hard links work, and allow proxy vnodes in the kernel as real data structures to allow this. Effectively, a hard link becomes an immediate file, and maintains a linked list of references to the non-hard-link inodes. This is pretty trivially handled by stacking, if stacking works in your kernel (e.g., you have my kernel, or you have BSDI's kernel). Without stacking, it looks like a job for one of Matt Dillon's VM object aliases, but stacking is probably a better way to handle it. The point of the alias is to allow a struct file reference to a vnode to be used to identify that vnode's immediate parent. This works because the vnode in core is a pointer to the real file vnode (i.e., exactly a stacked reference), but is itself a link vonde, and therefore is capable of rememebring the lookup parent inode_t and dev_t, instead of merely being a reference directly to the real vnode's inode_t and dev_t. The end result is that you have a backlink to the parent directory, and since directories implicitly have backlinks, the missing piece is files, and traversal is to root. Given the fact that forward traversal path is always relative to a directory in the first place (as a required argument to VOP_LOOKUP), you don't even have to change the on disk structure; you can, in fact, rememebr parent paths this way on any FS for which hard directory links are not allowed. For hard directory link supporting FS's (there used to be no "rename" system call, so a rename was effected via a non-atomic link, adjust "..", unlink), you would have to have an on disk reference structure to maintain the real parent pointer, since a hard link could make it N-1 deep (for N hops to root from the current directory). Pretty trivial, actually. I implemented this for NWFS in 1993 or so, back when I was at USL (Novell/USG). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jan 15 14:30:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24619 for freebsd-fs-outgoing; Fri, 15 Jan 1999 14:30:42 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24600; Fri, 15 Jan 1999 14:30:26 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA00305; Fri, 15 Jan 1999 15:30:18 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd029756; Fri Jan 15 15:29:53 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA14068; Fri, 15 Jan 1999 15:29:35 -0700 (MST) From: Terry Lambert Message-Id: <199901152229.PAA14068@usr04.primenet.com> Subject: Re: Mount bogosity To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Fri, 15 Jan 1999 22:29:35 +0000 (GMT) Cc: Don.Lewis@tsc.tdk.com, fs@FreeBSD.ORG In-Reply-To: <19990115052007.B362@bitbox.follo.net> from "Eivind Eklund" at Jan 15, 99 05:20:08 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Even with the full path name in the mount table, you can still mess > > things up by renaming one of the intermediate directories ... > > Yeah. I don't really know a good way of handling it - I just thought I'd > note that it is bogus so somebody else could think about it, too :-) Har. It's trivial. All you have to do is set curproc->p_fd->fd_rdir to the real root directory, instead of "NULL" when you create the first process, and then get rid of the "NULL implies root" code in the lookup code. The fd_rdir value is inherited on fork, and only set on chroot, so this is a trivial change. I've been after this (among other small changes) for years. It incidently solves your problem, since it removes the distinction for vnode covering in the chroot vs. non-chroot case. If you dig in the -current list archives, you'll find a set of patches that does this. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jan 16 08:10:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25704 for freebsd-fs-outgoing; Sat, 16 Jan 1999 08:10:20 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from prefetch-atm.san.rr.com (ns1.san.rr.com [204.210.0.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25699 for ; Sat, 16 Jan 1999 08:10:18 -0800 (PST) (envelope-from mlx@san.rr.com) Received: from newt (dt080n7e.san.rr.com [204.210.22.126]) by prefetch-atm.san.rr.com (8.8.7/8.8.8) with ESMTP id IAA27931 for ; Sat, 16 Jan 1999 08:10:15 -0800 (PST) Message-Id: <199901161610.IAA27931@prefetch-atm.san.rr.com> Reply-To: From: "Steve Biskis" To: Subject: Help: Too many open files !!! Date: Sat, 16 Jan 1999 08:10:30 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello All, Having a regular problem on my 2.2.5/6 file server. I should mention that it supports a fair amount of samba clients (10-20) on average. (1.9.18p10) First, a little background: I obtained my kernel in compiled form (as I couldn't get the patch to work) for DPT SCSI support. Therefore, I don't know all the details of its config. Despite the fact that I've never caught this host running more than about 70 processes, I was hitting a "process table full" error. I did a little poking about and discovered multiple smbd's for the same host/share. Now, many of our Samba clients are Win95 wireless units that can experience some serious network outages. So I figured maybe my network was pushing Samba a bit beyond its limits. I wrote a daemon to kill "orphaned" Samba daemons and voila, this error seems to have ceased. I've researched enough to know that MAXUSERS determines the proc table size and based on where I was running out of processes, I figure it can't be more than 4 (84 processes). Now, onto the current problem: /kernel: file: table is full Jan 15 10:28:11 rio last message repeated 7 times Jan 15 10:31:51 rio syslogd: /dev/console: Too many open files in system: Too many open files in system Jan 15 10:31:51 rio syslogd: /var/run/utmp: Too many open files in system Jan 15 10:31:51 rio syslogd: /var/run/utmp: Too many open files in system Jan 15 10:31:51 rio /kernel: file: table is full Jan 15 10:31:51 rio last message repeated 3 times Questions: 1a> Is this table some how also tied to MAXUSERS ? 1b> If so, how ? 1c> If not, then how is the file table size set. 2> Is there a utility or a resource that I can access to write a utility to see how many files are open and maybe even the processes that have them open ? I've already installed FreeBSD 2.2.8 on my local machine and could build a new kernel. This problem exists on a heavily used production machine located out of town and I want to be real sure of what I'm doing before I F_CK with it. All help will be greatly appreciated. Steve B. mlx@san.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message