From owner-freebsd-fs Sun Feb 1 04:12:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA00837 for freebsd-fs-outgoing; Sun, 1 Feb 1998 04:12:43 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from shadows.aeon.net (shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA00813 for ; Sun, 1 Feb 1998 04:12:39 -0800 (PST) (envelope-from bsdfs@shadows.aeon.net) Received: (from bsdfs@localhost) by shadows.aeon.net (8.8.8/8.8.3) id OAA02537 for fs@freebsd.org; Sun, 1 Feb 1998 14:12:19 +0200 (EET) From: mika ruohotie Message-Id: <199802011212.OAA02537@shadows.aeon.net> Subject: log/journal fs In-Reply-To: <199801312252.QAA10636@friley585.res.iastate.edu> from Chris Csanady at "Jan 31, 98 04:52:51 pm" To: fs@FreeBSD.ORG Date: Sun, 1 Feb 1998 14:12:19 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" > >I have decided to code up an IBM-style journaling filesystem > >(jfs) with maximum portability for free unices. While I'm at it > This is quite nice to hear, I would love to see a journaling file system > for FreeBSD. If you were to base it on JFS, you might want to talk ditto. anyone ever having some modern journalling code to be tested on freebsd, i'm volunteering for testing. as probably some people might remember, i've been hoping to have "freebsd-xfs" for like a year or something... mickey From owner-freebsd-fs Sun Feb 1 05:15:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA05912 for freebsd-fs-outgoing; Sun, 1 Feb 1998 05:15:43 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from magicnet.magicnet.net (root@magicnet.magicnet.net [204.96.116.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA05907 for ; Sun, 1 Feb 1998 05:15:41 -0800 (PST) (envelope-from bill@bilver.magicnet.net) Received: from bilver.magicnet.net (uucp@localhost) by magicnet.magicnet.net (8.8.6/8.8.6) with UUCP id IAA05516 for freebsd-fs@freebsd.org; Sun, 1 Feb 1998 08:13:26 -0500 (EST) Received: (from bill@localhost) by bilver.magicnet.net (8.8.5/8.7.3) id IAA15329 for freebsd-fs@freebsd.org; Sun, 1 Feb 1998 08:02:42 -0500 (EST) From: Bill Vermillion Message-Id: <199802011302.IAA15329@bilver.magicnet.net> Subject: Re: Filesystem hacking In-Reply-To: <199801311727.LAA13881@x115-105.reshalls.umn.edu> from "mikk0022@maroon.tc.umn.edu" at "Jan 31, 98 11:27:19 am" To: freebsd-fs@FreeBSD.ORG Date: Sun, 1 Feb 1998 08:02:42 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" Recently mikk0022@maroon.tc.umn.edu said: > On Fri, 30 Jan 1998 14:52:27 -0600 "Alton, Matthew" wrote > >I have decided to code up an IBM-style journaling filesystem > >(jfs) with maximum portability for free unices. ... ... > What do you know about LFS for FreeBSD. I haven't used > it, but from what I understand, it was an early implementation > of a "log-structured filesystem" for BSD. Are "log-structured" > and "journaling" synonymous? > I know that SGI's XFS is a hybrid, where each filesystem has a log > which stores committed operations on the filesystem. The filesystem > is a fairly normal filesystem from what I understand. .... I don't know a great deal about the XFS, but it's not 'fairly normal' in some respects. It does appear to be robust. However I had some tracks go bad on an HD and fx wasn't able to read and recover them so they were left there bad. fsck won't run ons xfs as it's nots needed. The only cure for this problem is to backup the system and remake the filesystem. I will say that it is darned fast however. We're going to be moving virutally all of the web sites from the SGI's to FreeBSD and Apache with the exception of the catalog sites. (the package runs only on NT, SGI's Irix, Sun's Solaris. The HP/UX port is almost done) -- bill@bilver.magicnet.net | bill@bilver.com From owner-freebsd-fs Sun Feb 1 12:06:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25124 for freebsd-fs-outgoing; Sun, 1 Feb 1998 12:06:18 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from x115-105.reshalls.umn.edu (x115-105.reshalls.umn.edu [134.84.115.105]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25103; Sun, 1 Feb 1998 12:06:10 -0800 (PST) (envelope-from chris@x115-105.reshalls.umn.edu) Received: from x115-105.reshalls.umn.edu (localhost [127.0.0.1]) by x115-105.reshalls.umn.edu (8.8.7/8.8.7) with ESMTP id NAA18654; Sun, 1 Feb 1998 13:45:58 -0600 (CST) (envelope-from chris@x115-105.reshalls.umn.edu) Message-Id: <199802011945.NAA18654@x115-105.reshalls.umn.edu> From: mikk0022@maroon.tc.umn.edu To: Terry Lambert cc: Matthew.Alton@anheuser-busch.com, fs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Filesystem hacking In-reply-to: Your message of "Sun, 01 Feb 1998 00:49:17 GMT." <199802010049.RAA18732@usr06.primenet.com> References: <199802010049.RAA18732@usr06.primenet.com> Date: Sun, 01 Feb 1998 13:45:58 -0600 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" On Sun, 1 Feb 1998 00:49:17 +0000 (GMT) Terry Lambert wrote >> What do you know about LFS for FreeBSD. I haven't used >> it, but from what I understand, it was an early implementation >> of a "log-structured filesystem" for BSD. Are "log-structured" >> and "journaling" synonymous? > >No, they are not. A log-structured FS logs data; a journalling >FS logs data and transactions in a transaction journal. > >A log structured FS can only roll transactions back to recover from >failures. A journalling FS can roll transactions forward. OK, let's see if I get this -- a log-structured filesystem stores file data and metadata only in its log. A journaling filesystem stores data, metadata, *and operations* in the log? >A Journalling FS also allows you to expose a transactioning interface >to allow you to group transactions. Is there a portable way to do this? >XFS internally seems to look a lot like NTFS internally. That is, >it seems to journal. I've only looked at images of small XFS's >snapshotted before and after transactions, I haven't really >snooped out the structure. You probably know more about both than I do. All I know about XFS is what I read in the "white paper" on SGI's web site... >> As far as Logical Volume Management, SGI's XLV is a good target >> (can you tell what kind of UNIXen I use at work yet? :-). In my >> understanding, the system marks each disk with its place in the >> volume, so the logical volume can be automagically composed on >> boot-up. This is nice, because there is no configuration file to >> worry about, and you can move around the disks on the >> SCSI chain without affecting the volume. > >CCD can do this as well. How? I thought CCD built the logical volumes from /etc/ccd.conf on bootup. Thus, moving around disks would require editing /etc/ccd.conf on bootup. XLV does this all automatically. Or has this been added in -current ? -- Chris Mikkelson mikk0022@maroon.tc.umn.edu Microsoft: We're the software company -- we don't care, 'cause we don't have to. --- Lily Tomlin, updated From owner-freebsd-fs Sun Feb 1 13:37:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10531 for freebsd-fs-outgoing; Sun, 1 Feb 1998 13:37:01 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10514; Sun, 1 Feb 1998 13:36:58 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA25034; Sun, 1 Feb 1998 14:27:06 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd025020; Sun Feb 1 14:27:03 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA29406; Sun, 1 Feb 1998 14:26:58 -0700 (MST) From: Terry Lambert Message-Id: <199802012126.OAA29406@usr09.primenet.com> Subject: Re: Filesystem hacking To: mikk0022@maroon.tc.umn.edu Date: Sun, 1 Feb 1998 21:26:58 +0000 (GMT) Cc: tlambert@primenet.com, Matthew.Alton@anheuser-busch.com, fs@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199802011945.NAA18654@x115-105.reshalls.umn.edu> from "mikk0022@maroon.tc.umn.edu" at Feb 1, 98 01:45:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" > OK, let's see if I get this -- a log-structured filesystem stores > file data and metadata only in its log. A journaling filesystem > stores data, metadata, *and operations* in the log? A log structure filesystem logs writes. The youngets write claiming to contain some data wins. The data and metadata are written seperately, but tagged as being together for write that span more than one logging region. Otherwise, they are written together. The "valid" stamp is the last thing written to the log. On reboot, the logs are scanned to "find out where everything is". Oldest date wins, so long as it has a "valid" stamp. For multilog transactions, the "valid stamp is delayed for two or more writes. Logged data does not map 1:1 to user data; for example, you may log several otherwise unrelated writes in the same log. Thus if you fail before a valid stamp, the transactions are rolled back. It is the only thing you can do. A journallying filesystem journals what it is going to do, and that it has done it. If the power goes out after it has stated a full intention, and it hasn't written that it has done it, all full intentions can be rolled forward, not just back. Because the transaction relationship is held in the journal, not in the FS data or metadata, a journalling FS can expose a transactioning interface to user space to allow a program to group intentions. > >A Journalling FS also allows you to expose a transactioning interface > >to allow you to group transactions. > > Is there a portable way to do this? Yes. But it requires a graphical soloution to the soft updates problem; most soloutions to the soft updates problem are hand optimized for how they resolve node-node conflicts, and hand-coded to problem they attempt to solve. Kirk McKusicks port of the Ganger/Patt code is an example of this. To expose a transactioning mechanism, you must allow the specification of soft dependencies *between* stacking layers. Effectively, this means you run a warshal's algorithm on the event/operation nodes that make up the graph of relationships Example 1: I have an event called "delete file". To delete the file, I must perform serveral operations: 1) Delete the blocks hung off the inode 2) Zero the inode 3) Remove the directory entry referring to the inode These operations are "nodes" in a graph, and the meta-operation (or event) is "delete a file"; it constitutes an edge of three nodes. This means that there are two dependency vectors in the graph, and that they have a relationship defined by the connecting node. I'll spare you the details of the dependency resoloution algorithm; you can read Kirk McKusick's code from OpenBSD (not for commercial use without license), or you can read the Ganger/Patt paper. Now, to expose a transactioning system, you need a general algorithm for defining dependencies. Effectively, when you stack your NULLFS layer with the new VOP (or ioctl) "TRANSACT", which takes the arguments "begin", "commit", and "abort". What this means is that you must expose the internals of your graph so that you can register your own "dependency resolvers". Example 2: I have a transaction that requires the deletion of two files. To do this, I must perform the same three operations above, but I must do it twice, and I must abort both operations if I can't complete one. I must also be able to roll-back/roll-forward the operations if the system fails and comes back up. How do I do this? The transaction layer is not really NULL. When you begin a transaction, it uses a namespace escaped file to journal all subsequent VOP's, and to make subsequent requests *appear* to get the new data. It can do this several ways, but the most probable one is to use renames and copies, because renames are atomic. This will allow it to support the transactions on any underlying FS. Alternately, it can journal the transaction by hooking into the dependency queueing mechanism to ensure that the transaction is committed in vector-terminal order. Example 3: A transaction consisting of two events, one containing two nodes, and one containing three: a log write followed by a delete. The transaction system creates an imaginary edge between the terminal node of the log write (the update of the inode size) and the terminal node of the delete (the update of the directory entry block). This edge is a dynamic soft dependency; it is created on the fly, and it will go away after the event (transaction) it represents has completed. It's pretty obvious that the dependency resolvers need to consider the action nodes seperately, and not as an "edge" unit -- in other words, not like the Ganger/Patt code -- for this to be able to work. This is because the transaction layer can't resolve dependencies between edges, only between nodes. This damages some optimizations, mostly having to do with compresion of dependency enumerations (McKusick uses bitmaps for this; technically, you could still do this, but on a node, not an edge, granularity. I *believe* that the losses would be minimal, but I don't have a proof-of-concept implementation of both [yet] to be able to benchmark the monolitic vs. the nodal implementations against each other). So yes, it's possible to do generically, if you think of FS's in terms of events, operations, and dependencies between operations, and if you have soft update technology, and if you implement it correctly. Probably, it's easier at this point to just write a JFS and not worry about making everything work the way it should. Going the other way would probably be worthy of a PhD to somone looking for a Doctoral project. ;-). [ ...automatic aggregation of volumes... ] > >CCD can do this as well. > > How? I thought CCD built the logical volumes from /etc/ccd.conf > on bootup. Thus, moving around disks would require editing > /etc/ccd.conf on bootup. XLV does this all automatically. > > Or has this been added in -current ? No, but it is a trivial hack to add it. Julian's "slice" and "devfs" code provide "volume arrival" events. These events do not propagate as far as I want them to (an arriving device with no claimers would be handed to the VFS for mount in my model), but you could easily put CCD in as a slice type handler. When a device "arrives", you would read the first block and see if it has a "CCDLABEL"; if it does, CCD swallows it. The label contains: 1) A magic number ("CCDLABEL" is as good as any) that means "I am a member of a volume set". 2) A volume set identifier; probably just a unique-across-volumes 32 bit identifier. 3) A count of devices in the volume. 4) An ID indicating which of the devices in #3 the current device represents. When CCD get N of N devices, it exports "/dev/ccd0". It would probably be a good idea to have a "no more devices" event propagated to CCD as well; this would let it recognize a failed RAID-5 subassembly (for example), but it's not absolutely necessary. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-fs Mon Feb 2 09:41:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA29039 for freebsd-fs-outgoing; Mon, 2 Feb 1998 09:41:45 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from zeus.carroll.com (zeus.carroll.com [199.224.10.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA29030 for ; Mon, 2 Feb 1998 09:41:43 -0800 (PST) (envelope-from jim@carroll.com) Received: from apollo.carroll.com [199.224.10.3] by zeus.carroll.com with ESMTP (8.8.5/0) id MAA14592; Mon, 2 Feb 1998 12:41:36 -0500 Received: by apollo.carroll.com (8.8.5) is MAA20188; Mon, 2 Feb 1998 12:41:35 -0500 Date: Mon, 2 Feb 1998 12:41:29 -0500 From: Jim Carroll To: freebsd-fs@FreeBSD.ORG Subject: hard errors 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 X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" > wd0s1e: hard error reading fsbn 721266 of 721264-721279 (wd0s1 bn 1057138; cn 262 tn 11 sn 61)wd0: status 59 error 40 > wd0s1e: hard error reading fsbn 721266 of 721264-721279 (wd0s1 bn 1057138; cn 262 tn 11 sn 61)wd0: status 59 error 40 > wd0s1e: hard error reading fsbn 721266 of 721264-721279 (wd0s1 bn 1057138; cn 262 tn 11 sn 61)wd0: status 59 error 40 > wd0s1e: hard error reading fsbn 721266 of 721264-721279 (wd0s1 bn 1057138; cn 262 tn 11 sn 61)wd0: status 59 error 40 Can someone point me towards a man page, FAQ, book or other reference that would describe what I can do about the above sort of error? I have looked over the bad144 docs, but it appears this software is considered obsolete. Unfortuantely, I cannot figure out what is it's contemporary replacement. Thanks --- Jim C., President | C A R R O L L - N E T, Inc. 201-488-1332 | New Jersey's Premier Internet Service Provider www.carroll.com | From owner-freebsd-fs Tue Feb 3 22:21:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24577 for freebsd-fs-outgoing; Tue, 3 Feb 1998 22:21:11 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from master.inter-linc.net ([12.10.101.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24570 for ; Tue, 3 Feb 1998 22:21:06 -0800 (PST) (envelope-from cdillon@inter-linc.net) Received: from cheetah.inter-linc.net (207.3.81.148) by master.inter-linc.net (Worldmail 1.3.167) for freebsd-fs@freebsd.org; 4 Feb 1998 00:19:37 -0600 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 04 Feb 1998 00:02:01 -0600 (CST) From: Chris Dillon To: freebsd-fs@FreeBSD.ORG Subject: May have pounced on something weird with ccd and newfs (rather old) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" A short time ago (late November or early December of 1997, about when these maillists started bouncing mail for people that didn't have valid reverse lookups) I tried to post a bit about the tests I I did to figure out which ccd stripe size would probably work best with my equipment. Running 2.2.5-stable, I set up two new IBM DCAS-34330W's (4.3GB UW-SCSI) on a Tekram DC-390F and tried setting various stripe sizes with ccd and running bonnie on the resulting filesystems. I did something like this: ccdconfig -c ccd0 $BLOCKSIZE 0 /dev/sd0s1g /dev/sd1s1g newfs -b 8192 -f 1024 ccd0c mount /dev/ccd0c /mnt bonnie -d /mnt -s 100 -m "I=$BLOCKSIZE" | grep "I=" >> ~/ccdtest.txt umount -f /dev/ccd0c (only did -f since weirdly enough, it would fail sometimes) ccdconfig -u ccd0 BLOCKSIZE varied from 0 to 8192, in powers of two (0, 16, 32, 64, etc.). Here is the resulting output of the above. -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU std 100 3462 97.9 7636 40.8 2976 28.6 3732 98.6 7942 32.3 153.9 7.2 I=0 100 3422 98.0 7311 37.1 2905 28.0 3707 98.5 7404 29.8 156.8 7.5 I=16 100 3319 96.1 12043 81.3 4515 45.4 3626 97.3 12683 66.4 167.3 8.2 I=32 100 3418 97.2 13433 87.8 4747 46.1 3671 98.3 14597 77.5 164.5 8.1 I=64 100 3413 97.0 13986 89.9 4844 47.2 3700 98.9 14703 74.8 166.9 8.2 I=128 newfs -b 8192 -f 1024 fails with "write error: 2047871 wtfs: invalid argument". I=256 100 3433 97.3 12782 92.2 4912 52.7 3718 98.9 13539 88.9 165.9 9.3 I=512 100 3474 98.1 12391 86.7 6107 66.6 3746 98.8 12306 75.7 166.6 9.3 I=1024 100 3473 98.0 12403 91.1 4449 49.5 3735 98.5 9870 57.7 170.4 9.6 I=2048 100 3453 98.0 11876 88.2 3493 39.1 3752 98.8 8397 47.0 168.9 9.5 I=4096 100 3449 98.1 11851 84.0 3217 35.6 3708 98.2 7922 44.2 169.3 9.5 I=8192 100 3464 97.8 12011 87.9 3116 32.8 3745 99.0 7652 42.4 174.8 9.9 "std" is the output when NOT using ccd (i.e., a regular disk). With a ccd stripe size of 128, newfs refused to create a filesystem with the error you see above. (I decided on using the 64 block stripe ultimately, by the way.) Is this a known anomaly, or did I stumble onto some underlying problem? If this is common knowledge, please enlighten me. :-) This also seemed like the appropriate maillist to post this to (I'm on just about ALL of them), but if not, I'll move it elsewhere. --- Chris Dillon --- cdillon@inter-linc.net --- Powered by FreeBSD, the best operating system on the planet for Intel x86 based computers (and soon Sparcs). ---- (http://www.freebsd.org) From owner-freebsd-fs Wed Feb 4 02:12:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24557 for freebsd-fs-outgoing; Wed, 4 Feb 1998 02:12:33 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from silvia.HIP.Berkeley.EDU (ala-ca36-04.ix.netcom.com [207.93.42.196]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA24550 for ; Wed, 4 Feb 1998 02:12:30 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id CAA02979; Wed, 4 Feb 1998 02:12:19 -0800 (PST) Date: Wed, 4 Feb 1998 02:12:19 -0800 (PST) Message-Id: <199802041012.CAA02979@silvia.HIP.Berkeley.EDU> To: cdillon@inter-linc.net CC: freebsd-fs@FreeBSD.ORG In-reply-to: (message from Chris Dillon on Wed, 04 Feb 1998 00:02:01 -0600 (CST)) Subject: Re: May have pounced on something weird with ccd and newfs (rather old) From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" * ccdconfig -c ccd0 $BLOCKSIZE 0 /dev/sd0s1g /dev/sd1s1g * newfs -b 8192 -f 1024 ccd0c * mount /dev/ccd0c /mnt * bonnie -d /mnt -s 100 -m "I=$BLOCKSIZE" | grep "I=" >> ~/ccdtest.txt * umount -f /dev/ccd0c (only did -f since weirdly enough, it would fail sometimes) * ccdconfig -u ccd0 * I=128 newfs -b 8192 -f 1024 fails with "write error: 2047871 * wtfs: invalid argument". * "std" is the output when NOT using ccd (i.e., a regular disk). With * a ccd stripe size of 128, newfs refused to create a filesystem with * the error you see above. (I decided on using the 64 block stripe * ultimately, by the way.) Could you have an old disklabel in there by any chance? See if the size given in "disklabel ccd0" is consistent with "ccdconfig -g". Satoshi From owner-freebsd-fs Wed Feb 4 07:38:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA03914 for freebsd-fs-outgoing; Wed, 4 Feb 1998 07:38:27 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from master.inter-linc.net ([12.10.101.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA03906 for ; Wed, 4 Feb 1998 07:38:21 -0800 (PST) (envelope-from cdillon@inter-linc.net) Received: from cheetah.inter-linc.net (12.10.101.13) by master.inter-linc.net (Worldmail 1.3.167); 4 Feb 1998 09:37:02 -0600 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802041012.CAA02979@silvia.HIP.Berkeley.EDU> Date: Wed, 04 Feb 1998 09:17:45 -0600 (CST) From: Chris Dillon To: (Satoshi Asami) Subject: Re: May have pounced on something weird with ccd and newfs (rat Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" On 04-Feb-98 Satoshi Asami wrote: > * ccdconfig -c ccd0 $BLOCKSIZE 0 /dev/sd0s1g /dev/sd1s1g > * newfs -b 8192 -f 1024 ccd0c > * mount /dev/ccd0c /mnt > * bonnie -d /mnt -s 100 -m "I=$BLOCKSIZE" | grep "I=" >> ~/ccdtest.txt > * umount -f /dev/ccd0c (only did -f since weirdly enough, it would fail >sometimes) > * ccdconfig -u ccd0 > > * I=128 newfs -b 8192 -f 1024 fails with "write error: 2047871 > * wtfs: invalid argument". > > * "std" is the output when NOT using ccd (i.e., a regular disk). With > * a ccd stripe size of 128, newfs refused to create a filesystem with > * the error you see above. (I decided on using the 64 block stripe > * ultimately, by the way.) > >Could you have an old disklabel in there by any chance? See if the >size given in "disklabel ccd0" is consistent with "ccdconfig -g". > >Satoshi I'm not quite sure what you mean by "old" disklabel, but I started out fresh with these drives, and labeled them symmetrically with using ccd's in mind.. Here's the labels for sd0, sd1, and ccd0, and the output of ccdconfig -g. root@cheetah [/root] # disklabel sd0 # /dev/rsd0c: type: SCSI disk: sd0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 15 sectors/cylinder: 945 cylinders: 8960 sectors/unit: 8467200 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 102400 0 4.2BSD 0 0 0 # (Cyl. 0 - 108*) b: 153600 1536000 swap # (Cyl. 1625*- 1787*) c: 8467200 0 unused 0 0 # (Cyl. 0 - 8959) e: 1331200 102400 4.2BSD 0 0 0 # (Cyl. 108*- 1517*) f: 102400 1433600 4.2BSD 0 0 0 # (Cyl. 1517*- 1625*) g: 1024000 1689600 4.2BSD 0 0 0 # (Cyl. 1787*- 2871*) h: 5753600 2713600 4.2BSD 0 0 0 # (Cyl. 2871*- 8959*) root@cheetah [/root] # disklabel sd1 # /dev/rsd1c: type: SCSI disk: sd1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 15 sectors/cylinder: 945 cylinders: 8960 sectors/unit: 8467200 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 153600 1536000 swap # (Cyl. 1625*- 1787*) c: 8467200 0 unused 0 0 # (Cyl. 0 - 8959) e: 1331200 0 4.2BSD 0 0 0 # (Cyl. 0 - 1408*) f: 204800 1331200 4.2BSD 0 0 0 # (Cyl. 1408*- 1625*) g: 1024000 1689600 4.2BSD 0 0 0 # (Cyl. 1787*- 2871*) h: 5753600 2713600 4.2BSD 0 0 0 # (Cyl. 2871*- 8959*) root@cheetah [/root] # disklabel ccd0 # /dev/rccd0c: type: CCD disk: ccd label: default label flags: bytes/sector: 512 sectors/track: 2048 tracks/cylinder: 1 sectors/cylinder: 2048 cylinders: 999 sectors/unit: 2047872 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1023936 0 4.2BSD 1024 8192 0 # (Cyl. 0 - 499*) b: 1023936 1023936 4.2BSD 1024 8192 0 # (Cyl. 499*- 999*) c: 2047872 0 unused 0 0 # (Cyl. 0 - 999*) And the fstab... root@cheetah [/root] # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/sd0s1b none swap sw 0 0 /dev/sd1s1b none swap sw 0 0 /dev/sd0a / ufs rw 1 1 /dev/sd0s1e /release ufs rw 2 2 /dev/sd0s1f /tmp ufs rw 2 2 /dev/sd1s1e /extra ufs rw 2 2 /dev/sd1s1f /var ufs rw 2 2 /dev/ccd1c /usr ufs rw 2 2 /dev/ccd0a /devel ufs rw 2 2 /dev/ccd0b /usr/src ufs rw 2 2 proc /proc procfs rw 0 0 /dev/wcd0c /cdrom cd9660 ro,noauto 0 0 /dev/fd0 /dos/a msdos rw,noauto,noexec 0 0 /dev/wd0s1 /dos/c msdos rw,noauto,noexec 0 0 /dev/wd0s5 /dos/d msdos rw,noauto,noexec 0 0 /dev/sd2c /zip ufs rw,noauto,async 0 0 /dev/sd2s4 /dos/zip msdos rw,noauto,noexec 0 0 This may look pretty convoluted, but it was just an attempt at a way to waste all this new space I had acquired (and a vain attempt to put everything I could think of on separate filesystems) :-) Let me know if you need anything else to find out what causes this weirdness (or my stupidity). On an unrelated note, i've tried twiddling the Pass# layout in fstab since it seems like fsck is trying to check two filesystems on the same drive at the same time (lots of head movement, and it moves pretty fast checking clean filesystems, but not dirty ones), but putting them in what seemed to be an order that would prevent fsck from doing that didn't speed anything up, nor slow it down. I guess fsck is already smart enough to know what drives a ccd uses and not to check two things on them at the same time? --- Chris Dillon --- cdillon@inter-linc.net --- Powered by FreeBSD, the best operating system on the planet for Intel x86 based computers (and soon Sparcs). ---- (http://www.freebsd.org) From owner-freebsd-fs Wed Feb 4 07:58:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA07538 for freebsd-fs-outgoing; Wed, 4 Feb 1998 07:58:31 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from silvia.HIP.Berkeley.EDU (ala-ca36-04.ix.netcom.com [207.93.42.196]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA07532 for ; Wed, 4 Feb 1998 07:58:26 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id HAA04258; Wed, 4 Feb 1998 07:58:11 -0800 (PST) Date: Wed, 4 Feb 1998 07:58:11 -0800 (PST) Message-Id: <199802041558.HAA04258@silvia.HIP.Berkeley.EDU> To: cdillon@inter-linc.net CC: freebsd-fs@FreeBSD.ORG In-reply-to: (message from Chris Dillon on Wed, 04 Feb 1998 09:17:45 -0600 (CST)) Subject: Re: May have pounced on something weird with ccd and newfs (rat From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" * > * I=128 newfs -b 8192 -f 1024 fails with "write error: 2047871 * > * wtfs: invalid argument". * I'm not quite sure what you mean by "old" disklabel, but I started out fresh * with these drives, and labeled them symmetrically with using ccd's in mind.. What I meant is if you edit the disklabel on a ccd at a certain interleave, the label will "stick" when you later reconfigure the ccd with a different interleave (since the disklabel exists in the first sector of the first partition). Since the interleaves are increasing in your test order, it's possible that the last few blocks that the disklabel says exist may not exist. * Here's the labels for sd0, sd1, and ccd0, and the output of ccdconfig -g. You are missing the output of ccdconfig -g. I can't diagnose the problem without it. * root@cheetah [/root] # disklabel ccd0 * sectors/unit: 2047872 See the number above (the error from wtfs). It is second from the last block, which could be invalid at a 128 interleave. * 3 partitions: * # size offset fstype [fsize bsize bps/cpg] * a: 1023936 0 4.2BSD 1024 8192 0 # (Cyl. 0 - 499*) * b: 1023936 1023936 4.2BSD 1024 8192 0 # (Cyl. 499*- 999*) * c: 2047872 0 unused 0 0 # (Cyl. 0 - 999*) So you do have a disklabel. (The ccd driver will return a "default" label with only partition "c" and type "4.2BSD" if you don't write one yourself...that is often good enough, there usually is no point in sub-partitioning the ccd if you're combining disks is the first place. :) Satoshi From owner-freebsd-fs Wed Feb 4 09:00:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16569 for freebsd-fs-outgoing; Wed, 4 Feb 1998 09:00:34 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16526 for ; Wed, 4 Feb 1998 09:00:29 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA19913; Thu, 5 Feb 1998 03:58:05 +1100 Date: Thu, 5 Feb 1998 03:58:05 +1100 From: Bruce Evans Message-Id: <199802041658.DAA19913@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, cdillon@inter-linc.net Subject: Re: May have pounced on something weird with ccd and newfs (rat Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" >On an unrelated note, i've tried twiddling the Pass# layout in fstab since it >seems like fsck is trying to check two filesystems on the same drive at the same >time (lots of head movement, and it moves pretty fast checking clean >filesystems, but not dirty ones), but putting them in what seemed to be an order >that would prevent fsck from doing that didn't speed anything up, nor slow it >down. I guess fsck is already smart enough to know what drives a ccd uses and >not to check two things on them at the same time? It probably doesn't understand that sd0 and ccd0 may be (partly for ccd) on the same drive. It certainly doesn't understand that different slices on the same drive are on the same drive. The latter is usually not a problem because multiple real FreeBSD slices are not normally used (don't use both the compatibility slice and the corresponding real slice except possibly for using the former for the root file system and the latter for everything else). Bruce From owner-freebsd-fs Wed Feb 4 09:10:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18447 for freebsd-fs-outgoing; Wed, 4 Feb 1998 09:10:33 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18438 for ; Wed, 4 Feb 1998 09:10:30 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id EAA20278; Thu, 5 Feb 1998 04:09:04 +1100 Date: Thu, 5 Feb 1998 04:09:04 +1100 From: Bruce Evans Message-Id: <199802041709.EAA20278@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, cdillon@inter-linc.net Subject: Re: May have pounced on something weird with ccd and newfs (rat Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" > * 3 partitions: > * # size offset fstype [fsize bsize bps/cpg] > * a: 1023936 0 4.2BSD 1024 8192 0 # (Cyl. 0 - 499*) > * b: 1023936 1023936 4.2BSD 1024 8192 0 # (Cyl. 499*- 999*) > * c: 2047872 0 unused 0 0 # (Cyl. 0 - 999*) > >So you do have a disklabel. (The ccd driver will return a "default" >label with only partition "c" and type "4.2BSD" if you don't write one >yourself...that is often good enough, there usually is no point in >sub-partitioning the ccd if you're combining disks is the first >place. :) Except some things are different for the "c" partition. The label on it is easier to clobber, and some drivers, notably the ccd driver, don't check for EOF on it, so things only work right if the lower layers handle EOF correctly and consistently. Bruce From owner-freebsd-fs Thu Feb 5 05:31:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18552 for freebsd-fs-outgoing; Thu, 5 Feb 1998 05:31:52 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from master.inter-linc.net ([12.10.101.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18543 for ; Thu, 5 Feb 1998 05:31:50 -0800 (PST) (envelope-from cdillon@inter-linc.net) Received: from cheetah.inter-linc.net (12.10.101.13) by master.inter-linc.net (Worldmail 1.3.167); 5 Feb 1998 07:30:34 -0600 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802041558.HAA04258@silvia.HIP.Berkeley.EDU> Date: Thu, 05 Feb 1998 07:21:15 -0600 (CST) From: Chris Dillon To: (Satoshi Asami) Subject: Re: May have pounced on something weird with ccd and newfs (rat Cc: freebsd-fs@FreeBSD.ORG Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" On 04-Feb-98 Satoshi Asami wrote: > > * > * I=128 newfs -b 8192 -f 1024 fails with "write error: 2047871 > * > * wtfs: invalid argument". > > * I'm not quite sure what you mean by "old" disklabel, but I started out >fresh > * with these drives, and labeled them symmetrically with using ccd's in >mind.. > >What I meant is if you edit the disklabel on a ccd at a certain >interleave, the label will "stick" when you later reconfigure the ccd >with a different interleave (since the disklabel exists in the first >sector of the first partition). Aaaah, so maybe the best thing for me to do would have been to throw some zeros to the front of the partitions I was going to use for the ccd before I configured it? Or would it have been enough to throw some zeros onto the ccd *after* i configured it? >Since the interleaves are increasing in your test order, it's possible >that the last few blocks that the disklabel says exist may not exist. Makes sense, now. > * Here's the labels for sd0, sd1, and ccd0, and the output of ccdconfig -g. > >You are missing the output of ccdconfig -g. I can't diagnose the >problem without it. Whoops. I won't paste the rest of it since its back in this thread somewhere. :-) root@cheetah [/root] # ccdconfig -g ccd0 64 0 /dev/sd0s1g /dev/sd1s1g ccd1 64 0 /dev/sd0s1h /dev/sd1s1h > * root@cheetah [/root] # disklabel ccd0 > > * sectors/unit: 2047872 > >See the number above (the error from wtfs). It is second from the >last block, which could be invalid at a 128 interleave. > * 3 partitions: > * # size offset fstype [fsize bsize bps/cpg] > * a: 1023936 0 4.2BSD 1024 8192 0 # (Cyl. 0 - >499*) > * b: 1023936 1023936 4.2BSD 1024 8192 0 # (Cyl. 499*- >999*) > * c: 2047872 0 unused 0 0 # (Cyl. 0 - >999*) > >So you do have a disklabel. (The ccd driver will return a "default" >label with only partition "c" and type "4.2BSD" if you don't write one >yourself...that is often good enough, there usually is no point in >sub-partitioning the ccd if you're combining disks is the first >place. :) When I did the testing, i didn't label the ccd, i let it use the 'c' partition. However, i am now using two ccd's, one is using 'c', the other is split with 'a' and 'b'. This was more or less a learning thing for me, since I had never set up any ccd's before, and I wanted to see what kind of performance enhancement I would get from it. --- Chris Dillon --- cdillon@inter-linc.net --- Powered by FreeBSD, the best operating system on the planet for Intel x86 based computers (and soon Sparcs). ---- (http://www.freebsd.org) From owner-freebsd-fs Thu Feb 5 05:48:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20007 for freebsd-fs-outgoing; Thu, 5 Feb 1998 05:48:17 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from master.inter-linc.net ([12.10.101.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19999 for ; Thu, 5 Feb 1998 05:48:16 -0800 (PST) (envelope-from cdillon@inter-linc.net) Received: from cheetah.inter-linc.net (12.10.101.13) by master.inter-linc.net (Worldmail 1.3.167); 5 Feb 1998 07:46:55 -0600 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802041658.DAA19913@godzilla.zeta.org.au> Date: Thu, 05 Feb 1998 07:32:23 -0600 (CST) From: Chris Dillon To: Bruce Evans Subject: Re: May have pounced on something weird with ccd and newfs (rat Cc: freebsd-fs@FreeBSD.ORG, asami@cs.berkeley.edu Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" On 04-Feb-98 Bruce Evans wrote: >>On an unrelated note, i've tried twiddling the Pass# layout in fstab since it >>seems like fsck is trying to check two filesystems on the same drive at the >same >>time (lots of head movement, and it moves pretty fast checking clean >>filesystems, but not dirty ones), but putting them in what seemed to be an >order >>that would prevent fsck from doing that didn't speed anything up, nor slow it >>down. I guess fsck is already smart enough to know what drives a ccd uses >and >>not to check two things on them at the same time? > >It probably doesn't understand that sd0 and ccd0 may be (partly for ccd) >on the same drive. It certainly doesn't understand that different slices >on the same drive are on the same drive. The latter is usually not a >problem because multiple real FreeBSD slices are not normally used (don't >use both the compatibility slice and the corresponding real slice except >possibly for using the former for the root file system and the latter for >everything else). Hmm.. according to the fsck manual page, it first checks anything marked with a pass number of 1 first, but then checks everything else doing what it thinks is "one process per disk drive", based on the definition of a drive being "the longest prefix of the device name that ends in a digit; the remaining characters are assumed to be the partition designator." So apparently, no matter wether I set little numbered "groups" in fstab (assuming each group was checked sequentially), if any pass number is >1, fsck decides who and what gets checked in what order. While I was just now contemplating hacking fsck to do the numbered-group thing, i just realized I could give the ccd's a pass number of 1 so that they get checked by themselves, one at a time, and then give everything else a pass number of 2. :-) --- Chris Dillon --- cdillon@inter-linc.net --- Powered by FreeBSD, the best operating system on the planet for Intel x86 based computers (and soon Sparcs). ---- (http://www.freebsd.org) From owner-freebsd-fs Fri Feb 6 06:22:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17888 for freebsd-fs-outgoing; Fri, 6 Feb 1998 06:22:37 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.124.148]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17883 for ; Fri, 6 Feb 1998 06:22:35 -0800 (PST) (envelope-from kato@migmatite.eps.nagoya-u.ac.jp) Received: from localhost (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.8/3.6Wbeta7) with ESMTP id XAA03716 for ; Fri, 6 Feb 1998 23:05:28 +0900 (JST) To: freebsd-fs@FreeBSD.ORG Subject: umapfs PRs From: KATO Takenori X-Mailer: Mew version 1.92.4 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980206230528M.kato@gneiss.eps.nagoya-u.ac.jp> Date: Fri, 06 Feb 1998 23:05:28 +0900 X-Dispatcher: imput version 971024 Lines: 14 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" Someone maintains umapfs? I will commit patches in PR/5632 and PR/5640 to 3.0-current if no one objects. Also, I hope someone review the patch in PR/5634. I'm not 100% sure that vnode can be unlocked in umap_node_find(). ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-fs Fri Feb 6 13:37:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA05998 for freebsd-fs-outgoing; Fri, 6 Feb 1998 13:37:57 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA05986 for ; Fri, 6 Feb 1998 13:37:47 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id WAA06600 for freebsd-fs@FreeBSD.ORG; Fri, 6 Feb 1998 22:37:37 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id WAA00309; Fri, 6 Feb 1998 22:21:36 +0100 (CET) (envelope-from roberto) Message-ID: <19980206222135.12564@keltia.freenix.fr> Date: Fri, 6 Feb 1998 22:21:35 +0100 From: Ollivier Robert To: freebsd-fs@FreeBSD.ORG Subject: Re: umapfs PRs Mail-Followup-To: freebsd-fs@FreeBSD.ORG References: <19980206230528M.kato@gneiss.eps.nagoya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980206230528M.kato@gneiss.eps.nagoya-u.ac.jp>; from KATO Takenori on Fri, Feb 06, 1998 at 11:05:28PM +0900 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4049 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-fs" According to KATO Takenori: > I will commit patches in PR/5632 and PR/5640 to 3.0-current if no one > objects. Go for it. > Also, I hope someone review the patch in PR/5634. I'm not 100% sure > that vnode can be unlocked in umap_node_find(). I "ported" your patch into nullfs and that fixes the "locking against myself" problem I was constantly seeing. Now, running programs out of a nullfs is again broken (not your fault :-)). I get a panic from inside ffs_getpages (called through null_bypass) when it tries to get the first page of the executable. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #54: Mon Jan 26 20:29:17 CET 1998