1d5eefa2cSMauro Carvalho Chehab.. SPDX-License-Identifier: GPL-2.0 2d5eefa2cSMauro Carvalho Chehab 3d5eefa2cSMauro Carvalho Chehab=================== 4d5eefa2cSMauro Carvalho ChehabThe QNX6 Filesystem 5d5eefa2cSMauro Carvalho Chehab=================== 6d5eefa2cSMauro Carvalho Chehab 7d5eefa2cSMauro Carvalho ChehabThe qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino) 8d5eefa2cSMauro Carvalho ChehabIt got introduced in QNX 6.4.0 and is used default since 6.4.1. 9d5eefa2cSMauro Carvalho Chehab 10d5eefa2cSMauro Carvalho ChehabOption 11d5eefa2cSMauro Carvalho Chehab====== 12d5eefa2cSMauro Carvalho Chehab 13d5eefa2cSMauro Carvalho Chehabmmi_fs Mount filesystem as used for example by Audi MMI 3G system 14d5eefa2cSMauro Carvalho Chehab 15d5eefa2cSMauro Carvalho ChehabSpecification 16d5eefa2cSMauro Carvalho Chehab============= 17d5eefa2cSMauro Carvalho Chehab 18d5eefa2cSMauro Carvalho Chehabqnx6fs shares many properties with traditional Unix filesystems. It has the 19d5eefa2cSMauro Carvalho Chehabconcepts of blocks, inodes and directories. 20d5eefa2cSMauro Carvalho Chehab 21d5eefa2cSMauro Carvalho ChehabOn QNX it is possible to create little endian and big endian qnx6 filesystems. 22d5eefa2cSMauro Carvalho ChehabThis feature makes it possible to create and use a different endianness fs 23d5eefa2cSMauro Carvalho Chehabfor the target (QNX is used on quite a range of embedded systems) platform 24d5eefa2cSMauro Carvalho Chehabrunning on a different endianness. 25d5eefa2cSMauro Carvalho Chehab 26d5eefa2cSMauro Carvalho ChehabThe Linux driver handles endianness transparently. (LE and BE) 27d5eefa2cSMauro Carvalho Chehab 28d5eefa2cSMauro Carvalho ChehabBlocks 29d5eefa2cSMauro Carvalho Chehab------ 30d5eefa2cSMauro Carvalho Chehab 31d5eefa2cSMauro Carvalho ChehabThe space in the device or file is split up into blocks. These are a fixed 32d5eefa2cSMauro Carvalho Chehabsize of 512, 1024, 2048 or 4096, which is decided when the filesystem is 33d5eefa2cSMauro Carvalho Chehabcreated. 34d5eefa2cSMauro Carvalho Chehab 35d5eefa2cSMauro Carvalho ChehabBlockpointers are 32bit, so the maximum space that can be addressed is 36d5eefa2cSMauro Carvalho Chehab2^32 * 4096 bytes or 16TB 37d5eefa2cSMauro Carvalho Chehab 38d5eefa2cSMauro Carvalho ChehabThe superblocks 39d5eefa2cSMauro Carvalho Chehab--------------- 40d5eefa2cSMauro Carvalho Chehab 41d5eefa2cSMauro Carvalho ChehabThe superblock contains all global information about the filesystem. 42d5eefa2cSMauro Carvalho ChehabEach qnx6fs got two superblocks, each one having a 64bit serial number. 43d5eefa2cSMauro Carvalho ChehabThat serial number is used to identify the "active" superblock. 44d5eefa2cSMauro Carvalho ChehabIn write mode with reach new snapshot (after each synchronous write), the 45d5eefa2cSMauro Carvalho Chehabserial of the new master superblock is increased (old superblock serial + 1) 46d5eefa2cSMauro Carvalho Chehab 47d5eefa2cSMauro Carvalho ChehabSo basically the snapshot functionality is realized by an atomic final 48d5eefa2cSMauro Carvalho Chehabupdate of the serial number. Before updating that serial, all modifications 49d5eefa2cSMauro Carvalho Chehabare done by copying all modified blocks during that specific write request 50d5eefa2cSMauro Carvalho Chehab(or period) and building up a new (stable) filesystem structure under the 51d5eefa2cSMauro Carvalho Chehabinactive superblock. 52d5eefa2cSMauro Carvalho Chehab 53d5eefa2cSMauro Carvalho ChehabEach superblock holds a set of root inodes for the different filesystem 54d5eefa2cSMauro Carvalho Chehabparts. (Inode, Bitmap and Longfilenames) 55d5eefa2cSMauro Carvalho ChehabEach of these root nodes holds information like total size of the stored 56d5eefa2cSMauro Carvalho Chehabdata and the addressing levels in that specific tree. 57d5eefa2cSMauro Carvalho ChehabIf the level value is 0, up to 16 direct blocks can be addressed by each 58d5eefa2cSMauro Carvalho Chehabnode. 59d5eefa2cSMauro Carvalho Chehab 60d5eefa2cSMauro Carvalho ChehabLevel 1 adds an additional indirect addressing level where each indirect 61d5eefa2cSMauro Carvalho Chehabaddressing block holds up to blocksize / 4 bytes pointers to data blocks. 62d5eefa2cSMauro Carvalho ChehabLevel 2 adds an additional indirect addressing block level (so, already up 63d5eefa2cSMauro Carvalho Chehabto 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree). 64d5eefa2cSMauro Carvalho Chehab 65d5eefa2cSMauro Carvalho ChehabUnused block pointers are always set to ~0 - regardless of root node, 66d5eefa2cSMauro Carvalho Chehabindirect addressing blocks or inodes. 67d5eefa2cSMauro Carvalho Chehab 68d5eefa2cSMauro Carvalho ChehabData leaves are always on the lowest level. So no data is stored on upper 69d5eefa2cSMauro Carvalho Chehabtree levels. 70d5eefa2cSMauro Carvalho Chehab 71d5eefa2cSMauro Carvalho ChehabThe first Superblock is located at 0x2000. (0x2000 is the bootblock size) 72d5eefa2cSMauro Carvalho ChehabThe Audi MMI 3G first superblock directly starts at byte 0. 73d5eefa2cSMauro Carvalho Chehab 74d5eefa2cSMauro Carvalho ChehabSecond superblock position can either be calculated from the superblock 75d5eefa2cSMauro Carvalho Chehabinformation (total number of filesystem blocks) or by taking the highest 76d5eefa2cSMauro Carvalho Chehabdevice address, zeroing the last 3 bytes and then subtracting 0x1000 from 77d5eefa2cSMauro Carvalho Chehabthat address. 78d5eefa2cSMauro Carvalho Chehab 79d5eefa2cSMauro Carvalho Chehab0x1000 is the size reserved for each superblock - regardless of the 80d5eefa2cSMauro Carvalho Chehabblocksize of the filesystem. 81d5eefa2cSMauro Carvalho Chehab 82d5eefa2cSMauro Carvalho ChehabInodes 83d5eefa2cSMauro Carvalho Chehab------ 84d5eefa2cSMauro Carvalho Chehab 85d5eefa2cSMauro Carvalho ChehabEach object in the filesystem is represented by an inode. (index node) 86d5eefa2cSMauro Carvalho ChehabThe inode structure contains pointers to the filesystem blocks which contain 87d5eefa2cSMauro Carvalho Chehabthe data held in the object and all of the metadata about an object except 88d5eefa2cSMauro Carvalho Chehabits longname. (filenames longer than 27 characters) 89d5eefa2cSMauro Carvalho ChehabThe metadata about an object includes the permissions, owner, group, flags, 90d5eefa2cSMauro Carvalho Chehabsize, number of blocks used, access time, change time and modification time. 91d5eefa2cSMauro Carvalho Chehab 92d5eefa2cSMauro Carvalho ChehabObject mode field is POSIX format. (which makes things easier) 93d5eefa2cSMauro Carvalho Chehab 94d5eefa2cSMauro Carvalho ChehabThere are also pointers to the first 16 blocks, if the object data can be 95d5eefa2cSMauro Carvalho Chehabaddressed with 16 direct blocks. 96d5eefa2cSMauro Carvalho Chehab 97d5eefa2cSMauro Carvalho ChehabFor more than 16 blocks an indirect addressing in form of another tree is 98d5eefa2cSMauro Carvalho Chehabused. (scheme is the same as the one used for the superblock root nodes) 99d5eefa2cSMauro Carvalho Chehab 100d5eefa2cSMauro Carvalho ChehabThe filesize is stored 64bit. Inode counting starts with 1. (while long 101d5eefa2cSMauro Carvalho Chehabfilename inodes start with 0) 102d5eefa2cSMauro Carvalho Chehab 103d5eefa2cSMauro Carvalho ChehabDirectories 104d5eefa2cSMauro Carvalho Chehab----------- 105d5eefa2cSMauro Carvalho Chehab 106d5eefa2cSMauro Carvalho ChehabA directory is a filesystem object and has an inode just like a file. 107d5eefa2cSMauro Carvalho ChehabIt is a specially formatted file containing records which associate each 108d5eefa2cSMauro Carvalho Chehabname with an inode number. 109d5eefa2cSMauro Carvalho Chehab 110d5eefa2cSMauro Carvalho Chehab'.' inode number points to the directory inode 111d5eefa2cSMauro Carvalho Chehab 112d5eefa2cSMauro Carvalho Chehab'..' inode number points to the parent directory inode 113d5eefa2cSMauro Carvalho Chehab 114d5eefa2cSMauro Carvalho ChehabEeach filename record additionally got a filename length field. 115d5eefa2cSMauro Carvalho Chehab 116d5eefa2cSMauro Carvalho ChehabOne special case are long filenames or subdirectory names. 117d5eefa2cSMauro Carvalho Chehab 118d5eefa2cSMauro Carvalho ChehabThese got set a filename length field of 0xff in the corresponding directory 119d5eefa2cSMauro Carvalho Chehabrecord plus the longfile inode number also stored in that record. 120d5eefa2cSMauro Carvalho Chehab 121d5eefa2cSMauro Carvalho ChehabWith that longfilename inode number, the longfilename tree can be walked 122d5eefa2cSMauro Carvalho Chehabstarting with the superblock longfilename root node pointers. 123d5eefa2cSMauro Carvalho Chehab 124d5eefa2cSMauro Carvalho ChehabSpecial files 125d5eefa2cSMauro Carvalho Chehab------------- 126d5eefa2cSMauro Carvalho Chehab 127d5eefa2cSMauro Carvalho ChehabSymbolic links are also filesystem objects with inodes. They got a specific 128d5eefa2cSMauro Carvalho Chehabbit in the inode mode field identifying them as symbolic link. 129d5eefa2cSMauro Carvalho Chehab 130d5eefa2cSMauro Carvalho ChehabThe directory entry file inode pointer points to the target file inode. 131d5eefa2cSMauro Carvalho Chehab 132d5eefa2cSMauro Carvalho ChehabHard links got an inode, a directory entry, but a specific mode bit set, 133d5eefa2cSMauro Carvalho Chehabno block pointers and the directory file record pointing to the target file 134d5eefa2cSMauro Carvalho Chehabinode. 135d5eefa2cSMauro Carvalho Chehab 136d5eefa2cSMauro Carvalho ChehabCharacter and block special devices do not exist in QNX as those files 137d5eefa2cSMauro Carvalho Chehabare handled by the QNX kernel/drivers and created in /dev independent of the 138*d56b699dSBjorn Helgaasunderlying filesystem. 139d5eefa2cSMauro Carvalho Chehab 140d5eefa2cSMauro Carvalho ChehabLong filenames 141d5eefa2cSMauro Carvalho Chehab-------------- 142d5eefa2cSMauro Carvalho Chehab 143d5eefa2cSMauro Carvalho ChehabLong filenames are stored in a separate addressing tree. The staring point 144d5eefa2cSMauro Carvalho Chehabis the longfilename root node in the active superblock. 145d5eefa2cSMauro Carvalho Chehab 146d5eefa2cSMauro Carvalho ChehabEach data block (tree leaves) holds one long filename. That filename is 147d5eefa2cSMauro Carvalho Chehablimited to 510 bytes. The first two starting bytes are used as length field 148d5eefa2cSMauro Carvalho Chehabfor the actual filename. 149d5eefa2cSMauro Carvalho Chehab 150d5eefa2cSMauro Carvalho ChehabIf that structure shall fit for all allowed blocksizes, it is clear why there 151d5eefa2cSMauro Carvalho Chehabis a limit of 510 bytes for the actual filename stored. 152d5eefa2cSMauro Carvalho Chehab 153d5eefa2cSMauro Carvalho ChehabBitmap 154d5eefa2cSMauro Carvalho Chehab------ 155d5eefa2cSMauro Carvalho Chehab 156d5eefa2cSMauro Carvalho ChehabThe qnx6fs filesystem allocation bitmap is stored in a tree under bitmap 157d5eefa2cSMauro Carvalho Chehabroot node in the superblock and each bit in the bitmap represents one 158d5eefa2cSMauro Carvalho Chehabfilesystem block. 159d5eefa2cSMauro Carvalho Chehab 160d5eefa2cSMauro Carvalho ChehabThe first block is block 0, which starts 0x1000 after superblock start. 161d5eefa2cSMauro Carvalho ChehabSo for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical 162d5eefa2cSMauro Carvalho Chehabaddress at which block 0 is located. 163d5eefa2cSMauro Carvalho Chehab 164d5eefa2cSMauro Carvalho ChehabBits at the end of the last bitmap block are set to 1, if the device is 165d5eefa2cSMauro Carvalho Chehabsmaller than addressing space in the bitmap. 166d5eefa2cSMauro Carvalho Chehab 167d5eefa2cSMauro Carvalho ChehabBitmap system area 168d5eefa2cSMauro Carvalho Chehab------------------ 169d5eefa2cSMauro Carvalho Chehab 170d5eefa2cSMauro Carvalho ChehabThe bitmap itself is divided into three parts. 171d5eefa2cSMauro Carvalho Chehab 172d5eefa2cSMauro Carvalho ChehabFirst the system area, that is split into two halves. 173d5eefa2cSMauro Carvalho Chehab 174d5eefa2cSMauro Carvalho ChehabThen userspace. 175d5eefa2cSMauro Carvalho Chehab 176d5eefa2cSMauro Carvalho ChehabThe requirement for a static, fixed preallocated system area comes from how 177d5eefa2cSMauro Carvalho Chehabqnx6fs deals with writes. 178d5eefa2cSMauro Carvalho Chehab 179622d6f19SRandy DunlapEach superblock got its own half of the system area. So superblock #1 180d5eefa2cSMauro Carvalho Chehabalways uses blocks from the lower half while superblock #2 just writes to 181d5eefa2cSMauro Carvalho Chehabblocks represented by the upper half bitmap system area bits. 182d5eefa2cSMauro Carvalho Chehab 183d5eefa2cSMauro Carvalho ChehabBitmap blocks, Inode blocks and indirect addressing blocks for those two 184d5eefa2cSMauro Carvalho Chehabtree structures are treated as system blocks. 185d5eefa2cSMauro Carvalho Chehab 186d5eefa2cSMauro Carvalho ChehabThe rational behind that is that a write request can work on a new snapshot 187d5eefa2cSMauro Carvalho Chehab(system area of the inactive - resp. lower serial numbered superblock) while 18886f93e74SVilhelm Prytzat the same time there is still a complete stable filesystem structure in the 189d5eefa2cSMauro Carvalho Chehabother half of the system area. 190d5eefa2cSMauro Carvalho Chehab 191d5eefa2cSMauro Carvalho ChehabWhen finished with writing (a sync write is completed, the maximum sync leap 192d5eefa2cSMauro Carvalho Chehabtime or a filesystem sync is requested), serial of the previously inactive 193d5eefa2cSMauro Carvalho Chehabsuperblock atomically is increased and the fs switches over to that - then 194d5eefa2cSMauro Carvalho Chehabstable declared - superblock. 195d5eefa2cSMauro Carvalho Chehab 196d5eefa2cSMauro Carvalho ChehabFor all data outside the system area, blocks are just copied while writing. 197