- It implements all of
Xenix FS,
SystemV/386 FS,
Coherent FS.
To install:
Answer the ‘System V and Coherent filesystem support’ question with ‘y’when configuring the kernel.
To mount a disk or a partition, use:
mount [-r] -t sysv device mountpoint
The file system type names:
-t sysv-t xenix-t coherent
may be used interchangeably, but the last two will eventually disappear.
Bugs in the present implementation:
Coherent FS:
The “free list interleave” n:m is currently ignored.
Only file systems with no filesystem name and no pack name are recognized.(See Coherent “man mkfs” for a description of these features.)
SystemV Release 2 FS:
The superblock is only searched in the blocks 9, 15, 18, whichcorresponds to the beginning of track 1 on floppy disks. No supportfor this FS on hard disk yet.
These filesystems are rather similar. Here is a comparison with Minix FS:
Linux fdisk reports on partitions
Minix FS 0x81 Linux/Minix
Xenix FS ??
SystemV FS ??
Coherent FS 0x08 AIX bootable
Size of a block or zone (data allocation unit on disk)
Minix FS 1024
Xenix FS 1024 (also 512 ??)
SystemV FS 1024 (also 512 and 2048)
Coherent FS 512
General layout: all have one boot block, one super block andseparate areas for inodes and for directories/data.On SystemV Release 2 FS (e.g. Microport) the first track is reserved andall the block numbers (including the super block) are offset by one track.
Byte ordering of “short” (16 bit entities) on disk:
Minix FS little endian 0 1
Xenix FS little endian 0 1
SystemV FS little endian 0 1
Coherent FS little endian 0 1
Of course, this affects only the file system, not the data of files on it!
Byte ordering of “long” (32 bit entities) on disk:
Minix FS little endian 0 1 2 3
Xenix FS little endian 0 1 2 3
SystemV FS little endian 0 1 2 3
Coherent FS PDP-11 2 3 0 1
Of course, this affects only the file system, not the data of files on it!
Inode on disk: “short”, 0 means non-existent, the root dir ino is:
Minix FS
1
Xenix FS, SystemV FS, Coherent FS
2
Maximum number of hard links to a file:
Minix FS
250
Xenix FS
??
SystemV FS
??
Coherent FS
>=10000
Free inode management:
- Minix FS
a bitmap
- Xenix FS, SystemV FS, Coherent FS
There is a cache of a certain number of free inodes in the super-block.When it is exhausted, new free inodes are found using a linear search.
Free block management:
- Minix FS
a bitmap
- Xenix FS, SystemV FS, Coherent FS
Free blocks are organized in a “free list”. Maybe a misleading term,since it is not true that every free block contains a pointer tothe next free block. Rather, the free blocks are organized in chunksof limited size, and every now and then a free block contains pointersto the free blocks pertaining to the next chunk; the first of thesecontains pointers and so on. The list terminates with a “block number”0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS.
Super-block location:
Minix FS
block 1 = bytes 1024..2047
Xenix FS
block 1 = bytes 1024..2047
SystemV FS
bytes 512..1023
Coherent FS
block 1 = bytes 512..1023
Super-block layout:
Minix FS:
unsigned short s_ninodes;unsigned short s_nzones;unsigned short s_imap_blocks;unsigned short s_zmap_blocks;unsigned short s_firstdatazone;unsigned short s_log_zone_size;unsigned long s_max_size;unsigned short s_magic;
Xenix FS, SystemV FS, Coherent FS:
unsigned short s_firstdatazone;unsigned long s_nzones;unsigned short s_fzone_count;unsigned long s_fzones[NICFREE];unsigned short s_finode_count;unsigned short s_finodes[NICINOD];char s_flock;char s_ilock;char s_modified;char s_rdonly;unsigned long s_time;short s_dinfo[4]; -- SystemV FS onlyunsigned long s_free_zones;unsigned short s_free_inodes;short s_dinfo[4]; -- Xenix FS onlyunsigned short s_interleave_m,s_interleave_n; -- Coherent FS onlychar s_fname[6];char s_fpack[6];
then they differ considerably:
Xenix FS:
char s_clean;char s_fill[371];long s_magic;long s_type;
SystemV FS:
long s_fill[12 or 14];long s_state;long s_magic;long s_type;
Coherent FS:
unsigned long s_unique;
Note that Coherent FS has no magic.
Inode layout:
Minix FS:
unsigned short i_mode;unsigned short i_uid;unsigned long i_size;unsigned long i_time;unsigned char i_gid;unsigned char i_nlinks;unsigned short i_zone[7+1+1];
Xenix FS, SystemV FS, Coherent FS:
unsigned short i_mode;unsigned short i_nlink;unsigned short i_uid;unsigned short i_gid;unsigned long i_size;unsigned char i_zone[3*(10+1+1+1)];unsigned long i_atime;unsigned long i_mtime;unsigned long i_ctime;
Regular file data blocks are organized as
Minix FS:
7 direct blocks
1 indirect block (pointers to blocks)
1 double-indirect block (pointer to pointers to blocks)
Xenix FS, SystemV FS, Coherent FS:
10 direct blocks
1 indirect block (pointers to blocks)
1 double-indirect block (pointer to pointers to blocks)
1 triple-indirect block (pointer to pointers to pointers to blocks)
Minix FS
32
32
Xenix FS
64
16
SystemV FS
64
16
Coherent FS
64
8
Directory entry on disk
Minix FS:
unsigned short inode;char name[14/30];
Xenix FS, SystemV FS, Coherent FS:
unsigned short inode;char name[14];
Minix FS
16/32
64/32
Xenix FS
16
64
SystemV FS
16
64
Coherent FS
16
32
How to implement symbolic links such that the host fsck doesn’t scream:
Minix FS normal
Xenix FS kludge: as regular files with chmod 1000
SystemV FS ??
Coherent FS kludge: as regular files with chmod 1000
Notation: We often speak of a “block” but mean a zone (the allocation unit)and not the disk driver’s notion of “block”.
