~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/filesystems/qnx6.rst

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /Documentation/filesystems/qnx6.rst (Architecture sparc) and /Documentation/filesystems/qnx6.rst (Architecture ppc)


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

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php