From owner-freebsd-fs Sun Nov 7 20:21:13 1999 Delivered-To: freebsd-fs@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id EDDCC15146; Sun, 7 Nov 1999 20:21:07 -0800 (PST) (envelope-from jrs@enteract.com) Received: from shell-1.enteract.com (jrs@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id WAA39691; Sun, 7 Nov 1999 22:21:06 -0600 (CST) (envelope-from jrs@enteract.com) Date: Sun, 7 Nov 1999 22:21:06 -0600 (CST) From: John Sconiers To: freebsd-fs@freebsd.org, freebsd-questions@freebsd.org Subject: journaling fs--news-- 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'm assuming I'm not the first to see this: http://linuxpr.com/releases/627.html It appears to be GPL'd with certain exceptions however locaed at: http://devlinux.org/namesys/ They clearly state they'd like to see it ported to different operating systems. JRS PS sorry for the cross post To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Nov 7 20:33:45 1999 Delivered-To: freebsd-fs@freebsd.org Received: from filer4.isc.rit.edu (filer4.isc.rit.edu [129.21.3.73]) by hub.freebsd.org (Postfix) with ESMTP id CC8D81505B for ; Sun, 7 Nov 1999 20:33:42 -0800 (PST) (envelope-from jcptch@osfmail.isc.rit.edu) Received: from grace.isc.rit.edu ("port 4282"@[129.21.3.102]) by osfmail.isc.rit.edu (PMDF V5.2-32 #34621) with ESMTP id <0FKV000Q03CIJA@osfmail.isc.rit.edu> for freebsd-fs@freebsd.org; Sun, 7 Nov 1999 23:33:54 -0500 (EST) Received: by grace.isc.rit.edu (8.8.8/1.1.19.2/21Sep98-0910AM) id XAA0000027155; Sun, 07 Nov 1999 23:32:38 -0500 (EST) Date: Sun, 07 Nov 1999 23:32:38 -0500 From: Jon Parise Subject: Re: journaling fs--news-- In-reply-to: ; from jrs@enteract.com on Sun, Nov 07, 1999 at 10:21:06PM -0600 To: freebsd-fs@freebsd.org Mail-followup-to: freebsd-fs@freebsd.org Message-id: <19991107233238.A26884@osfmail.isc.rit.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i X-Operating-System: OSF1 V4.0 (alpha) References: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 07, 1999 at 10:21:06PM -0600, John Sconiers wrote: > It appears to be GPL'd with certain exceptions however locaed at: > > http://devlinux.org/namesys/ > > They clearly state they'd like to see it ported to different operating > systems. I work with Chris Mason, the programmer the worked on the majority of the journalling code. He expressed an interest in seeing the file system ported to additional platforms, but he doesn't plan on doing any of the porting himself. They've done a lot of good work on ReiserFS, and I'd like to see it ported to FreeBSD. Any takers? =) -- Jon Parise (parise@pobox.com) . Rochester Inst. of Technology http://www.pobox.com/~parise/ : Computer Science House Member To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Nov 8 7: 6:55 1999 Delivered-To: freebsd-fs@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id BC81B14CA9; Mon, 8 Nov 1999 07:06:50 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991107223921.30116@yana.lemis.com> Date: Sun, 7 Nov 1999 22:39:21 -0500 From: Greg Lehey To: "Justin T. Gibbs" , Kelly Yancey Cc: Bernd Walter , Mattias Pantzare , freebsd-fs@FreeBSD.ORG Subject: Re: feature list journalled fs Reply-To: Greg Lehey References: <199911042245.PAA05113@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199911042245.PAA05113@caspian.plutotech.com>; from Justin T. Gibbs on Thu, Nov 04, 1999 at 03:45:26PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 4 November 1999 at 15:45:26 -0700, Justin T. Gibbs wrote: >> On Thu, 4 Nov 1999, Greg Lehey wrote: >> >>> That's for writing. When throughput becomes the limit, the write >>> throughput of RAID-4 is limited to about 2 / n of the write throughput >>> of RAID-5. On reading (randomly), it's (n - 1) / n. >> >> I think that it has been significantly proven that RAID 4 is not very >> userful, and I regret bringing it up...sometimes the mind wonders :). > > It all depends on your application. If you are dealing with a data > set composed of large, fixed sized entries, RAID 3 or 4 (they are almost > identical) will always outperform RAID5. I assume you're talking about read access, and by "large" you mean "more than one stripe". Under these circumstances, I can believe that sometimes you'll see better performance when you have few requestors. My discussion applied to multiple requestors. I don't think you can generalize, though I'm prepared to listen to detailed arguments, and even more to benchmark results :-) Greg -- Finger grog@lemis.com for PGP public key 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 Mon Nov 8 7:18: 1 1999 Delivered-To: freebsd-fs@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 1E0F215213 for ; Mon, 8 Nov 1999 07:17:55 -0800 (PST) (envelope-from jrs@enteract.com) Received: from shell-1.enteract.com (jrs@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id JAA29618; Mon, 8 Nov 1999 09:17:54 -0600 (CST) (envelope-from jrs@enteract.com) Date: Mon, 8 Nov 1999 09:17:54 -0600 (CST) From: John Sconiers To: Jon Parise Cc: freebsd-fs@freebsd.org Subject: Re: journaling fs--news-- In-Reply-To: <19991107233238.A26884@osfmail.isc.rit.edu> 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 work with Chris Mason, the programmer the worked on the majority > of the journalling code. He expressed an interest in seeing the > file system ported to additional platforms, but he doesn't plan on > doing any of the porting himself. > They've done a lot of good work on ReiserFS, and I'd like to see it > ported to FreeBSD. Any takers? =) I am willing to help port it to freebsd. I can setup a central online repository(or mirror), mailing lists, as well as program and test if enough people are interested. JRS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 0:46:16 1999 Delivered-To: freebsd-fs@freebsd.org Received: from akat.civ.cvut.cz (akat.civ.cvut.cz [147.32.235.105]) by hub.freebsd.org (Postfix) with SMTP id 631F014EA7 for ; Tue, 9 Nov 1999 00:46:05 -0800 (PST) (envelope-from pechy@hp735.cvut.cz) Received: from localhost (pechy@localhost) by akat.civ.cvut.cz (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05498; Tue, 9 Nov 1999 09:45:55 +0100 Date: Tue, 9 Nov 1999 09:45:55 +0100 From: Jan Pechanec X-Sender: pechy@akat.civ.cvut.cz To: Mats Lofkvist Cc: freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-Reply-To: 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 6 Nov 1999, Mats Lofkvist wrote: >julian@whistle.com (Julian Elischer) writes: >> On Fri, 5 Nov 1999, Jan Pechanec wrote: >> > >> > BTW, don't you know why deadfs was written? No doc in FreeBSD. >> > From what I saw in the source code, operations just fail. >> > >> When youhave a vnode open, and for some reason the filesystem the vmode >> pints to disappears (e.g. the disk is removed, or the PC-CARD is removed, >> or many other posibilties), then you cannot track down all teh users fo >> that vnode very easily, so insteadm you 'fiddle' with it to make it >> reference the DEADFS (use VGONE) and when the users try use it again they >> will safely get an error, but at least the system will >> not core-dump when they access a non existant filesyste,/device. > >I guess deadfs is what makes the -f (force) flag to umount work >also, and that one is a truly great feature in FreeBSD missing in >many other unixen (e.g. solaris {and linux, I believe}). > >Having to track down all processes with open descriptors on e.g. >a nfs mount before being able to umount it is a real pain in the *, >most times I give up on it and reboot the machine instead. I am not so experienced with FreeBSD, but SGI IRIX has ``fuser'' command. This command can find all processes that has open files inside the mounted fs. You can easily write a script that kill them all. Jan. -- Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, Praha 6, 166 35, Czech Republic) www.civ.cvut.cz, pechy.civ.cvut.cz, tel: +420 2 24352969 (fax: 24310271) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 0:53:16 1999 Delivered-To: freebsd-fs@freebsd.org Received: from akat.civ.cvut.cz (akat.civ.cvut.cz [147.32.235.105]) by hub.freebsd.org (Postfix) with SMTP id 103F514FFF for ; Tue, 9 Nov 1999 00:53:11 -0800 (PST) (envelope-from pechy@hp735.cvut.cz) Received: from localhost (pechy@localhost) by akat.civ.cvut.cz (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05513 for ; Tue, 9 Nov 1999 09:53:07 +0100 Date: Tue, 9 Nov 1999 09:53:07 +0100 From: Jan Pechanec X-Sender: pechy@akat.civ.cvut.cz To: freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-Reply-To: <199911051914.OAA23367@shekel.mcl.cs.columbia.edu> 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 Fri, 5 Nov 1999, Erez Zadok wrote: >In message , Robert Watson writes: >[...] >> Because wrapfs doesn't work in 3.3-RELEASE yet, and because of the reasons >> you mention, I decided to keep working on a stupidfs :-). > >I'll be updating wrapfs for 3.3 once I return from LISA. With luck, it'll >work again before you return from Albuquerque. > >> That is, that I >> don't want to add functionality to an existing file system by stacking, >> but rather to have a new simple file system that I can modify the >> semantics of in ways not encouarged by the stacking of file systems. > >If I understand you right (maybe I didn't), there are two ways to do that: > Hello, how I understand is, eg.: let's write a simple kernel fs for new developers to learn. The fs can have just 2 directories, no tree structures, max. 10 files in the directory. It will be simple so that a programmer who has little experience in writing fs's can easily look at it and understand. There is no idea about stacking or about using existing fs's together with stupid-fs. But maybe I didn't understand right :-). Therefore I think that Erez and Robert don't ,,compete'', wrapfs and stupidfs will be written for different purpose. cheers, Jan. >(1) Create a simple *native* (disk based?) file system template from which > you can possibly create new file systems that put data on disks and > floppies, right? In theory, one should be able to create msdosfs and > ffs from such a template. In practice, there are numerous details to > work out, that getting something barely working for a "stuipid" template > will require substantial effort. Such a template would be very useful > if it will have these two characteristics: (a) be small and simple, and > (b) require little modification to create file systems such as msdosfs > and ffs. I believe that with current OS technology, it is impossible to > get both 'a' and 'b' done. > >(2) If what you want is a file system that can work with other file systems, > then you're essentially asking for stacking. Yes stacking f/s usually > have to maintain VFS semantics, so that a layer is kept independent from > other layers, either above or below it. It is possible, however, for a > stackable f/s to violate this priniciple; for example, you can muck with > direct disk blocks and inode blocks from a stackable f/s. It's not > something I'd recommend, but it is possible. > >> I am >> currently traveling (IETF next week, Active Network conference in >> Alberquerque the week after) so won't get back to my development machines >> for about two weeks. After that time, I hope to get a stupidfs >> implementation to the point where it might be useful for others to see, so >> I'll put it online. As I mentioned before, the goal is to have a really >> simple file system with no backing store, appropriate for use when >> experimenting with new VOPs, etc, etc. > >I'd be very interested in seeing this. I would also suggest that before you >dive into coding, you write out a detailed design, and post it to this list, >so we could all comment on it. > >Note that extensible VFSs have been the expressed desire of stackable file >systems from the very early days. In order for me to support file system >extensibilty without changing the OS or other file systems, I had to give up >the idea of creating new VOPs. That is, you cannot add new vops using >wrapfs; you could create new ioctls, however, which are the poor man's >extensible model. IOW, if you created an infrastructure that can extend the >VFS, you'll have something that wrapfs cannot do --- something that people >have been asking for some time. (So don't call it "stuipid" :-) > >If you haven't already, you should read up on all of the classic stacking >papers first, from Rosenthal, Skinner & Wong, Heidemann, Popek, etc. Then >you might look into papers on Spring, BSD's Unionfs, and the HURD. All of >these talk about mechanisms for VFS extensibility that would be useful for >you. > >> It won't be fully functioning (for >> example, I probably won't even bother to implement symlinks) but it will >> be *simple*, meaning it can be modifed easily. It will also be separable >> into an entirely separate module, unlike UFS which has fingers everywhere, >> so it can easily be loaded and unloaded on demand during development. >> >> I wouldn't encourage anyone to use it in production--it will make a fair >> amount of use of kernel memory, as it won't back to a process--but for >> development it should be useful. > >I think you have to be very careful about your implementation. You cannot >encourage people to use something in PRODUCTION that has not been thoroughly >tested, and esp. if it's missing functionality. If you want your f/s to be >useful, make sure it works with existing VFSs and existing file systems. At >the very least, make sure it won't damage people's installations. It would >be nice if "all" it did was _add_ new VOPs, while keeping existing ones >unchanged. > >I'm speaking from experience here. I've developed wrapfs on solaris, >freebsd, and linux. In the early days, I've dealt with bugs that easily >corrupted active memory and resulted in total corruption of system and boot >partitions, to a point where a reinstallation was required. After a few >frustrating reinstallations, I wound up setting up automatic OS installation >systems (network-based booting, installing off of an auxiliary disk, even >using identical disks and dd'ing a good copy onto a trashed one). > >> 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 > >Good luck. Let me know if I can help. > >Erez. > -- Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, Praha 6, 166 35, Czech Republic) www.civ.cvut.cz, pechy.civ.cvut.cz, tel: +420 2 24352969 (fax: 24310271) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 1: 0:46 1999 Delivered-To: freebsd-fs@freebsd.org Received: from akat.civ.cvut.cz (akat.civ.cvut.cz [147.32.235.105]) by hub.freebsd.org (Postfix) with SMTP id 60C3614FFF for ; Tue, 9 Nov 1999 01:00:33 -0800 (PST) (envelope-from pechy@hp735.cvut.cz) Received: from localhost (pechy@localhost) by akat.civ.cvut.cz (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05536; Tue, 9 Nov 1999 10:00:20 +0100 Date: Tue, 9 Nov 1999 10:00:20 +0100 From: Jan Pechanec X-Sender: pechy@akat.civ.cvut.cz To: Erez Zadok Cc: freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-Reply-To: <199911051843.NAA21856@shekel.mcl.cs.columbia.edu> 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 Fri, 5 Nov 1999, Erez Zadok wrote: Why I'm interesting in this is that I would like to do something on this as my final work at university. I don't want to include my changes in any OS like FreeBSD or Linux, the work is not intended to be so vast. Maybe I would like to use Minix, it has no VFS etc. so I am free to change what I want and the changes won't be so expensive as they would be in FreeBSD, eg. I would like to try to separate fs into really small layers, ie. UFS can be devided in three layers (disk, inode, dir layer). I am not sure whether it is possible in an efficient way, but I want to try it. I can invent VFS-like interface that would be extensible etc. etc. I know that no of these changes most probably won't appear anywhere, but this is not my goal. I'm just interested. Please, could you comment whether you think it is worth the effort of not? thank you, Jan. >In message , Jan Pechanec writes: >> On Thu, 28 Oct 1999, Erez Zadok wrote: >> >> Hi, >> >> I think that it is a bit different. What Robert is hacking is >> a filesystem where in-vfs-not-experienced programmer can see how vfs >> is working. I have just read some of your papers, Erez, and I think >> that wrapfs wants me not to bother with something like vfs (just >> encode and decode routines). > >The encode and decode routines that wrapfs exports are an API that greatly >simplifies two difficult tasks: > >(1) modifying file names (e.g., translating b/t unix and 8.3 names) >(2) modifying file data (e.g., encryption) > >Every other task you want to accomplish in wrapfs, you do it right in the >actual f/s routines, right in the code itself. For example, if you wanted >to add acl support (as I've done w/ a trivial aclfs based on wrapfs), you >add the right code in lookup(). If you want to create an unrmfs (another >prototype I've got), you add it in unlink(). If you wish, you can also >touch the read/write/getpage/putpage routines directly and not use the >encode/decode API functions. But you'll find that there's a substantial >amount of support code needed to deal with data pages, locking, and a lot >more stuff around it. All of this is detailed in my Usenix 99 paper. > >> I think that Robert's effort is very useful, I wanted myself >> to write somethink like this (purpose: to learn and _touch_ vfs >> interface). Robert, do you carry on or not? > >I commend you, but don't be surprised if what you'll produce in the end will >be almost identical to wrapfs in functionality. It many ways, wrapfs is >"stupid", b/c it only provides a thin layer that passes all VOPs to the >layer below it, while maintaining semantics. Wrapfs does not do much more >than that. That's why I'm telling you now that your stupidfs may wind up >being very similar to wrapfs. You cannot get stacking functionality with >much less than wrapfs does. > >If you actually intend to modify the VFS, and add new VOPs, that'll be neat >too. But I think you'll find it a bit difficult to get VFS changes merged >into the main source tree... :-) And if you will change the VFS, you'll find >that your stupidfs does more than, and is "smarter" than wrapfs. > >You cannot introduce new VOPs w/o changing the VFS, and if you change the >VFS, you must make sure that other (native) file systems do something >reasonable with these new VOPs. > >> -- >> Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, >> Praha 6, 166 35, Czech Republic) http://www.civ.cvut.cz, tel: +420 2 2435 >> 2969, http://pechy.civ.cvut.cz > >Jan et al. I'm not trying to "hawk my merchandise" on you, but rather to >save you a great deal of effort repeating that which has been done before. >I've created and released my wrapfs templates so that others could build on >them, and create hopefully really useful (even commercial) file systems. It >may sound corny, but I hope that my work will revitalize the stagnating >field of stackable file systems research. You may save a lot of time, and >still be able to learn much, by starting with my wrapfs code, and modifying >it to your needs. I will be happy to help you in any way I can. > >Cheers, >Erez. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-fs" in the body of the message > -- Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, Praha 6, 166 35, Czech Republic) www.civ.cvut.cz, pechy.civ.cvut.cz, tel: +420 2 24352969 (fax: 24310271) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 1: 4:50 1999 Delivered-To: freebsd-fs@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4A32D150BC for ; Tue, 9 Nov 1999 01:04:24 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B69CF1CC7; Tue, 9 Nov 1999 17:04:22 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Pechanec Cc: Mats Lofkvist , freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-reply-to: Your message of "Tue, 09 Nov 1999 09:45:55 +0100." Date: Tue, 09 Nov 1999 17:04:22 +0800 From: Peter Wemm Message-Id: <19991109090422.B69CF1CC7@overcee.netplex.com.au> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jan Pechanec wrote: > On 6 Nov 1999, Mats Lofkvist wrote: > > >julian@whistle.com (Julian Elischer) writes: > >> On Fri, 5 Nov 1999, Jan Pechanec wrote: > >> > > >> > BTW, don't you know why deadfs was written? No doc in FreeBSD. > >> > From what I saw in the source code, operations just fail. > >> > > >> When youhave a vnode open, and for some reason the filesystem the vmode > >> pints to disappears (e.g. the disk is removed, or the PC-CARD is removed, > >> or many other posibilties), then you cannot track down all teh users fo > >> that vnode very easily, so insteadm you 'fiddle' with it to make it > >> reference the DEADFS (use VGONE) and when the users try use it again they > >> will safely get an error, but at least the system will > >> not core-dump when they access a non existant filesyste,/device. > > > >I guess deadfs is what makes the -f (force) flag to umount work > >also, and that one is a truly great feature in FreeBSD missing in > >many other unixen (e.g. solaris {and linux, I believe}). > > > >Having to track down all processes with open descriptors on e.g. > >a nfs mount before being able to umount it is a real pain in the *, > >most times I give up on it and reboot the machine instead. > > I am not so experienced with FreeBSD, but SGI IRIX has > ``fuser'' command. This command can find all processes that has open > files inside the mounted fs. You can easily write a script that kill > them all. SVR4's fuser command (derived from SVR3 which was a bit simpler) had a built-in -k (kill) switch. So, you could 'fuser -k /home' which would kill -9 any process using /home. The problem was it had a bit of a nasty tendancy to panic the system since it was moved from userland to a syscall in SVR4.0. Anyway, deadfs is another solution to the problem. I would use both if available. 'fstat' and 'lsof' are reasonable substitutes for fuser. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 13:46:15 1999 Delivered-To: freebsd-fs@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7D58914C05 for ; Tue, 9 Nov 1999 13:45:58 -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.3/8.9.3) with ESMTP id WAA25971 for ; Tue, 9 Nov 1999 22:45:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA02925 for fs@FreeBSD.org; Tue, 9 Nov 1999 22:45:54 +0100 (MET) Date: Tue, 9 Nov 1999 22:45:54 +0100 From: Eivind Eklund To: fs@FreeBSD.org Subject: Killing WILLRELE Message-ID: <19991109224553.G256@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm looking at removing WILLRELE from the VFS specs, in order to get more sane semantics before introducing many more VFS consumers through stacking layers. I'm sending this as a 'HEADS UP!', a chance for people to object, and to give a chance at an advance view. Note that the present set of patches has not been tested beyond compilation; I'm reserving testing until after I've let people have the chance to scream at me (as I don't see a point in testing the changes unless people agree that they are a step in the right direction). There are presently three VOPs that use it: VOP_MKNOD Uses this for the 'vpp' parameter (should be the return vnode for the newly created node, I believe). The value is presently unusable; depending on which FS you call, it it is either set to NULL, set to point to a vnode (MSDOSFS), or just kept the way it was. (Note that MSDOSFS will leak vnodes as of today). I've been tempted to remove it, but am not entirely happy about that, as I think it might be useful for some stacked layers. Thanks to phk, I've been able to come up with patches to fix it - but these will increase the cost of VOP_MKNOD() (only slightly, I think, but I am not quite certain). The other alternatives are to remove the parameter, or to break the layering around ufs_mknod (basically, re-implement parts of VFS_VGET in it, and make it assume that it is only used with ffsspecops and ffsfifoops. This is presently correct, but introduces risk of breakage down the road.) Both of these alternatives are slightly more efficient than my preferred fix. Patches to make VOP_MKNOD use vpp normally are http://www.freebsd.org/~eivind/vop_mknod_fixed.patch It is possible that the NFS vp release would have been handled by common code if I hadn't added special code there, but I feel too uncomfortable around the NFS code/macros to try to find out. Patches to just remove the parameter are at http://www.freebsd.org/~eivind/vop_mknod_novpp.patch VOP_MKNOD has 5 callers. VOP_SYMLINK Same use of WILLRELE as VOP_MKNOD. Returns trash in some cases, OK values in others; relatively simple to fix, with Coda as the only complication. Patches to fix it are at http://www.freebsd.org/~eivind/vop_symlink_fixed.patch These will break Coda, which I'm planning to contact rvb about how to solve if people agree that WILLRELE should die. VOP_SYMLINK has 3 callers. VOP_RENAME WILLRELE on a bunch of parameters. Adrian Chadd is doing several things to VOP_RENAME which is relevant to this, so I'm keeping my hands off it for the moment. Hopefully, patches should be available later in the week. My next step along the sane semantics road will probably be to make freeing of cnp's reflexive - looking at the code that is there now, there looks like there are a number of bugs related to this at the moment, and it certainly makes the code much harder to follow. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 23: 5:44 1999 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 789F214BD7 for ; Tue, 9 Nov 1999 23:05:31 -0800 (PST) (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.1/8.9.1) with ESMTP id CAA11913; Wed, 10 Nov 1999 02:05:30 -0500 (EST) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id CAA09303; Wed, 10 Nov 1999 02:05:29 -0500 (EST) Date: Wed, 10 Nov 1999 02:05:29 -0500 (EST) Message-Id: <199911100705.CAA09303@shekel.mcl.cs.columbia.edu> X-Authentication-Warning: shekel.mcl.cs.columbia.edu: ezk set sender to ezk@shekel.mcl.cs.columbia.edu using -f From: Erez Zadok To: Mats Lofkvist Cc: freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-reply-to: Your message of "06 Nov 1999 19:33:46 +0100." Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Mats Lofkvist writes: [...] > I guess deadfs is what makes the -f (force) flag to umount work also, and > that one is a truly great feature in FreeBSD missing in many other unixen > (e.g. solaris {and linux, I believe}). Hear hear. It's very useful when a user-level automounter dies. In such cases even kill -9 doesn't help, umount -f does. [...] > Mats Lofkvist > mal@algonet.se > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Nov 9 23:31:34 1999 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 9551314BCC for ; Tue, 9 Nov 1999 23:31:25 -0800 (PST) (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.1/8.9.1) with ESMTP id CAA14064; Wed, 10 Nov 1999 02:31:25 -0500 (EST) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id CAA10809; Wed, 10 Nov 1999 02:31:24 -0500 (EST) Date: Wed, 10 Nov 1999 02:31:24 -0500 (EST) Message-Id: <199911100731.CAA10809@shekel.mcl.cs.columbia.edu> X-Authentication-Warning: shekel.mcl.cs.columbia.edu: ezk set sender to ezk@shekel.mcl.cs.columbia.edu using -f From: Erez Zadok To: Jan Pechanec Cc: Erez Zadok , freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-reply-to: Your message of "Tue, 09 Nov 1999 10:00:20 +0100." Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Jan Pechanec writes: > On Fri, 5 Nov 1999, Erez Zadok wrote: > > Why I'm interesting in this is that I would like to do > something on this as my final work at university. I don't want to > include my changes in any OS like FreeBSD or Linux, the work is not > intended to be so vast. > > Maybe I would like to use Minix, it has no VFS etc. so I am > free to change what I want and the changes won't be so expensive as > they would be in FreeBSD, eg. I would like to try to separate fs into > really small layers, ie. UFS can be devided in three layers (disk, > inode, dir layer). I am not sure whether it is possible in an > efficient way, but I want to try it. I can invent VFS-like interface > that would be extensible etc. etc. I know that no of these changes > most probably won't appear anywhere, but this is not my goal. I'm just > interested. > > Please, could you comment whether you think it is worth the > effort of not? > > thank you, Jan. I understand better now. Thanks. Yes what you're proposing would be useful, if it is really really simple. I think it'd be a useful teaching tool, for people who want to learn file systems w/o the huge overhead of a fully-featured f/s. I would suggest you consider the msdosfs sources, being that they are probably the simplest, and remove much of the code to make it, say, use a limited number of dirs and files. Erez. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Nov 11 6: 1: 5 1999 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.43.150]) by hub.freebsd.org (Postfix) with ESMTP id CAF3914D95; Thu, 11 Nov 1999 06:01:02 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id NAA00369; Thu, 11 Nov 1999 13:57:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Eivind Eklund Cc: fs@FreeBSD.ORG Subject: Re: Killing WILLRELE In-reply-to: Your message of "Tue, 09 Nov 1999 22:45:54 +0100." <19991109224553.G256@bitbox.follo.net> Date: Thu, 11 Nov 1999 13:57:33 +0100 Message-ID: <367.942325053@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My position is that WILLRELE should die. A performance hit in MKNOD is not a problem. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Nov 11 15: 4:20 1999 Delivered-To: freebsd-fs@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 312C114E4A for ; Thu, 11 Nov 1999 15:04:16 -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.3/8.9.3) with ESMTP id AAA02575 for ; Fri, 12 Nov 1999 00:04:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA14093 for fs@FreeBSD.org; Fri, 12 Nov 1999 00:04:14 +0100 (MET) Date: Fri, 12 Nov 1999 00:03:59 +0100 From: Eivind Eklund To: fs@FreeBSD.org Subject: namei() and freeing componentnames Message-ID: <19991112000359.A256@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would like to make this reflexive - "symmetrical" allocation and free, like it presently is supposed to be with SAVESTART (but isn't - there are approximately one billion bugs in the code). I suspect that for some filesystems (though none of the present ones), it might be necessary to do more than a zfree(namei_zone,cnp->cn_pnbuf) in order to free up all the relevant data. In order to support this, we'd have to introduce a new VOP - tentatively called VOP_RELEASEND(). Unfortunately, this comes with a performance penalty. As we presently do not need this capability, I am thinking of "faking" VOP_RELEASEND() - make it into a macro similar to this: #define VOP_RELEASEND(vp, cnp) do { \ (void)(vp); /* Do side effects of (vp) */ \ zfree(namei_zone, (cnp)->cn_pnbuf; \ } while (0) This is somewhat vile, but has the advantage of keeping the code ready for the real VOP_RELEASEND(), and not loosing performance until we actually get some benefit out of it. Do the rest of you consider it too vile to do, or is it an OK tradeoff? (Personally, I consider it an OK tradeoff.) It also allows an evil hack: The NFS code is rather incestuous with the VFS system, in order to minimize the amount of cached data during NFS requests. One side of this is that it seems to throw away the vnode we'd like to use for VOP_RELEASEND() - before it wants to throw away the componentname. With the macro, NFS could use VOP_RELEASEND(NULL, ); for the time being, crashing in a very obvious way when we find we need to introduce the actual VOP. This avoids re-structuring the NFS code until we actually get benefits from VOP_RELEASEND. Is it too evil? I'm of two minds - I don't like messing more than necessary with the NFS code (and isn't sure I could do the messing without performance impact), but I'm not exactly ecstatic about the hack, either. I've got first pass patches for the above (not tested, not compiled, not done the three different forms of review for errors I'm planning to do). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Nov 11 15:10:28 1999 Delivered-To: freebsd-fs@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D9B0E14F66; Thu, 11 Nov 1999 15:10:25 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA96628; Thu, 11 Nov 1999 15:10:24 -0800 (PST) Date: Thu, 11 Nov 1999 15:10:23 -0800 (PST) From: Julian Elischer To: Eivind Eklund Cc: fs@FreeBSD.ORG, terry@lambert.org Subject: Re: namei() and freeing componentnames In-Reply-To: <19991112000359.A256@bitbox.follo.net> 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 didn't terry have some patches for this? On Fri, 12 Nov 1999, Eivind Eklund wrote: > I would like to make this reflexive - "symmetrical" allocation and > free, like it presently is supposed to be with SAVESTART (but isn't - > there are approximately one billion bugs in the code). > > I suspect that for some filesystems (though none of the present ones), > it might be necessary to do more than a > zfree(namei_zone,cnp->cn_pnbuf) in order to free up all the relevant > data. In order to support this, we'd have to introduce a new VOP - > tentatively called VOP_RELEASEND(). Unfortunately, this comes with a > performance penalty. > > As we presently do not need this capability, I am thinking of > "faking" VOP_RELEASEND() - make it into a macro similar to this: > #define VOP_RELEASEND(vp, cnp) do { \ > (void)(vp); /* Do side effects of (vp) */ \ > zfree(namei_zone, (cnp)->cn_pnbuf; \ > } while (0) > > This is somewhat vile, but has the advantage of keeping the code ready > for the real VOP_RELEASEND(), and not loosing performance until we > actually get some benefit out of it. > > Do the rest of you consider it too vile to do, or is it an OK > tradeoff? (Personally, I consider it an OK tradeoff.) > > It also allows an evil hack: > The NFS code is rather incestuous with the VFS system, in order to > minimize the amount of cached data during NFS requests. One side of > this is that it seems to throw away the vnode we'd like to use for > VOP_RELEASEND() - before it wants to throw away the componentname. > With the macro, NFS could use VOP_RELEASEND(NULL, ); for the > time being, crashing in a very obvious way when we find we need to > introduce the actual VOP. This avoids re-structuring the NFS code > until we actually get benefits from VOP_RELEASEND. > > Is it too evil? I'm of two minds - I don't like messing more than > necessary with the NFS code (and isn't sure I could do the messing > without performance impact), but I'm not exactly ecstatic about the > hack, either. > > I've got first pass patches for the above (not tested, not compiled, > not done the three different forms of review for errors I'm planning > to do). > > Eivind. > > > 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 Sat Nov 13 10:11:58 1999 Delivered-To: freebsd-fs@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id DC65214D1C; Sat, 13 Nov 1999 10:11:24 -0800 (PST) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id JAA17021; Sat, 13 Nov 1999 09:42:06 -0800 (PST) Message-Id: <199911131742.JAA17021@flamingo.McKusick.COM> To: Eivind Eklund Subject: Re: Killing WILLRELE (fwd) Cc: fs@freebsd.org Date: Sat, 13 Nov 1999 11:42:06 -0600 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am of the opinion that WILLRELE should die. It was never meant as anything but a temporary hack. I concur with your preferred fix to VOP_MKNOD. Performance of the VOP_MKNOD operator is not an issue as it is rarely used. Kirk McKusick =-=-=-=-=-=-=-= Date: Tue, 9 Nov 1999 22:45:54 +0100 From: Eivind Eklund To: fs@FreeBSD.ORG Subject: Killing WILLRELE I'm looking at removing WILLRELE from the VFS specs, in order to get more sane semantics before introducing many more VFS consumers through stacking layers. I'm sending this as a 'HEADS UP!', a chance for people to object, and to give a chance at an advance view. Note that the present set of patches has not been tested beyond compilation; I'm reserving testing until after I've let people have the chance to scream at me (as I don't see a point in testing the changes unless people agree that they are a step in the right direction). There are presently three VOPs that use it: VOP_MKNOD Uses this for the 'vpp' parameter (should be the return vnode for the newly created node, I believe). The value is presently unusable; depending on which FS you call, it it is either set to NULL, set to point to a vnode (MSDOSFS), or just kept the way it was. (Note that MSDOSFS will leak vnodes as of today). I've been tempted to remove it, but am not entirely happy about that, as I think it might be useful for some stacked layers. Thanks to phk, I've been able to come up with patches to fix it - but these will increase the cost of VOP_MKNOD() (only slightly, I think, but I am not quite certain). The other alternatives are to remove the parameter, or to break the layering around ufs_mknod (basically, re-implement parts of VFS_VGET in it, and make it assume that it is only used with ffsspecops and ffsfifoops. This is presently correct, but introduces risk of breakage down the road.) Both of these alternatives are slightly more efficient than my preferred fix. Patches to make VOP_MKNOD use vpp normally are http://www.freebsd.org/~eivind/vop_mknod_fixed.patch It is possible that the NFS vp release would have been handled by common code if I hadn't added special code there, but I feel too uncomfortable around the NFS code/macros to try to find out. Patches to just remove the parameter are at http://www.freebsd.org/~eivind/vop_mknod_novpp.patch VOP_MKNOD has 5 callers. VOP_SYMLINK Same use of WILLRELE as VOP_MKNOD. Returns trash in some cases, OK values in others; relatively simple to fix, with Coda as the only complication. Patches to fix it are at http://www.freebsd.org/~eivind/vop_symlink_fixed.patch These will break Coda, which I'm planning to contact rvb about how to solve if people agree that WILLRELE should die. VOP_SYMLINK has 3 callers. VOP_RENAME WILLRELE on a bunch of parameters. Adrian Chadd is doing several things to VOP_RENAME which is relevant to this, so I'm keeping my hands off it for the moment. Hopefully, patches should be available later in the week. My next step along the sane semantics road will probably be to make freeing of cnp's reflexive - looking at the code that is there now, there looks like there are a number of bugs related to this at the moment, and it certainly makes the code much harder to follow. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message