From owner-freebsd-fs Thu Mar 5 09:05:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09680 for freebsd-fs-outgoing; Thu, 5 Mar 1998 09:05:19 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09642 for ; Thu, 5 Mar 1998 09:05:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id RAA20669 for ; Thu, 5 Mar 1998 17:05:12 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id SAA02276; Thu, 5 Mar 1998 18:05:12 +0100 (MET) Message-ID: <19980305180512.15607@follo.net> Date: Thu, 5 Mar 1998 18:05:12 +0100 From: Eivind Eklund To: fs@FreeBSD.ORG Subject: [bouyer@antioche.lip6.fr: bi-endian ffs available] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Should we adopt this? ----- 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