Second extended file system (ext2fs) and MS-DOS file system support for Lites ----------------------------------------------- This file describes briefly how support for these two file systems was implemented in Lites. It also provides some hints for users and developers. + EXT2FS Support ---------------------------------------------------------------------------- The ext2fs support is embedded in the ufs framework, and it is based on the ffs implementation. The rationale for this is that ffs and ext2fs are very similar filesystems - both use groups, multilevel indexing, a similar on-disk inode format and almost identical directory formats. The main differences are that ext2fs uses smaller blocksizes and doesn't support fragments. There are minor differences in the directory format. Furthermore, the allocation policies differ. Ext2fs's policy is mainly extent-based, aiming for contiguous allocation, whereas ffs' policy takes various disk parameters into account to aid its strategy. A first approach to use the Linux code base and provide it with glue code so that it could use Lites' buffer cache and could be used by Lites' VFS layer failed. The reasons are threefold: first, the buffer cache interfaces are different, second, the amount of glue code for the vfs layer would have been rather large, and finally it would have been necessary to guarantee all the implicit assumptions the ext2fs code makes about the Linux kernel. Therefore, I decided to start with the ffs code. The translation was then straightforward. The differences in the DIRECTORY FORMAT required a customized readdir routine, plus customized routines to enter or remove directory entries. Since those routines are not part of the VFS abstract interface, the ufs code dynamically checks the type of the vnode and calls the appropriate function. A second difference is that ext2fs and ffs have different notions of a basic unit in a directory (DIRBLKSIZ). These two changes were the only changes the ufs code suffered; the alternative would have been to clone large parts of the code. Linux's ALLOCATION POLICIES are enforced. This includes preferences of where to allocate blocks and inodes as well as the preallocation of up to eight contiguous blocks that help lay out ext2fs files contiguously under contention. The allocation code was the only code that came from the Linux source. At this point, it includes some i386 specific asm macros which were also taken from Linux. PORTING EXT2FS TO OTHER *BSD FLAVOURS: from what was said above it should be clear that it should be sufficient to trace the changes the ufs and ffs code experienced and apply them to the ufs/ext2fs code. (IMHO, it's a pity that there is this jungle of different versions of ufs in the different *BSD flavours.) Anyone who wants to do that is requested to #ifdef LITES the changes he/she makes, and provide us with the changed version. (This is my personal effort to reunite the BSDs - where it makes sense. I know it's poised to fail). SUPPORT BINARIES FOR EXT2FS: I aided Ted Ts'o in porting his e2fsprog package to *BSD. The next release 0.5c will run on NetBSD and FreeBSD systems. A prelease (as of 8/17/95) can be obtained from: ftp://tsx-11.mit.edu:/pub/linux/ALPHA/ext2fs/e2fsprogs-0.5c-WIP.tar.gz UNIMPLEMENTED FEATURES: - The LINUX SPECIFIC mount options such as resuid/resgid have not been implemented. - VFS cluster_read is enabled, cluster_write doesn't work stable and is disabled. Reallocblks is also not implemented. Due to the small block size and the Lites implementation of pagemove, write clustering actually reduces performance. ---------------------------------------------------------------------------- + MSDOSFS support: The msdosfs support was taken almost AS IS from the FreeBSD 2.0.5-snapshot 7/26/95. Only minor changes were needed, and these could be incorporated in a single header file. In addition, FreeBSD extensions not present in Lites had to be commented out (such as NFS cookies in readdir) Jordan K. Hubbard cautioned that it doesn't run stable in read-write mode in FreeBSD. He mentioned that "dd if=/dev/zero of=" would reproduce the failure. (The disklabel gets supposedly overwritten, causing what he referred to as partition pizza.) He uses a big DOS partition (>700 MB). Even though I was not able to reproduce this failure on my small DOS partition, please be aware that you're using this software at your risk. Since the changes to the code are really minor, the problem is likely to occur in Lites as well, provided it doesn't lie elsewhere. ---------------------------------------------------------------------------- If you have any comments/questions, please send mail to gback@cs.utah.edu. I sincerely appreciate any feedback. Godmar Back University of Utah, CSL August 29, 1995