From owner-freebsd-fs Thu Mar 5 14:15:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28708 for freebsd-fs-outgoing; Thu, 5 Mar 1998 14:15:55 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.31.78.80]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28703 for ; Thu, 5 Mar 1998 14:15:53 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA25069; Thu, 5 Mar 1998 17:14:25 -0500 (EST) Date: Thu, 5 Mar 1998 17:14:24 -0500 (EST) From: "Matthew N. Dodd" To: Eivind Eklund cc: fs@FreeBSD.ORG Subject: Re: [bouyer@antioche.lip6.fr: bi-endian ffs available] In-Reply-To: <19980305180512.15607@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 On Thu, 5 Mar 1998, Eivind Eklund wrote: > Should we adopt this? Yes -PLEASE- > ----- Forwarded message from Manuel Bouyer ----- > Message-ID: <19980304173610.09180@antioche.lip6.fr> > Date: Wed, 4 Mar 1998 17:36:10 +0100 > From: Manuel Bouyer > To: tech-kern@NetBSD.ORG > Subject: bi-endian ffs available > > > Hi, > I've made big progress in getting ffs read both big and little endian > file systems. A preliminary (but working :) version is available > at ftp.netbsd.org:/pub/incoming/bouyer/ffs_endian.diff.gz. > > Features are: > kernel can mount read/write both big and little endian ffs. The selection > is made on the superblock magic order at mount time. > > fsck_ffs can work on both endian, and will convert from one to another > if the '-s' flag is given. However, the filesystem will be unrecoverable if > fsck is stopped before the end of the convertion for some reason. > I really don't know how to be safer here. Once fsck starts rewrinting the > fielsystem metadatas, there is no way to know where it stopped. > > Other filsystem utilities (badsect, clri, dump, fsdb, fsirand, newfs, tunefs, > dumpfs, quotacheck - let me know if I missed some !) will work on both > byte order. newfs will be able create both byte order ffs (not done yet, > but will be soon). > Quotacheck will be able to work on any byte order, but the quota file will > always be used in host byte order - if you move a disk with user quotas, > you will have to rerun quotacheck on it. If peoples feels it's a too strong > limitation, I can have a look at this too. My understanding of things are > that such situations should be exceptional. I can't see the use of quotas > on removable medias. > > On the kernel side, I added a 'int um_flags' to struct ufsmount. > For now it can only take one value - UFS_NEEDSWAP. This flags is checked > at various place in the kernel when reading/writing metadatas. > As inodes and the superblocks have a in-memory copy, they are converted > in whole at read/write time (exept the blocks addresses in the inode). > The blocks adresses (in inode or indirect blocks), cylinder groups and the > directory infos are converted at use time, as the in-memory copy is > the disk buffer itself. Things could maybe be improved here by adding a > cylinder group cache, as does linux, but this needs further studies. > > I plan to commit this next friday, unless I get negative comments sine then. > > -- > Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr > -- > ----- End forwarded message ----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message