From owner-freebsd-current Thu Mar 12 18:38:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA28479 for freebsd-current-outgoing; Thu, 12 Mar 1998 18:38:55 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28474 for ; Thu, 12 Mar 1998 18:38:50 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id CAA15111; Fri, 13 Mar 1998 02:37:56 GMT Date: Fri, 13 Mar 1998 11:37:56 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Eivind Eklund , adkin003@tc.umn.edu, current@FreeBSD.ORG Subject: Re: ext2_sync and NULL inode and VNON v_type In-Reply-To: <199803121941.MAA10146@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 12 Mar 1998, Terry Lambert wrote: > > AFAIK, it worked fine before the soft-updates integration. After the > > soft-updates integration it didn't even _compile_. I fixed this - it > > took three lines of changes, which I snarfed from FFS - but I haven't > > done any testing etc, and it wouldn't surprise me if there are other, > > more insidious problems from the integration. I just needed it to > > compile so it wouldn't block LINT. > > I'm curious, but not enough to drive home during lunch. What did > you have to change? There was not supposed to be an impact. There's a lot of code shared with ext2fs. There are #ifdef EXT2FS's all over the ffs code. There are also ext2fs only modules that are very similar to their ffs counterparts, but slightly different. A good example is ext2_fsync, this one was not lite2ified. The ufs directory code could have been used in it's entirety if it weren't for some small gratutious changes in the ext2 on-disk directory format. The other main differences include a different block allocation scheme and no fragment support. They use block groups, which take the ffs cylinder group wins without the geometry based code. Other than that they look very much the same. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message