From owner-freebsd-fs Sun Apr 6 11:16:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA24400 for fs-outgoing; Sun, 6 Apr 1997 11:16:11 -0700 (PDT) Received: from nexis.net (customer-1.ican.net [198.133.36.101]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA24393; Sun, 6 Apr 1997 11:16:08 -0700 (PDT) Received: from localhost (james@localhost) by nexis.net (8.8.5/8.8.5) with SMTP id OAA18502; Sun, 6 Apr 1997 14:15:17 -0400 (EDT) Date: Sun, 6 Apr 1997 14:15:16 -0400 (EDT) From: James FitzGibbon To: freebsd-questions@freebsd.org cc: freebsd-fs@freebsd.org Subject: Quotas over NFS with 2.2.x ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been successfully using quotas over NFS with a 2.2.1R server and a 3.0-current client. In trying to set up a third 2.2.1R system as a client, I receive the message nfs: -o userquota option not supported when trying to mount an nfs filesystem with quotas. Is this normal ? Are quotas over NFS only supported in 3.0-current ? I can't find specific mention of it being something new in the SNAP relnotes.txt file. Any help would be appreciated. -- j. From owner-freebsd-fs Mon Apr 7 13:31:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA09230 for fs-outgoing; Mon, 7 Apr 1997 13:31:46 -0700 (PDT) Received: from nexis.net (customer-1.ican.net [198.133.36.101]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09225; Mon, 7 Apr 1997 13:31:36 -0700 (PDT) Received: from localhost (james@localhost) by nexis.net (8.8.5/8.8.5) with SMTP id QAA23824; Mon, 7 Apr 1997 16:30:05 -0400 (EDT) Date: Mon, 7 Apr 1997 16:30:05 -0400 (EDT) From: James FitzGibbon To: freebsd-questions@freebsd.org cc: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Can you mount NFS w/quotas from a 2.2.x client ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Apologies for posting this multiple times, but nobody responded the first time, and my project is at a bit of standstill without confirmation of this question) Can you mount an NFS file system with user quotas using a 2.2.x client ? I have been able to with a 3.0-current client, but using a similarly configured 2.2.x client, when running mount_nfs -o userquota server:/usr/exports/home /usr/home I receive the response nfs: -o userquota option not supported. I have tried this with a newly installed 2.2.1R system, recompiled with the GENERIC kernel, adding just the 'options QUOTA' line, without success. If it can't be done, I really need to know. Any help is appreciated. -- j. From owner-freebsd-fs Mon Apr 7 19:06:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09048 for fs-outgoing; Mon, 7 Apr 1997 19:06:13 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA09022 for ; Mon, 7 Apr 1997 19:05:36 -0700 (PDT) Received: from dash.isi.edu by darkstar.isi.edu (5.65c/5.61+local-24) id ; Mon, 7 Apr 1997 19:05:29 -0700 Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (8.8.5/8.8.4) with ESMTP id TAA10123; Mon, 7 Apr 1997 19:05:22 -0700 Message-Id: <199704080205.TAA10123@dash.isi.edu> X-Url: To: Michael Hancock Cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer In-Reply-To: Date: Mon, 07 Apr 1997 19:05:19 -0700 From: John Heidemann Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A long time ago, on Wed, 13 Nov 1996 23:49:43 +0900, Michael Hancock wrote: >Subject: NFS bypass op and the utok layer > >Were these even considered when the FreeBSD vnode stacking implementation >was done? > >The NFS default op is the one returning the NOT SUPPORTED error. A bypass >op would allow you to stack on top of an out-of-kernel layer which could >then be layered on a utok layer to cross the boundary again. > >I guess the fs memory allocation architecture is not compatible with this. > >Debugging in userland would sure be cool, when you're satisfied take away >the transport layers and you're back in the kernel. >... >Mike Hancock NFS bypass and user-level debugging were considered in the context of the initial stackable filing implementation under SunOS. See for a description. The scenario you describe (moving layers in and out of the kernel) was in regular use from about 1990-1995 at UCLA. Unfortunately, the FreeBSD port of stacking included only the in-kernel portions. At the time the NFS code required Sun's XDR implementation. There many possible design trade-offs in the approach. We had NFS as our kernel-to-user transport layer and a custom user-to-kernel transport layer. The disadvantage with our approach is that NFS munges all the operations, making them stateless and in general giving you a different operation mix at user-level than in the kernel. The big advantage is that the NFS client-side of the user-to-kernel transport provides caching and deals with all of the memory allocation problems you allude to. Other design points (such as having custom transport layers in both directions) have other trade-offs, of course. I actually re-implemented the NFS-bypass code after the FreeBSD port, making it freely available and more flexible but slower. (Slower XDR code than Sun's---hard to believe, I know, but think of it as a research prototype. The speed could be much improved with different design decisions.) A port of this later work to FreeBSD and a FreeBSD-based user-level file-system development envrionment would be kind of cool, if anyone's interested. -John ``not reading this mailing list often enough'' Heidemann From owner-freebsd-fs Mon Apr 7 22:22:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA17473 for fs-outgoing; Mon, 7 Apr 1997 22:22:55 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA17468 for ; Mon, 7 Apr 1997 22:22:52 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id FAA08636; Tue, 8 Apr 1997 05:22:39 GMT Date: Tue, 8 Apr 1997 14:22:39 +0900 (JST) From: Michael Hancock To: John Heidemann cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer In-Reply-To: <199704080205.TAA10123@dash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 7 Apr 1997, John Heidemann wrote: > Unfortunately, the FreeBSD port of stacking included only the > in-kernel portions. At the time the NFS code required Sun's XDR > implementation. > > There many possible design trade-offs in the approach. We had NFS as > our kernel-to-user transport layer and a custom user-to-kernel > transport layer. The disadvantage with our approach is that NFS > munges all the operations, making them stateless and in general giving > you a different operation mix at user-level than in the kernel. The > big advantage is that the NFS client-side of the user-to-kernel > transport provides caching and deals with all of the memory allocation > problems you allude to. Other design points (such as having custom > transport layers in both directions) have other trade-offs, of course. > > I actually re-implemented the NFS-bypass code after the FreeBSD port, > making it freely available and more flexible but slower. (Slower XDR > code than Sun's---hard to believe, I know, but think of it as a > research prototype. The speed could be much improved with different > design decisions.) A port of this later work to FreeBSD and a > FreeBSD-based user-level file-system development envrionment would be > kind of cool, if anyone's interested. > > -John ``not reading this mailing list often enough'' Heidemann I'd like to have a look. Are you volunteering or are you looking for volunteers? Regards, Mike From owner-freebsd-fs Tue Apr 8 03:31:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA29757 for fs-outgoing; Tue, 8 Apr 1997 03:31:42 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA29751; Tue, 8 Apr 1997 03:31:36 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id KAA10828; Tue, 8 Apr 1997 10:30:00 GMT Date: Tue, 8 Apr 1997 19:29:59 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: DISCUSS: vnode references as open instances In-Reply-To: <199704032343.QAA17773@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry, I think it will be hard to get support to change ufs this drastically at this time since Kirk is working on soft updates. And there is also quite of a bit of community interest in having a trusted stable fs implementation to fall back on. How you considered what Netcom? did with tfs? It seems they use their own vnode allocation scheme. I vaguely remember seeing changes made to allow this. If you wanted to make even more radical changes Heidemann's papers discuss using a compatibility layer between the consumer of the old interface and a new framework. This would give you more leeway for big changes like reimplementing ufs without the outdated cylinder group layout stuff, etc. I know it's easier said then done and there might be some restrictions, but I think you would get more support with this strategy. Regards, Mike Hancock On Thu, 3 Apr 1997, Terry Lambert wrote: > I am looking for discussion, pro and con. > > ----------------------------------------------------------------------------- > > I believe that vnode references should be treated as counting > semaphores. > > Currently, reference holders are net required to count references > in all cases. > > The purpose of this change would be to significantly clean up > the vnode reference interactions to provide a meaningful > seperation between vnode maintenance and vnode reclamation, > with the eventual intention of removing the need for vclean() > and the duplication of code in each per FS VOP_LOCK implementation. > > > This change would affect the directory name lookup cache code > (for which a vnode reference in a cache would be very much the > same as an open instance for a vnode reference by a system open > file table reference), as well as several other subsystems. > > > Though vnodes are currently globally accounted, I beleive that > there should be a per FS interface, initially to the global > accounting interface, for freeing vnodes in an FS specific > manner. > > The eventual intent of this change is to allow per-FS management > of vnodes as part of the FS's [*,i]node pool, and to therefore > relieve the need for global vnode pool management, and thus global > recovery of vnodes for reuse. > > > This would be similar in scope to the SVR4 vnode management scheme, > as described in "The Magic Garden Explained" and the _Bach_ book. > > > One large benefit of this technique would be to allow the recovery > of unreferenced vnodes from per FS "second chance" caches, like > the FFS "ihash" facility, and therfore the recovery of perfectly > valid memory pages that refere to a referenced per FS object. > > Currently, there is no recovery mechanism whereby the valid pages > can be re-referenced for use once the vnode had been disassociated > from the per-FS object, but not from the valid pages. > > When a reference which references these pages occurs, the data, > though in core, cannot be reclaimed, and must be reread from > disk. > > ----------------------------------------------------------------------------- > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 From owner-freebsd-fs Tue Apr 8 03:46:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02044 for fs-outgoing; Tue, 8 Apr 1997 03:46:50 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02034; Tue, 8 Apr 1997 03:46:46 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id KAA10918; Tue, 8 Apr 1997 10:46:38 GMT Date: Tue, 8 Apr 1997 19:46:38 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: DISCUSS: vnode references as open instances In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 8 Apr 1997, Michael Hancock wrote: > Terry, > > I think it will be hard to get support to change ufs this drastically at > this time since Kirk is working on soft updates. And there is also quite > of a bit of community interest in having a trusted stable fs > implementation to fall back on. > > How you considered what Netcom? did with tfs? It seems they use their own > vnode allocation scheme. I vaguely remember seeing changes made to allow > this. I just verified this. Grep for VT_TFS in /sys/kern. It's a special case hack, but maybe we can come up with a more general way of informing the kernel that we're doing our own vnode management. Regards, Mike From owner-freebsd-fs Tue Apr 8 04:28:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA03635 for fs-outgoing; Tue, 8 Apr 1997 04:28:57 -0700 (PDT) Received: from hemnet.com.au (scotty.hemnet.com.au [203.33.153.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA03627 for ; Tue, 8 Apr 1997 04:28:49 -0700 (PDT) Received: from wayne.hemnet.com.au (wayne.hemnet.com.au [203.33.153.42]) by hemnet.com.au (8.7.5/8.7.3) with SMTP id VAA00477 for ; Tue, 8 Apr 1997 21:29:41 GMT Message-Id: <3.0.32.19970408212953.006b2608@hemnet.com.au> X-Sender: wheming@hemnet.com.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 08 Apr 1997 21:29:54 +1000 To: freebsd-fs@freebsd.org From: Wayne Heming Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-fs Tue Apr 8 18:30:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA17385 for fs-outgoing; Tue, 8 Apr 1997 18:30:43 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA17367; Tue, 8 Apr 1997 18:30:40 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA15672; Wed, 9 Apr 1997 01:30:32 GMT Date: Wed, 9 Apr 1997 10:30:32 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: DISCUSS: vnode references as open instances In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 8 Apr 1997, Michael Hancock wrote: > > Though vnodes are currently globally accounted, I beleive that > > there should be a per FS interface, initially to the global > > accounting interface, for freeing vnodes in an FS specific > > manner. > > > > The eventual intent of this change is to allow per-FS management > > of vnodes as part of the FS's [*,i]node pool, and to therefore > > relieve the need for global vnode pool management, and thus global > > recovery of vnodes for reuse. > > > > One large benefit of this technique would be to allow the recovery > > of unreferenced vnodes from per FS "second chance" caches, like > > the FFS "ihash" facility, and therfore the recovery of perfectly > > valid memory pages that refere to a referenced per FS object. > > > > Currently, there is no recovery mechanism whereby the valid pages > > can be re-referenced for use once the vnode had been disassociated > > from the per-FS object, but not from the valid pages. > > > > When a reference which references these pages occurs, the data, > > though in core, cannot be reclaimed, and must be reread from > > disk. 1) Create a directory /sys/u2fs. 2) Build the necessary scaffolding, VT_U2FS, vop scripts, etc. and do the VT_TFS thing. 3) Submit updates to the /sys/u2fs directory in parcels as big as you want. 4) If your analysis is accurate, and you correctly design and implement the changes then most applications will show a significant performance improvement. 5) Get Matt Dillon, Joe Greco, and Karl to "beat the snot" out your new improved ufs and get them to make testimonials. 6) Then work on converting the VT_TFS, VT_U2FS special case the general case. Regards, Mike Hancock From owner-freebsd-fs Tue Apr 8 22:51:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA28023 for fs-outgoing; Tue, 8 Apr 1997 22:51:48 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA28018 for ; Tue, 8 Apr 1997 22:51:43 -0700 (PDT) Received: from dash.isi.edu (ppp29.isi.edu) by darkstar.isi.edu (5.65c/5.61+local-24) id ; Tue, 8 Apr 1997 22:51:40 -0700 Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (8.8.5/8.8.4) with ESMTP id WAA15867; Tue, 8 Apr 1997 22:51:35 -0700 Message-Id: <199704090551.WAA15867@dash.isi.edu> X-Url: To: Michael Hancock Cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer In-Reply-To: Date: Tue, 08 Apr 1997 22:51:34 -0700 From: John Heidemann Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 08 Apr 1997 14:22:39 +0900, Michael Hancock wrote: >On Mon, 7 Apr 1997, John Heidemann wrote: >> [a description of stacking in SunOS] >> ... >> I actually re-implemented the NFS-bypass code after the FreeBSD port, >> making it freely available and more flexible but slower. (Slower XDR >> code than Sun's---hard to believe, I know, but think of it as a >> research prototype. The speed could be much improved with different >> design decisions.) A port of this later work to FreeBSD and a >> FreeBSD-based user-level file-system development envrionment would be >> kind of cool, if anyone's interested. > >I'd like to have a look. Are you volunteering or are you looking for >volunteers? I'm interested in seeing stacking used, but if I took on the port it wouldn't get done for a long time. I'm happy to offer advice to interested hackers, and a copy of all of the freely available UCLA code. -John Heidemann From owner-freebsd-fs Tue Apr 8 22:58:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA28336 for fs-outgoing; Tue, 8 Apr 1997 22:58:49 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA28329 for ; Tue, 8 Apr 1997 22:58:44 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id FAA17123; Wed, 9 Apr 1997 05:58:35 GMT Date: Wed, 9 Apr 1997 14:58:35 +0900 (JST) From: Michael Hancock To: John Heidemann cc: fs@freebsd.org Subject: Re: NFS bypass op and the utok layer In-Reply-To: <199704090551.WAA15867@dash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 8 Apr 1997, John Heidemann wrote: > I'm interested in seeing stacking used, but if I took on the port it > wouldn't get done for a long time. I'm happy to offer advice to > interested hackers, and a copy of all of the freely available UCLA > code. > > -John Heidemann Can you make it available by anonymous ftp? Mike Hancock From owner-freebsd-fs Wed Apr 9 20:48:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA10800 for fs-outgoing; Wed, 9 Apr 1997 20:48:50 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA10793; Wed, 9 Apr 1997 20:48:45 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id UAA05131; Wed, 9 Apr 1997 20:48:41 -0700 (PDT) Date: Wed, 9 Apr 1997 20:48:41 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: James FitzGibbon cc: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Quotas over NFS with 2.2.x ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Apr 1997, James FitzGibbon wrote: > > I've been successfully using quotas over NFS with a 2.2.1R server and a > 3.0-current client. In trying to set up a third 2.2.1R system as a > client, I receive the message > > nfs: -o userquota option not supported > > when trying to mount an nfs filesystem with quotas. > > Is this normal ? Are quotas over NFS only supported in 3.0-current ? I > can't find specific mention of it being something new in the SNAP > relnotes.txt file. I think so. NFS quotas is an advanced topic, and lives with nfs locking in the 'not quite implemented' bin... Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major