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