| 1 | |
| 2 |
|
| 3 | ===================
|
| 4 | The QNX6 Filesystem
|
| 5 | ===================
|
| 6 |
|
| 7 | The qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino)
|
| 8 | It got introduced in QNX 6.4.0 and is used default since 6.4.1.
|
| 9 |
|
| 10 | Option
|
| 11 | ======
|
| 12 |
|
| 13 | mmi_fs Mount filesystem as used for example by Audi MMI 3G system
|
| 14 |
|
| 15 | Specification
|
| 16 | =============
|
| 17 |
|
| 18 | qnx6fs shares many properties with traditional Unix filesystems. It has the
|
| 19 | concepts of blocks, inodes and directories.
|
| 20 |
|
| 21 | On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
| 22 | This feature makes it possible to create and use a different endianness fs
|
| 23 | for the target (QNX is used on quite a range of embedded systems) platform
|
| 24 | running on a different endianness.
|
| 25 |
|
| 26 | The Linux driver handles endianness transparently. (LE and BE)
|
| 27 |
|
| 28 | Blocks
|
| 29 | ------
|
| 30 |
|
| 31 | The space in the device or file is split up into blocks. These are a fixed
|
| 32 | size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
|
| 33 | created.
|
| 34 |
|
| 35 | Blockpointers are 32bit, so the maximum space that can be addressed is
|
| 36 | 2^32 * 4096 bytes or 16TB
|
| 37 |
|
| 38 | The superblocks
|
| 39 | ---------------
|
| 40 |
|
| 41 | The superblock contains all global information about the filesystem.
|
| 42 | Each qnx6fs got two superblocks, each one having a 64bit serial number.
|
| 43 | That serial number is used to identify the "active" superblock.
|
| 44 | In write mode with reach new snapshot (after each synchronous write), the
|
| 45 | serial of the new master superblock is increased (old superblock serial + 1)
|
| 46 |
|
| 47 | So basically the snapshot functionality is realized by an atomic final
|
| 48 | update of the serial number. Before updating that serial, all modifications
|
| 49 | are done by copying all modified blocks during that specific write request
|
| 50 | (or period) and building up a new (stable) filesystem structure under the
|
| 51 | inactive superblock.
|
| 52 |
|
| 53 | Each superblock holds a set of root inodes for the different filesystem
|
| 54 | parts. (Inode, Bitmap and Longfilenames)
|
| 55 | Each of these root nodes holds information like total size of the stored
|
| 56 | data and the addressing levels in that specific tree.
|
| 57 | If the level value is 0, up to 16 direct blocks can be addressed by each
|
| 58 | node.
|
| 59 |
|
| 60 | Level 1 adds an additional indirect addressing level where each indirect
|
| 61 | addressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
| 62 | Level 2 adds an additional indirect addressing block level (so, already up
|
| 63 | to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree).
|
| 64 |
|
| 65 | Unused block pointers are always set to ~0 - regardless of root node,
|
| 66 | indirect addressing blocks or inodes.
|
| 67 |
|
| 68 | Data leaves are always on the lowest level. So no data is stored on upper
|
| 69 | tree levels.
|
| 70 |
|
| 71 | The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
|
| 72 | The Audi MMI 3G first superblock directly starts at byte 0.
|
| 73 |
|
| 74 | Second superblock position can either be calculated from the superblock
|
| 75 | information (total number of filesystem blocks) or by taking the highest
|
| 76 | device address, zeroing the last 3 bytes and then subtracting 0x1000 from
|
| 77 | that address.
|
| 78 |
|
| 79 | 0x1000 is the size reserved for each superblock - regardless of the
|
| 80 | blocksize of the filesystem.
|
| 81 |
|
| 82 | Inodes
|
| 83 | ------
|
| 84 |
|
| 85 | Each object in the filesystem is represented by an inode. (index node)
|
| 86 | The inode structure contains pointers to the filesystem blocks which contain
|
| 87 | the data held in the object and all of the metadata about an object except
|
| 88 | its longname. (filenames longer than 27 characters)
|
| 89 | The metadata about an object includes the permissions, owner, group, flags,
|
| 90 | size, number of blocks used, access time, change time and modification time.
|
| 91 |
|
| 92 | Object mode field is POSIX format. (which makes things easier)
|
| 93 |
|
| 94 | There are also pointers to the first 16 blocks, if the object data can be
|
| 95 | addressed with 16 direct blocks.
|
| 96 |
|
| 97 | For more than 16 blocks an indirect addressing in form of another tree is
|
| 98 | used. (scheme is the same as the one used for the superblock root nodes)
|
| 99 |
|
| 100 | The filesize is stored 64bit. Inode counting starts with 1. (while long
|
| 101 | filename inodes start with 0)
|
| 102 |
|
| 103 | Directories
|
| 104 | -----------
|
| 105 |
|
| 106 | A directory is a filesystem object and has an inode just like a file.
|
| 107 | It is a specially formatted file containing records which associate each
|
| 108 | name with an inode number.
|
| 109 |
|
| 110 | '.' inode number points to the directory inode
|
| 111 |
|
| 112 | '..' inode number points to the parent directory inode
|
| 113 |
|
| 114 | Eeach filename record additionally got a filename length field.
|
| 115 |
|
| 116 | One special case are long filenames or subdirectory names.
|
| 117 |
|
| 118 | These got set a filename length field of 0xff in the corresponding directory
|
| 119 | record plus the longfile inode number also stored in that record.
|
| 120 |
|
| 121 | With that longfilename inode number, the longfilename tree can be walked
|
| 122 | starting with the superblock longfilename root node pointers.
|
| 123 |
|
| 124 | Special files
|
| 125 | -------------
|
| 126 |
|
| 127 | Symbolic links are also filesystem objects with inodes. They got a specific
|
| 128 | bit in the inode mode field identifying them as symbolic link.
|
| 129 |
|
| 130 | The directory entry file inode pointer points to the target file inode.
|
| 131 |
|
| 132 | Hard links got an inode, a directory entry, but a specific mode bit set,
|
| 133 | no block pointers and the directory file record pointing to the target file
|
| 134 | inode.
|
| 135 |
|
| 136 | Character and block special devices do not exist in QNX as those files
|
| 137 | are handled by the QNX kernel/drivers and created in /dev independent of the
|
| 138 | underlying filesystem.
|
| 139 |
|
| 140 | Long filenames
|
| 141 | --------------
|
| 142 |
|
| 143 | Long filenames are stored in a separate addressing tree. The staring point
|
| 144 | is the longfilename root node in the active superblock.
|
| 145 |
|
| 146 | Each data block (tree leaves) holds one long filename. That filename is
|
| 147 | limited to 510 bytes. The first two starting bytes are used as length field
|
| 148 | for the actual filename.
|
| 149 |
|
| 150 | If that structure shall fit for all allowed blocksizes, it is clear why there
|
| 151 | is a limit of 510 bytes for the actual filename stored.
|
| 152 |
|
| 153 | Bitmap
|
| 154 | ------
|
| 155 |
|
| 156 | The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
|
| 157 | root node in the superblock and each bit in the bitmap represents one
|
| 158 | filesystem block.
|
| 159 |
|
| 160 | The first block is block 0, which starts 0x1000 after superblock start.
|
| 161 | So for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical
|
| 162 | address at which block 0 is located.
|
| 163 |
|
| 164 | Bits at the end of the last bitmap block are set to 1, if the device is
|
| 165 | smaller than addressing space in the bitmap.
|
| 166 |
|
| 167 | Bitmap system area
|
| 168 | ------------------
|
| 169 |
|
| 170 | The bitmap itself is divided into three parts.
|
| 171 |
|
| 172 | First the system area, that is split into two halves.
|
| 173 |
|
| 174 | Then userspace.
|
| 175 |
|
| 176 | The requirement for a static, fixed preallocated system area comes from how
|
| 177 | qnx6fs deals with writes.
|
| 178 |
|
| 179 | Each superblock got its own half of the system area. So superblock #1
|
| 180 | always uses blocks from the lower half while superblock #2 just writes to
|
| 181 | blocks represented by the upper half bitmap system area bits.
|
| 182 |
|
| 183 | Bitmap blocks, Inode blocks and indirect addressing blocks for those two
|
| 184 | tree structures are treated as system blocks.
|
| 185 |
|
| 186 | The rational behind that is that a write request can work on a new snapshot
|
| 187 | (system area of the inactive - resp. lower serial numbered superblock) while
|
| 188 | at the same time there is still a complete stable filesystem structure in the
|
| 189 | other half of the system area.
|
| 190 |
|
| 191 | When finished with writing (a sync write is completed, the maximum sync leap
|
| 192 | time or a filesystem sync is requested), serial of the previously inactive
|
| 193 | superblock atomically is increased and the fs switches over to that - then
|
| 194 | stable declared - superblock.
|
| 195 |
|
| 196 | For all data outside the system area, blocks are just copied while writing.
|