![]() |
|
| Daemon News Ezine | BSD News | BSD Mall | BSD Support Forum | BSD Advocacy | BSD Updates |
Ext2fs rev 1 changes in NetBSDHubert Feyrer, Manuel Bouyer; April 2000Manuel Bouyer has made changes to the NetBSD ext2fs to include changes for revision 1 of the Linux Extended2 filesystem. Here's an introduction to what ext2fs is, and an overview of the first revision's changes.
Why so many filesystems?Running on a broad range of hardware platforms not only means being able to talk to the hardware. Often it's necessary to access programs and files installed on machines prior to the transition to another operating system, or even after. While changing to (or even playing with) another operating system, copying all data over to the new filesystem format is often not an option. And even if so, some method of accessing data is required. Given that systems may have their own filesystem format to store data in their "native" format, accessability via an appropriate filesystem is required to get to the data. It is the filesystem's responsibility to understand the layout of the data on the disk, and to make it accessible for reading and writing. Besides native filesystems like FFS and LFS, NetBSD comes with a wide range of file systems, which ensure it can read and/or write disks containing data in the following filesystems:
The filesystem used natively in NetBSD is the Berkeley FFS. The name was changed from Unix File System (UFS) to avoid the trademarked term "Unix". See [1] for more information on the Berkeley FFS. There are some changes to the ext2fs code used in NetBSD, and we'll talk about that here. After a general overview of ext2fs, we'll outline the changes made in ext2fs revision 1.
What is ext2fs?The Second Extended Filesystem (ext2fs) is used as the Linux operating system's native filesystem format today. Ext2fs is based on the Minix filesystem, and several improvements were made to make it fit today's data storage requirements, using semantics and concepts found then (and today) in the traditional Berkeley based Fast Filesystem (FFS). Besides implementing standard FFS features like symbolic links, long filenames and variable blocksize, extfs also includes other changes like bitfields for extensions in new revisions and a filesystem "clean" flag to avoid the filesystem check on reboot. Please refer to [2] for more details on ext2fs.
Changes in ext2fs rev. 1Ext2fs rev 1 has bitfields in the superblock indicating which features the ext2fs has. They are categorized in three classes: 'compat' are features which can be ignored by kernels which don't support it; 'rocompat' are features which can be ignored by kernels which don't support them if the filesystem is mounted read-only; and 'incompat' are features which prevent the filesystem from being mounted at all if the kernel doesn't support one of them. As of linux-2.2.14 the only 'compat' feature defined so far is 'prealloc', which affects the way blocks are pre-alloctated on write; No support for this optimisation is present in NetBSD so far. Three 'rocompat' features are defined:
Linux-2.2.14 supports sparse_super and largefile; NetBSD only supports 'sparse_super' (lacking access to 64bit linux systems, it's not known if linux-2.2.14 completely supports largefile, and mke2fs 1.18 doesn't support it either, at least it's not documented in the man page). Two 'incompat' features are defined:
As of linux-2.2.14/e2fsprogs 1.18 only 'filetype' is supported; NetBSD supports it as well.
A bit of historyThe NetBSD ext2fs started with a 'cp -r ffs ext2fs' and then (after renaming all functions/defines) adapting this to ext2fs: no fragments, different block allocation policy, minor changes in inodes and directory formats (ext2fs is really close to ffs), byte swapping on big-endian systems. At this time the 'file type in directory entries' code was deleted. Three years later it was added back. By using this approach, it was possible to get a completely GPL-free ext2fs implementation which fits the NetBSD requirement to keep GPL'ed code out of the kernel.
References
|