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