Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 | This is the implementation of the SystemV/Coherent filesystem for Linux. It grew out of separate filesystem implementations Xenix FS Doug Evans <dje@cygnus.com> June 1992 SystemV FS Paul B. Monday <pmonday@eecs.wsu.edu> March-June 1993 Coherent FS B. Haible <haible@ma2s2.mathematik.uni-karlsruhe.de> June 1993 and was merged together in July 1993. 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) - Coherent FS 512 * General layout: all have one boot block, one super block and separate areas for inodes and for directories/data. On SystemV Release 2 FS (e.g. Microport) the first track is reserved and all 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 to the next free block. Rather, the free blocks are organized in chunks of limited size, and every now and then a free block contains pointers to the free blocks pertaining to the next chunk; the first of these contains 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 only unsigned long s_free_zones; unsigned short s_free_inodes; short s_dinfo[4]; -- Xenix FS only unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only char 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) * Inode size, inodes per block - 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]; * Dir entry size, dir entries per block - 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". Because the block size may be smaller than 1024 (which is the unit used by the disk drivers and the buffer code), many functions must return a pointer to the buffer data additionally to the buffer head pointer. One must not assume that the entire buffer is occupied by this single block. This makes the implementation of truncate() difficult. Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de> |