From owner-freebsd-fs Tue May 2 13: 4:55 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (ewok.creative.net.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id 9801F37B813 for ; Tue, 2 May 2000 13:04:47 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 71844 invoked by uid 1008); 2 May 2000 20:04:32 -0000 Date: Wed, 3 May 2000 04:04:32 +0800 From: Adrian Chadd To: freebsd-fs@freebsd.org Subject: A proposal : IFS Message-ID: <20000503040431.B53701@ewok.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've had a modification to FFS called IFS (inode filesystem) in the works for a while, and I think its time for people to look at it. In a nutshell, it removes the directory namespace from FFS and presents a flat inode numbered namespace to applications. It was originally written for squid and inn type applications, but a few people have suggested other applications such as CODA/AFS stores/caches, and temp filesystems. The latest coderun is about 3 weeks old, and I haven't had time lately to keep it up to date with -current. However right now I'm after some comments. The only things this code is lacking is support for NFS cookies, and softupdates. I don't think either are very important right now, but if someone wants to prove me wrong, go ahead. :-) The code is located at : http://www.freebsd.org/~adrian/ifs/ Enjoy :) Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 2 19:21:13 2000 Delivered-To: freebsd-fs@freebsd.org Received: from linux.ssc.nsu.ru (linux.ssc.nsu.ru [193.124.219.91]) by hub.freebsd.org (Postfix) with SMTP id 5DFEF37BD25 for ; Tue, 2 May 2000 19:20:56 -0700 (PDT) (envelope-from danfe@ssc.nsu.ru) Received: (qmail 15711 invoked from network); 3 May 2000 02:20:48 -0000 Received: from inet.ssc.nsu.ru (62.76.110.12) by hub.freebsd.org with SMTP; 3 May 2000 02:20:48 -0000 Received: from localhost (danfe@localhost) by inet.ssc.nsu.ru (8.9.3/8.9.3) with ESMTP id JAA27557; Wed, 3 May 2000 09:20:21 +0700 Date: Wed, 3 May 2000 09:20:21 +0700 (NOVST) From: "Alexey N. Dokuchaev" To: freebsd-fs@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Which is the best filesystem to share data between fBSD and nBSD? 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 Hello! I plan to install three flawors of BSD: Free, Net, and possibly Open. I'm thinking of what is the best way of sharing data between them? If their FFS filesystems has the same layout, so I don't really have to care about it, simply mounting the slices, or there are certain differences, and I need to specify some mount options, or even use another FS, like ext2fs, or even VFAT [sic]. Please cc me since I am the member of the list, and sorry for crossposting. Cheers, /* Alexey N. Dokuchaev, more commonly | */ /* known as DAN Fe | mailto:danfe@inet.ssc.nsu.ru */ /* | ICQ UIN: 38934845 */ /* Novosibirsk State University | http://inet.ssc.nsu.ru/~danfe/ */ /* Scientific Study Center Computer Lab | */ [Team Assembler] [Team BSD] [Team DooM] [Team Quake] -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d-@ s+: a--- C++(+++) UBL++++$ P++>$ L+ E-- W++ N++ o? K? w-- O- M V- PS PE Y+ PGP+ t+ 5+ X+ R- !tv b++ DI+ D+++ G++ e h !r !y+ ------END GEEK CODE BLOCK------ Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? Microsoft: What are we going to rip off today and claim as our own? Microsoft: Where do you want to be taken today? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 1:25:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id 9336937B897 for ; Wed, 3 May 2000 01:25:33 -0700 (PDT) (envelope-from ezk@shekel.mcl.cs.columbia.edu) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA15410 for ; Wed, 3 May 2000 04:25:24 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id EAA21516; Wed, 3 May 2000 04:25:23 -0400 (EDT) Date: Wed, 3 May 2000 04:25:23 -0400 (EDT) Message-Id: <200005030825.EAA21516@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: freebsd-fs@freebsd.org Subject: announcing stackable file system templates and code generator Cc: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It is my pleasure to announce fistgen-0.0.1, the first release of the FiST code generator, used to create stackable file systems out of templates and a high-level language. This package comes with stackable file system templates for Linux, Solaris, and FreeBSD. It also contains several sample file systems built using the FiST language: an encryption file system, a compression file system, and more --- all of which are written as portable stackable file systems. For more information, software, and papers, see the FiST home page: http://www.cs.columbia.edu/~ezk/research/fist/ Happy stacking. Erez Zadok. --- Columbia University Department of Computer Science. EMail: ezk@cs.columbia.edu Web: http://www.cs.columbia.edu/~ezk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 3:33:50 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 868DF37B981; Wed, 3 May 2000 03:33:28 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12mwT0-000Iar-00; Wed, 03 May 2000 17:33:18 +0700 Date: Wed, 3 May 2000 17:33:18 +0700 (ALMST) From: Boris Popov To: Adrian Chadd Cc: freebsd-fs@freebsd.org Subject: Re: A proposal : IFS In-Reply-To: <20000503040431.B53701@ewok.creative.net.au> 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 Wed, 3 May 2000, Adrian Chadd wrote: > I've had a modification to FFS called IFS (inode filesystem) in the works > for a while, and I think its time for people to look at it. In a nutshell, > it removes the directory namespace from FFS and presents a flat inode No, it just provides another namespace and eliminates the need of directory metadata. > numbered namespace to applications. It was originally written for > squid and inn type applications, but a few people have suggested other > applications such as CODA/AFS stores/caches, and temp filesystems. As I can see, the primary goal of IFS is to reduce cost of inode lookup operation. And no doubt the best method is to expose inode numbers directly to application. However it is not clear to me how applications will interact with IFS and working example (patches for squid) would be very useful. Some performance benchmarks are also appreciated. > The only things this code is lacking is support for NFS cookies, and > softupdates. I don't think either are very important right now, but I'm doubt that someone will need to export IFS via NFS. And softupdates are not important too in this case. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 3:55: 9 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (ewok.creative.net.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id C248F37BC5A for ; Wed, 3 May 2000 03:55:03 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 77684 invoked by uid 1008); 3 May 2000 10:54:58 -0000 Date: Wed, 3 May 2000 18:54:58 +0800 From: Adrian Chadd To: freebsd-fs@freebsd.org Subject: Re: A proposal : IFS Message-ID: <20000503185457.C53701@ewok.creative.net.au> References: <20000503040431.B53701@ewok.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Boris Popov on Wed, May 03, 2000 at 05:33:18PM +0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 03, 2000, Boris Popov wrote: > > numbered namespace to applications. It was originally written for > > squid and inn type applications, but a few people have suggested other > > applications such as CODA/AFS stores/caches, and temp filesystems. > > As I can see, the primary goal of IFS is to reduce cost of inode > lookup operation. And no doubt the best method is to expose inode numbers > directly to application. > > However it is not clear to me how applications will interact with > IFS and working example (patches for squid) would be very useful. Some > performance benchmarks are also appreciated. After my current patchset for squid I will work on a quick patchset for IFS. It shouldn't be that hard to implement. An application which keeps an internal database of objects->filenames would simply continue to do so, but the filename is simply the inode number. WHen creating a file, it opens 'newfile' for create/write, which creates a new file. It then stat()s the fd to get the inode number, and records that. In squid case, it eliminates the need for keeping a bitmap of used file entries, since the FS does this anyway. > > The only things this code is lacking is support for NFS cookies, and > > softupdates. I don't think either are very important right now, but > > I'm doubt that someone will need to export IFS via NFS. And > softupdates are not important too in this case. Thats what I thought. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 5:44:43 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (Postfix) with ESMTP id AAB7C37B8D3; Wed, 3 May 2000 05:44:38 -0700 (PDT) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.9.3/8.9.3) id OAA47449; Wed, 3 May 2000 14:45:30 +0200 (CEST) (envelope-from bg) To: Adrian Chadd Cc: freebsd-fs@FreeBSD.ORG Subject: Re: A proposal : IFS References: <20000503040431.B53701@ewok.creative.net.au> <20000503185457.C53701@ewok.creative.net.au> From: Bjoern Groenvall Date: 03 May 2000 14:45:30 +0200 In-Reply-To: Adrian Chadd's message of Wed, 3 May 2000 18:54:58 +0800 Message-ID: Lines: 23 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Adrian Chadd writes: > An application which keeps an internal database of objects->filenames > would simply continue to do so, but the filename is simply the inode number. > WHen creating a file, it opens 'newfile' for create/write, which creates > a new file. It then stat()s the fd to get the inode number, and records > that. In squid case, it eliminates the need for keeping a bitmap of > used file entries, since the FS does this anyway. What about using fhopen and getfh instead? That way you won't have to write a new filesystem. You will have to use file handles rather than inode numbers though. Cheers, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 7: 1: 5 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (ewok.creative.net.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id EB07937B76C for ; Wed, 3 May 2000 07:01:00 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 78681 invoked by uid 1008); 3 May 2000 14:00:55 -0000 Date: Wed, 3 May 2000 22:00:55 +0800 From: Adrian Chadd To: Bjoern Groenvall Cc: freebsd-fs@FreeBSD.ORG Subject: Re: A proposal : IFS Message-ID: <20000503220053.D53701@ewok.creative.net.au> References: <20000503040431.B53701@ewok.creative.net.au> <20000503185457.C53701@ewok.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Bjoern Groenvall on Wed, May 03, 2000 at 02:45:30PM +0200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 03, 2000, Bjoern Groenvall wrote: > Adrian Chadd writes: > > > An application which keeps an internal database of objects->filenames > > would simply continue to do so, but the filename is simply the inode number. > > WHen creating a file, it opens 'newfile' for create/write, which creates > > a new file. It then stat()s the fd to get the inode number, and records > > that. In squid case, it eliminates the need for keeping a bitmap of > > used file entries, since the FS does this anyway. > > What about using fhopen and getfh instead? That way you won't have to > write a new filesystem. You will have to use file handles rather than > inode numbers though. You still need to do a directory lookup in getfh(), and IFS filesystems take far less time to fsck. There was once a hack floating about for Linux and FreeBSD which patched VOP_LOOKUP() to take a special filename and treat it as an inode number- it was designed for INN where once you opened a news article, you'd keep the inode number in memory and use that. But you still had the ondisk directory metadata and unlink()s couldn't be done with the inode number magic sequence, which is why I took it a step further and wrote IFS. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 7:12:39 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 07B2C37B7C5; Wed, 3 May 2000 07:12:36 -0700 (PDT) (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.9.3/8.9.3) with SMTP id KAA28823; Wed, 3 May 2000 10:12:34 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Wed, 3 May 2000 10:12:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Adrian Chadd Cc: Bjoern Groenvall , freebsd-fs@freebsd.org Subject: Re: A proposal : IFS In-Reply-To: <20000503220053.D53701@ewok.creative.net.au> 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 Wed, 3 May 2000, Adrian Chadd wrote: > On Wed, May 03, 2000, Bjoern Groenvall wrote: > > Adrian Chadd writes: > > > > > An application which keeps an internal database of objects->filenames > > > would simply continue to do so, but the filename is simply the inode number. > > > WHen creating a file, it opens 'newfile' for create/write, which creates > > > a new file. It then stat()s the fd to get the inode number, and records > > > that. In squid case, it eliminates the need for keeping a bitmap of > > > used file entries, since the FS does this anyway. > > > > What about using fhopen and getfh instead? That way you won't have to > > write a new filesystem. You will have to use file handles rather than > > inode numbers though. > > You still need to do a directory lookup in getfh(), and IFS filesystems > take far less time to fsck. There was once a hack floating about for > Linux and FreeBSD which patched VOP_LOOKUP() to take a special filename > and treat it as an inode number- it was designed for INN where once > you opened a news article, you'd keep the inode number in memory and use that. > But you still had the ondisk directory metadata and unlink()s couldn't > be done with the inode number magic sequence, which is why I took it > a step further and wrote IFS. Coda (and presumably early AFS code) made use of an ITC open to open a file by-inode to avoid the namespace costs, as it provides its own namespace. My recollection also is that the fh* calls don't give you a way to allocate new file handles, only convert an existing name into a file handle. So you still pay the cost of file creation in the namespace. And you can't assume that file handles will remain consistent across a backup/restore cycle, whereas if the unique (yet efficient) names are part of the exposed application namespace, you can. This also answers the question about what access limitations to put on the fh* calls in alternative security environments (capabilities, MAC, tokens, et al) as it would no longer be a call to access files out of band of the namespace, but instead be controlled by permissions on the fs. Speaking of which -- it strikes me that it would be nice to have an inode allocated (nominally) to the root directory, and vop_access() and vop_getattr() would return properties of that inode (specifically, permissions/ownership/file flags/etc) and apply those permission limitations on create and delete operations. This way when the file system was created, you could chown/chmod/whatever the root of the FS to set effective rights for use of the FS. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 7:33: 5 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (Postfix) with ESMTP id C0BC837BBDB; Wed, 3 May 2000 07:32:50 -0700 (PDT) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.9.3/8.9.3) id QAA47551; Wed, 3 May 2000 16:33:43 +0200 (CEST) (envelope-from bg) To: Adrian Chadd Cc: Bjoern Groenvall , freebsd-fs@freebsd.org Subject: Re: A proposal : IFS References: <20000503040431.B53701@ewok.creative.net.au> <20000503185457.C53701@ewok.creative.net.au> <20000503220053.D53701@ewok.creative.net.au> From: Bjoern Groenvall Date: 03 May 2000 16:33:42 +0200 In-Reply-To: Adrian Chadd's message of Wed, 3 May 2000 22:00:55 +0800 Message-ID: Lines: 42 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Adrian Chadd writes: > On Wed, May 03, 2000, Bjoern Groenvall wrote: > > Adrian Chadd writes: > > > > > An application which keeps an internal database of objects->filenames > > > would simply continue to do so, but the filename is simply the inode number. > > > WHen creating a file, it opens 'newfile' for create/write, which creates > > > a new file. It then stat()s the fd to get the inode number, and records > > > that. In squid case, it eliminates the need for keeping a bitmap of > > > used file entries, since the FS does this anyway. > > > > What about using fhopen and getfh instead? That way you won't have to > > write a new filesystem. You will have to use file handles rather than > > inode numbers though. > > You still need to do a directory lookup in getfh(), and IFS > filesystems take far less time to fsck. "An application which keeps an internal database of objects->filenames would simply continue to do so, but the filename is simply the inode number." So you don't have to do any directory lookups (except when you create your pool of objects). > But you still had the ondisk directory metadata and unlink()s couldn't > be done with the inode number magic sequence, which is why I took it > a step further and wrote IFS. You don't have to perform any unlinks when an object is deleted, just ftruncate the thing and return it to the free pool. /Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 3 7:46:38 2000 Delivered-To: freebsd-fs@freebsd.org Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (Postfix) with ESMTP id 1C51937BB36; Wed, 3 May 2000 07:46:24 -0700 (PDT) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.9.3/8.9.3) id QAA47583; Wed, 3 May 2000 16:47:14 +0200 (CEST) (envelope-from bg) To: Robert Watson Cc: Adrian Chadd , Bjoern Groenvall , freebsd-fs@freebsd.org Subject: Re: A proposal : IFS References: From: Bjoern Groenvall Date: 03 May 2000 16:47:14 +0200 In-Reply-To: Robert Watson's message of Wed, 3 May 2000 10:12:34 -0400 (EDT) Message-ID: Lines: 20 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > My recollection also is that the fh* calls don't give you a way to > allocate new file handles, only convert an existing name into a file > handle. You are right about that, ITC had an icreat system call and you will have to add a corresponding file system specific VOP_FHCREATE to be able to add anonymous files. It will also be necessary to teach programs e.g fsck about these anonymous files. /Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri May 5 15:38:23 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail1.bna.bellsouth.net (mail1.bna.bellsouth.net [205.152.150.13]) by hub.freebsd.org (Postfix) with ESMTP id 7B37037BD04 for ; Fri, 5 May 2000 15:38:20 -0700 (PDT) (envelope-from jim@siteplus.net) Received: from discover.siteplus.net (host-209-215-9-142.cha.bellsouth.net [209.215.9.142]) by mail1.bna.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id SAA06069 for ; Fri, 5 May 2000 18:38:20 -0400 (EDT) Date: Fri, 5 May 2000 18:38:27 -0400 (EDT) From: Jim Weeks To: freebsd-fs@freebsd.org Subject: File system lost 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 I have a problem with a ST39140W Seagate SCSI drive. I have two of these attached to a BT-958 Mylex adapter on a machine running 3.4-stable and after a power outage one of them wouldn't come back up. The only way I can get the machine to boot into multi user mode is to comment out the entry for "/dev/da1s1e" in /etc/fstab. This is a dedicated drive with only one slice mounted as /bak. This was the default slice configuration used by /stand/sysinstall during the initial 3.2-stable snapshot installation about a year ago. I have been rebuilding the system from source on a regular basis ever since, and with no problems. Since the power glitch I can talk to the drive via camcontroll. I did a fsck /dev/da1 and am now able to "mount /dev/da1 /bak" with no problem. I can't however "mount /dev/da1s1e /bak" I get a device not configured error. A copy of dmesg shows that the drive is recognized which in this case is da1, but mount spits out the error not configured. kernel: da0 at bt0 bus 0 target 0 lun 0 kernel: da0: Fixed Direct Access SCSI-2 device kernel: da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled kernel: da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) kernel: da1 at bt0 bus 0 target 1 lun 0 kernel: da1: Fixed Direct Access SCSI-2 device kernel: da1: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled kernel: da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) /stand/sysinstall also sees the drive, but when I try to configure through the partition manager there is no data listed in the configuration screen. I have also remade the device through MAKEDEV. I know the drive is working because when mounted as "/dev/da1 /bak" I am able to do backup operations with now problem. Another strange point is that /stand/sysinstall sees the drive as da1 but when you try to look at the slice information nothing is there. My question is what about the power glitch has corrupted the mounting of /dev/da1s1e? Any ideas would be appreciated, Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat May 6 8:42:11 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by hub.freebsd.org (Postfix) with ESMTP id 72BDF37B56D for ; Sat, 6 May 2000 08:42:09 -0700 (PDT) (envelope-from bfischer@Techfak.uni-bielefeld.de) Received: from frolic.no-support.loc (ppp36-128.hrz.uni-bielefeld.de) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FU500I5EA9ZAN@mail.uni-bielefeld.de> for freebsd-fs@freebsd.org; Sat, 6 May 2000 17:42:03 +0200 (MET DST) Received: (from bjoern@localhost) by frolic.no-support.loc (8.9.3/8.9.3) id RAA00666 for freebsd-fs@freebsd.org; Sat, 06 May 2000 17:40:54 +0200 (CEST envelope-from bjoern) Date: Sat, 06 May 2000 17:40:54 +0200 From: Bjoern Fischer Subject: NFSv4 To: freebsd-fs@freebsd.org Message-id: <20000506174054.A545@frolic.no-support.loc> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Is there an (experimental) NFSv4 implementation for FreeBSD out there? Or does anyone plan to implement NFSv4 for FreeBSD? What are the biggest show stoppers for a straight forward implementation of NFSv4 on FreeBSD? RPCSEC_GSS? Locking? Bj=F6rn --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message