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