| 1 | |
| 2 |
|
| 3 | ========================
|
| 4 | ext4 General Information
|
| 5 | ========================
|
| 6 |
|
| 7 | Ext4 is an advanced level of the ext3 filesystem which incorporates
|
| 8 | scalability and reliability enhancements for supporting large filesystems
|
| 9 | (64 bit) in keeping with increasing disk capacities and state-of-the-art
|
| 10 | feature requirements.
|
| 11 |
|
| 12 | Mailing list: [email protected]
|
| 13 | Web site: http://ext4.wiki.kernel.org
|
| 14 |
|
| 15 |
|
| 16 | Quick usage instructions
|
| 17 | ========================
|
| 18 |
|
| 19 | Note: More extensive information for getting started with ext4 can be
|
| 20 | found at the ext4 wiki site at the URL:
|
| 21 | http://ext4.wiki.kernel.org/index.php/Ext4_Howto
|
| 22 |
|
| 23 | - The latest version of e2fsprogs can be found at:
|
| 24 |
|
| 25 | https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/
|
| 26 |
|
| 27 | or
|
| 28 |
|
| 29 | http://sourceforge.net/project/showfiles.php?group_id=2406
|
| 30 |
|
| 31 | or grab the latest git repository from:
|
| 32 |
|
| 33 | https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
|
| 34 |
|
| 35 | - Create a new filesystem using the ext4 filesystem type:
|
| 36 |
|
| 37 | # mke2fs -t ext4 /dev/hda1
|
| 38 |
|
| 39 | Or to configure an existing ext3 filesystem to support extents:
|
| 40 |
|
| 41 | # tune2fs -O extents /dev/hda1
|
| 42 |
|
| 43 | If the filesystem was created with 128 byte inodes, it can be
|
| 44 | converted to use 256 byte for greater efficiency via:
|
| 45 |
|
| 46 | # tune2fs -I 256 /dev/hda1
|
| 47 |
|
| 48 | - Mounting:
|
| 49 |
|
| 50 | # mount -t ext4 /dev/hda1 /wherever
|
| 51 |
|
| 52 | - When comparing performance with other filesystems, it's always
|
| 53 | important to try multiple workloads; very often a subtle change in a
|
| 54 | workload parameter can completely change the ranking of which
|
| 55 | filesystems do well compared to others. When comparing versus ext3,
|
| 56 | note that ext4 enables write barriers by default, while ext3 does
|
| 57 | not enable write barriers by default. So it is useful to use
|
| 58 | explicitly specify whether barriers are enabled or not when via the
|
| 59 | '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems
|
| 60 | for a fair comparison. When tuning ext3 for best benchmark numbers,
|
| 61 | it is often worthwhile to try changing the data journaling mode; '-o
|
| 62 | data=writeback' can be faster for some workloads. (Note however that
|
| 63 | running mounted with data=writeback can potentially leave stale data
|
| 64 | exposed in recently written files in case of an unclean shutdown,
|
| 65 | which could be a security exposure in some situations.) Configuring
|
| 66 | the filesystem with a large journal can also be helpful for
|
| 67 | metadata-intensive workloads.
|
| 68 |
|
| 69 | Features
|
| 70 | ========
|
| 71 |
|
| 72 | Currently Available
|
| 73 | -------------------
|
| 74 |
|
| 75 | * ability to use filesystems > 16TB (e2fsprogs support not available yet)
|
| 76 | * extent format reduces metadata overhead (RAM, IO for access, transactions)
|
| 77 | * extent format more robust in face of on-disk corruption due to magics,
|
| 78 | * internal redundancy in tree
|
| 79 | * improved file allocation (multi-block alloc)
|
| 80 | * lift 32000 subdirectory limit imposed by i_links_count[1]
|
| 81 | * nsec timestamps for mtime, atime, ctime, create time
|
| 82 | * inode version field on disk (NFSv4, Lustre)
|
| 83 | * reduced e2fsck time via uninit_bg feature
|
| 84 | * journal checksumming for robustness, performance
|
| 85 | * persistent file preallocation (e.g for streaming media, databases)
|
| 86 | * ability to pack bitmaps and inode tables into larger virtual groups via the
|
| 87 | flex_bg feature
|
| 88 | * large file support
|
| 89 | * inode allocation using large virtual block groups via flex_bg
|
| 90 | * delayed allocation
|
| 91 | * large block (up to pagesize) support
|
| 92 | * efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force
|
| 93 | the ordering)
|
| 94 | * Case-insensitive file name lookups
|
| 95 | * file-based encryption support (fscrypt)
|
| 96 | * file-based verity support (fsverity)
|
| 97 |
|
| 98 | [1] Filesystems with a block size of 1k may see a limit imposed by the
|
| 99 | directory hash tree having a maximum depth of two.
|
| 100 |
|
| 101 | case-insensitive file name lookups
|
| 102 | ======================================================
|
| 103 |
|
| 104 | The case-insensitive file name lookup feature is supported on a
|
| 105 | per-directory basis, allowing the user to mix case-insensitive and
|
| 106 | case-sensitive directories in the same filesystem. It is enabled by
|
| 107 | flipping the +F inode attribute of an empty directory. The
|
| 108 | case-insensitive string match operation is only defined when we know how
|
| 109 | text in encoded in a byte sequence. For that reason, in order to enable
|
| 110 | case-insensitive directories, the filesystem must have the
|
| 111 | casefold feature, which stores the filesystem-wide encoding
|
| 112 | model used. By default, the charset adopted is the latest version of
|
| 113 | Unicode (12.1.0, by the time of this writing), encoded in the UTF-8
|
| 114 | form. The comparison algorithm is implemented by normalizing the
|
| 115 | strings to the Canonical decomposition form, as defined by Unicode,
|
| 116 | followed by a byte per byte comparison.
|
| 117 |
|
| 118 | The case-awareness is name-preserving on the disk, meaning that the file
|
| 119 | name provided by userspace is a byte-per-byte match to what is actually
|
| 120 | written in the disk. The Unicode normalization format used by the
|
| 121 | kernel is thus an internal representation, and not exposed to the
|
| 122 | userspace nor to the disk, with the important exception of disk hashes,
|
| 123 | used on large case-insensitive directories with DX feature. On DX
|
| 124 | directories, the hash must be calculated using the casefolded version of
|
| 125 | the filename, meaning that the normalization format used actually has an
|
| 126 | impact on where the directory entry is stored.
|
| 127 |
|
| 128 | When we change from viewing filenames as opaque byte sequences to seeing
|
| 129 | them as encoded strings we need to address what happens when a program
|
| 130 | tries to create a file with an invalid name. The Unicode subsystem
|
| 131 | within the kernel leaves the decision of what to do in this case to the
|
| 132 | filesystem, which select its preferred behavior by enabling/disabling
|
| 133 | the strict mode. When Ext4 encounters one of those strings and the
|
| 134 | filesystem did not require strict mode, it falls back to considering the
|
| 135 | entire string as an opaque byte sequence, which still allows the user to
|
| 136 | operate on that file, but the case-insensitive lookups won't work.
|
| 137 |
|
| 138 | Options
|
| 139 | =======
|
| 140 |
|
| 141 | When mounting an ext4 filesystem, the following option are accepted:
|
| 142 | (*) == default
|
| 143 |
|
| 144 | ro
|
| 145 | Mount filesystem read only. Note that ext4 will replay the journal (and
|
| 146 | thus write to the partition) even when mounted "read only". The mount
|
| 147 | options "ro,noload" can be used to prevent writes to the filesystem.
|
| 148 |
|
| 149 | journal_checksum
|
| 150 | Enable checksumming of the journal transactions. This will allow the
|
| 151 | recovery code in e2fsck and the kernel to detect corruption in the
|
| 152 | kernel. It is a compatible change and will be ignored by older
|
| 153 | kernels.
|
| 154 |
|
| 155 | journal_async_commit
|
| 156 | Commit block can be written to disk without waiting for descriptor
|
| 157 | blocks. If enabled older kernels cannot mount the device. This will
|
| 158 | enable 'journal_checksum' internally.
|
| 159 |
|
| 160 | journal_path=path, journal_dev=devnum
|
| 161 | When the external journal device's major/minor numbers have changed,
|
| 162 | these options allow the user to specify the new journal location. The
|
| 163 | journal device is identified through either its new major/minor numbers
|
| 164 | encoded in devnum, or via a path to the device.
|
| 165 |
|
| 166 | norecovery, noload
|
| 167 | Don't load the journal on mounting. Note that if the filesystem was
|
| 168 | not unmounted cleanly, skipping the journal replay will lead to the
|
| 169 | filesystem containing inconsistencies that can lead to any number of
|
| 170 | problems.
|
| 171 |
|
| 172 | data=journal
|
| 173 | All data are committed into the journal prior to being written into the
|
| 174 | main file system. Enabling this mode will disable delayed allocation
|
| 175 | and O_DIRECT support. This feature is deprecated and support
|
| 176 | will be removed in January 2028.
|
| 177 |
|
| 178 | data=ordered (*)
|
| 179 | All data are forced directly out to the main file system prior to its
|
| 180 | metadata being committed to the journal.
|
| 181 |
|
| 182 | data=writeback
|
| 183 | Data ordering is not preserved, data may be written into the main file
|
| 184 | system after its metadata has been committed to the journal.
|
| 185 |
|
| 186 | commit=nrsec (*)
|
| 187 | This setting limits the maximum age of the running transaction to
|
| 188 | 'nrsec' seconds. The default value is 5 seconds. This means that if
|
| 189 | you lose your power, you will lose as much as the latest 5 seconds of
|
| 190 | metadata changes (your filesystem will not be damaged though, thanks
|
| 191 | to the journaling). This default value (or any low value) will hurt
|
| 192 | performance, but it's good for data-safety. Setting it to 0 will have
|
| 193 | the same effect as leaving it at the default (5 seconds). Setting it
|
| 194 | to very large values will improve performance. Note that due to
|
| 195 | delayed allocation even older data can be lost on power failure since
|
| 196 | writeback of those data begins only after time set in
|
| 197 | /proc/sys/vm/dirty_expire_centisecs.
|
| 198 |
|
| 199 | barrier=<0|1(*)>, barrier(*), nobarrier
|
| 200 | This enables/disables the use of write barriers in the jbd code.
|
| 201 | barrier=0 disables, barrier=1 enables. This also requires an IO stack
|
| 202 | which can support barriers, and if jbd gets an error on a barrier
|
| 203 | write, it will disable again with a warning. Write barriers enforce
|
| 204 | proper on-disk ordering of journal commits, making volatile disk write
|
| 205 | caches safe to use, at some performance penalty. If your disks are
|
| 206 | battery-backed in one way or another, disabling barriers may safely
|
| 207 | improve performance. The mount options "barrier" and "nobarrier" can
|
| 208 | also be used to enable or disable barriers, for consistency with other
|
| 209 | ext4 mount options.
|
| 210 |
|
| 211 | inode_readahead_blks=n
|
| 212 | This tuning parameter controls the maximum number of inode table blocks
|
| 213 | that ext4's inode table readahead algorithm will pre-read into the
|
| 214 | buffer cache. The default value is 32 blocks.
|
| 215 |
|
| 216 | bsddf (*)
|
| 217 | Make 'df' act like BSD.
|
| 218 |
|
| 219 | minixdf
|
| 220 | Make 'df' act like Minix.
|
| 221 |
|
| 222 | debug
|
| 223 | Extra debugging information is sent to syslog.
|
| 224 |
|
| 225 | abort
|
| 226 | Simulate the effects of calling ext4_abort() for debugging purposes.
|
| 227 | This is normally used while remounting a filesystem which is already
|
| 228 | mounted.
|
| 229 |
|
| 230 | errors=remount-ro
|
| 231 | Remount the filesystem read-only on an error.
|
| 232 |
|
| 233 | errors=continue
|
| 234 | Keep going on a filesystem error.
|
| 235 |
|
| 236 | errors=panic
|
| 237 | Panic and halt the machine if an error occurs. (These mount options
|
| 238 | override the errors behavior specified in the superblock, which can be
|
| 239 | configured using tune2fs)
|
| 240 |
|
| 241 | data_err=ignore(*)
|
| 242 | Just print an error message if an error occurs in a file data buffer.
|
| 243 |
|
| 244 | data_err=abort
|
| 245 | Abort the journal if an error occurs in a file data buffer.
|
| 246 |
|
| 247 | grpid | bsdgroups
|
| 248 | New objects have the group ID of their parent.
|
| 249 |
|
| 250 | nogrpid (*) | sysvgroups
|
| 251 | New objects have the group ID of their creator.
|
| 252 |
|
| 253 | resgid=n
|
| 254 | The group ID which may use the reserved blocks.
|
| 255 |
|
| 256 | resuid=n
|
| 257 | The user ID which may use the reserved blocks.
|
| 258 |
|
| 259 | sb=
|
| 260 | Use alternate superblock at this location.
|
| 261 |
|
| 262 | quota, noquota, grpquota, usrquota
|
| 263 | These options are ignored by the filesystem. They are used only by
|
| 264 | quota tools to recognize volumes where quota should be turned on. See
|
| 265 | documentation in the quota-tools package for more details
|
| 266 | (http://sourceforge.net/projects/linuxquota).
|
| 267 |
|
| 268 | jqfmt=<quota type>, usrjquota=<file>, grpjquota=<file>
|
| 269 | These options tell filesystem details about quota so that quota
|
| 270 | information can be properly updated during journal replay. They replace
|
| 271 | the above quota options. See documentation in the quota-tools package
|
| 272 | for more details (http://sourceforge.net/projects/linuxquota).
|
| 273 |
|
| 274 | stripe=n
|
| 275 | Number of filesystem blocks that mballoc will try to use for allocation
|
| 276 | size and alignment. For RAID5/6 systems this should be the number of
|
| 277 | data disks * RAID chunk size in file system blocks.
|
| 278 |
|
| 279 | delalloc (*)
|
| 280 | Defer block allocation until just before ext4 writes out the block(s)
|
| 281 | in question. This allows ext4 to better allocation decisions more
|
| 282 | efficiently.
|
| 283 |
|
| 284 | nodelalloc
|
| 285 | Disable delayed allocation. Blocks are allocated when the data is
|
| 286 | copied from userspace to the page cache, either via the write(2) system
|
| 287 | call or when an mmap'ed page which was previously unallocated is
|
| 288 | written for the first time.
|
| 289 |
|
| 290 | max_batch_time=usec
|
| 291 | Maximum amount of time ext4 should wait for additional filesystem
|
| 292 | operations to be batch together with a synchronous write operation.
|
| 293 | Since a synchronous write operation is going to force a commit and then
|
| 294 | a wait for the I/O complete, it doesn't cost much, and can be a huge
|
| 295 | throughput win, we wait for a small amount of time to see if any other
|
| 296 | transactions can piggyback on the synchronous write. The algorithm
|
| 297 | used is designed to automatically tune for the speed of the disk, by
|
| 298 | measuring the amount of time (on average) that it takes to finish
|
| 299 | committing a transaction. Call this time the "commit time". If the
|
| 300 | time that the transaction has been running is less than the commit
|
| 301 | time, ext4 will try sleeping for the commit time to see if other
|
| 302 | operations will join the transaction. The commit time is capped by
|
| 303 | the max_batch_time, which defaults to 15000us (15ms). This
|
| 304 | optimization can be turned off entirely by setting max_batch_time to 0.
|
| 305 |
|
| 306 | min_batch_time=usec
|
| 307 | This parameter sets the commit time (as described above) to be at least
|
| 308 | min_batch_time. It defaults to zero microseconds. Increasing this
|
| 309 | parameter may improve the throughput of multi-threaded, synchronous
|
| 310 | workloads on very fast disks, at the cost of increasing latency.
|
| 311 |
|
| 312 | journal_ioprio=prio
|
| 313 | The I/O priority (from 0 to 7, where 0 is the highest priority) which
|
| 314 | should be used for I/O operations submitted by kjournald2 during a
|
| 315 | commit operation. This defaults to 3, which is a slightly higher
|
| 316 | priority than the default I/O priority.
|
| 317 |
|
| 318 | auto_da_alloc(*), noauto_da_alloc
|
| 319 | Many broken applications don't use fsync() when replacing existing
|
| 320 | files via patterns such as fd = open("foo.new")/write(fd,..)/close(fd)/
|
| 321 | rename("foo.new", "foo"), or worse yet, fd = open("foo",
|
| 322 | O_TRUNC)/write(fd,..)/close(fd). If auto_da_alloc is enabled, ext4
|
| 323 | will detect the replace-via-rename and replace-via-truncate patterns
|
| 324 | and force that any delayed allocation blocks are allocated such that at
|
| 325 | the next journal commit, in the default data=ordered mode, the data
|
| 326 | blocks of the new file are forced to disk before the rename() operation
|
| 327 | is committed. This provides roughly the same level of guarantees as
|
| 328 | ext3, and avoids the "zero-length" problem that can happen when a
|
| 329 | system crashes before the delayed allocation blocks are forced to disk.
|
| 330 |
|
| 331 | noinit_itable
|
| 332 | Do not initialize any uninitialized inode table blocks in the
|
| 333 | background. This feature may be used by installation CD's so that the
|
| 334 | install process can complete as quickly as possible; the inode table
|
| 335 | initialization process would then be deferred until the next time the
|
| 336 | file system is unmounted.
|
| 337 |
|
| 338 | init_itable=n
|
| 339 | The lazy itable init code will wait n times the number of milliseconds
|
| 340 | it took to zero out the previous block group's inode table. This
|
| 341 | minimizes the impact on the system performance while file system's
|
| 342 | inode table is being initialized.
|
| 343 |
|
| 344 | discard, nodiscard(*)
|
| 345 | Controls whether ext4 should issue discard/TRIM commands to the
|
| 346 | underlying block device when blocks are freed. This is useful for SSD
|
| 347 | devices and sparse/thinly-provisioned LUNs, but it is off by default
|
| 348 | until sufficient testing has been done.
|
| 349 |
|
| 350 | nouid32
|
| 351 | Disables 32-bit UIDs and GIDs. This is for interoperability with
|
| 352 | older kernels which only store and expect 16-bit values.
|
| 353 |
|
| 354 | block_validity(*), noblock_validity
|
| 355 | These options enable or disable the in-kernel facility for tracking
|
| 356 | filesystem metadata blocks within internal data structures. This
|
| 357 | allows multi- block allocator and other routines to notice bugs or
|
| 358 | corrupted allocation bitmaps which cause blocks to be allocated which
|
| 359 | overlap with filesystem metadata blocks.
|
| 360 |
|
| 361 | dioread_lock, dioread_nolock
|
| 362 | Controls whether or not ext4 should use the DIO read locking. If the
|
| 363 | dioread_nolock option is specified ext4 will allocate uninitialized
|
| 364 | extent before buffer write and convert the extent to initialized after
|
| 365 | IO completes. This approach allows ext4 code to avoid using inode
|
| 366 | mutex, which improves scalability on high speed storages. However this
|
| 367 | does not work with data journaling and dioread_nolock option will be
|
| 368 | ignored with kernel warning. Note that dioread_nolock code path is only
|
| 369 | used for extent-based files. Because of the restrictions this options
|
| 370 | comprises it is off by default (e.g. dioread_lock).
|
| 371 |
|
| 372 | max_dir_size_kb=n
|
| 373 | This limits the size of directories so that any attempt to expand them
|
| 374 | beyond the specified limit in kilobytes will cause an ENOSPC error.
|
| 375 | This is useful in memory constrained environments, where a very large
|
| 376 | directory can cause severe performance problems or even provoke the Out
|
| 377 | Of Memory killer. (For example, if there is only 512mb memory
|
| 378 | available, a 176mb directory may seriously cramp the system's style.)
|
| 379 |
|
| 380 | i_version
|
| 381 | Enable 64-bit inode version support. This option is off by default.
|
| 382 |
|
| 383 | dax
|
| 384 | Use direct access (no page cache). See
|
| 385 | Documentation/filesystems/dax.rst. Note that this option is
|
| 386 | incompatible with data=journal.
|
| 387 |
|
| 388 | inlinecrypt
|
| 389 | When possible, encrypt/decrypt the contents of encrypted files using
|
| 390 | inline encryption hardware rather than the CPU. For more details, see
|
| 391 | Documentation/filesystems/fscrypt.rst.
|
| 392 |
|
| 393 | Data Mode
|
| 394 | =========
|
| 395 | There are 3 different data modes:
|
| 396 |
|
| 397 | * writeback mode
|
| 398 |
|
| 399 | In data=writeback mode, ext4 does not journal data at all. This mode provides
|
| 400 | a similar level of journaling as that of XFS and JFS in its default
|
| 401 | mode - metadata journaling. A crash+recovery can cause incorrect data to
|
| 402 | appear in files which were written shortly before the crash. This mode will
|
| 403 | typically provide the best ext4 performance.
|
| 404 |
|
| 405 | * ordered mode
|
| 406 |
|
| 407 | In data=ordered mode, ext4 only officially journals metadata, but it logically
|
| 408 | groups metadata information related to data changes with the data blocks into
|
| 409 | a single unit called a transaction. When it's time to write the new metadata
|
| 410 | out to disk, the associated data blocks are written first. In general, this
|
| 411 | mode performs slightly slower than writeback but significantly faster than
|
| 412 | journal mode.
|
| 413 |
|
| 414 | * journal mode
|
| 415 |
|
| 416 | data=journal mode provides full data and metadata journaling. All new data is
|
| 417 | written to the journal first, and then to its final location. In the event of
|
| 418 | a crash, the journal can be replayed, bringing both data and metadata into a
|
| 419 | consistent state. This mode is the slowest except when data needs to be read
|
| 420 | from and written to disk at the same time where it outperforms all others
|
| 421 | modes. Enabling this mode will disable delayed allocation and O_DIRECT
|
| 422 | support. The data=journal feature is deprecated and support will be
|
| 423 | removed in January 2028.
|
| 424 |
|
| 425 | /proc entries
|
| 426 | =============
|
| 427 |
|
| 428 | Information about mounted ext4 file systems can be found in
|
| 429 | /proc/fs/ext4. Each mounted filesystem will have a directory in
|
| 430 | /proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
|
| 431 | /proc/fs/ext4/dm-0). The files in each per-device directory are shown
|
| 432 | in table below.
|
| 433 |
|
| 434 | Files in /proc/fs/ext4/<devname>
|
| 435 |
|
| 436 | mb_groups
|
| 437 | details of multiblock allocator buddy cache of free blocks
|
| 438 |
|
| 439 | /sys entries
|
| 440 | ============
|
| 441 |
|
| 442 | Information about mounted ext4 file systems can be found in
|
| 443 | /sys/fs/ext4. Each mounted filesystem will have a directory in
|
| 444 | /sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or
|
| 445 | /sys/fs/ext4/dm-0). The files in each per-device directory are shown
|
| 446 | in table below.
|
| 447 |
|
| 448 | Files in /sys/fs/ext4/<devname>:
|
| 449 |
|
| 450 | (see also Documentation/ABI/testing/sysfs-fs-ext4)
|
| 451 |
|
| 452 | delayed_allocation_blocks
|
| 453 | This file is read-only and shows the number of blocks that are dirty in
|
| 454 | the page cache, but which do not have their location in the filesystem
|
| 455 | allocated yet.
|
| 456 |
|
| 457 | inode_goal
|
| 458 | Tuning parameter which (if non-zero) controls the goal inode used by
|
| 459 | the inode allocator in preference to all other allocation heuristics.
|
| 460 | This is intended for debugging use only, and should be 0 on production
|
| 461 | systems.
|
| 462 |
|
| 463 | inode_readahead_blks
|
| 464 | Tuning parameter which controls the maximum number of inode table
|
| 465 | blocks that ext4's inode table readahead algorithm will pre-read into
|
| 466 | the buffer cache.
|
| 467 |
|
| 468 | lifetime_write_kbytes
|
| 469 | This file is read-only and shows the number of kilobytes of data that
|
| 470 | have been written to this filesystem since it was created.
|
| 471 |
|
| 472 | max_writeback_mb_bump
|
| 473 | The maximum number of megabytes the writeback code will try to write
|
| 474 | out before move on to another inode.
|
| 475 |
|
| 476 | mb_group_prealloc
|
| 477 | The multiblock allocator will round up allocation requests to a
|
| 478 | multiple of this tuning parameter if the stripe size is not set in the
|
| 479 | ext4 superblock
|
| 480 |
|
| 481 | mb_max_to_scan
|
| 482 | The maximum number of extents the multiblock allocator will search to
|
| 483 | find the best extent.
|
| 484 |
|
| 485 | mb_min_to_scan
|
| 486 | The minimum number of extents the multiblock allocator will search to
|
| 487 | find the best extent.
|
| 488 |
|
| 489 | mb_order2_req
|
| 490 | Tuning parameter which controls the minimum size for requests (as a
|
| 491 | power of 2) where the buddy cache is used.
|
| 492 |
|
| 493 | mb_stats
|
| 494 | Controls whether the multiblock allocator should collect statistics,
|
| 495 | which are shown during the unmount. 1 means to collect statistics, 0
|
| 496 | means not to collect statistics.
|
| 497 |
|
| 498 | mb_stream_req
|
| 499 | Files which have fewer blocks than this tunable parameter will have
|
| 500 | their blocks allocated out of a block group specific preallocation
|
| 501 | pool, so that small files are packed closely together. Each large file
|
| 502 | will have its blocks allocated out of its own unique preallocation
|
| 503 | pool.
|
| 504 |
|
| 505 | session_write_kbytes
|
| 506 | This file is read-only and shows the number of kilobytes of data that
|
| 507 | have been written to this filesystem since it was mounted.
|
| 508 |
|
| 509 | reserved_clusters
|
| 510 | This is RW file and contains number of reserved clusters in the file
|
| 511 | system which will be used in the specific situations to avoid costly
|
| 512 | zeroout, unexpected ENOSPC, or possible data loss. The default is 2% or
|
| 513 | 4096 clusters, whichever is smaller and this can be changed however it
|
| 514 | can never exceed number of clusters in the file system. If there is not
|
| 515 | enough space for the reserved space when mounting the file mount will
|
| 516 | _not_ fail.
|
| 517 |
|
| 518 | Ioctls
|
| 519 | ======
|
| 520 |
|
| 521 | Ext4 implements various ioctls which can be used by applications to access
|
| 522 | ext4-specific functionality. An incomplete list of these ioctls is shown in the
|
| 523 | table below. This list includes truly ext4-specific ioctls (``EXT4_IOC_*``) as
|
| 524 | well as ioctls that may have been ext4-specific originally but are now supported
|
| 525 | by some other filesystem(s) too (``FS_IOC_*``).
|
| 526 |
|
| 527 | Table of Ext4 ioctls
|
| 528 |
|
| 529 | FS_IOC_GETFLAGS
|
| 530 | Get additional attributes associated with inode. The ioctl argument is
|
| 531 | an integer bitfield, with bit values described in ext4.h.
|
| 532 |
|
| 533 | FS_IOC_SETFLAGS
|
| 534 | Set additional attributes associated with inode. The ioctl argument is
|
| 535 | an integer bitfield, with bit values described in ext4.h.
|
| 536 |
|
| 537 | EXT4_IOC_GETVERSION, EXT4_IOC_GETVERSION_OLD
|
| 538 | Get the inode i_generation number stored for each inode. The
|
| 539 | i_generation number is normally changed only when new inode is created
|
| 540 | and it is particularly useful for network filesystems. The '_OLD'
|
| 541 | version of this ioctl is an alias for FS_IOC_GETVERSION.
|
| 542 |
|
| 543 | EXT4_IOC_SETVERSION, EXT4_IOC_SETVERSION_OLD
|
| 544 | Set the inode i_generation number stored for each inode. The '_OLD'
|
| 545 | version of this ioctl is an alias for FS_IOC_SETVERSION.
|
| 546 |
|
| 547 | EXT4_IOC_GROUP_EXTEND
|
| 548 | This ioctl has the same purpose as the resize mount option. It allows
|
| 549 | to resize filesystem to the end of the last existing block group,
|
| 550 | further resize has to be done with resize2fs, either online, or
|
| 551 | offline. The argument points to the unsigned logn number representing
|
| 552 | the filesystem new block count.
|
| 553 |
|
| 554 | EXT4_IOC_MOVE_EXT
|
| 555 | Move the block extents from orig_fd (the one this ioctl is pointing to)
|
| 556 | to the donor_fd (the one specified in move_extent structure passed as
|
| 557 | an argument to this ioctl). Then, exchange inode metadata between
|
| 558 | orig_fd and donor_fd. This is especially useful for online
|
| 559 | defragmentation, because the allocator has the opportunity to allocate
|
| 560 | moved blocks better, ideally into one contiguous extent.
|
| 561 |
|
| 562 | EXT4_IOC_GROUP_ADD
|
| 563 | Add a new group descriptor to an existing or new group descriptor
|
| 564 | block. The new group descriptor is described by ext4_new_group_input
|
| 565 | structure, which is passed as an argument to this ioctl. This is
|
| 566 | especially useful in conjunction with EXT4_IOC_GROUP_EXTEND, which
|
| 567 | allows online resize of the filesystem to the end of the last existing
|
| 568 | block group. Those two ioctls combined is used in userspace online
|
| 569 | resize tool (e.g. resize2fs).
|
| 570 |
|
| 571 | EXT4_IOC_MIGRATE
|
| 572 | This ioctl operates on the filesystem itself. It converts (migrates)
|
| 573 | ext3 indirect block mapped inode to ext4 extent mapped inode by walking
|
| 574 | through indirect block mapping of the original inode and converting
|
| 575 | contiguous block ranges into ext4 extents of the temporary inode. Then,
|
| 576 | inodes are swapped. This ioctl might help, when migrating from ext3 to
|
| 577 | ext4 filesystem, however suggestion is to create fresh ext4 filesystem
|
| 578 | and copy data from the backup. Note, that filesystem has to support
|
| 579 | extents for this ioctl to work.
|
| 580 |
|
| 581 | EXT4_IOC_ALLOC_DA_BLKS
|
| 582 | Force all of the delay allocated blocks to be allocated to preserve
|
| 583 | application-expected ext3 behaviour. Note that this will also start
|
| 584 | triggering a write of the data blocks, but this behaviour may change in
|
| 585 | the future as it is not necessary and has been done this way only for
|
| 586 | sake of simplicity.
|
| 587 |
|
| 588 | EXT4_IOC_RESIZE_FS
|
| 589 | Resize the filesystem to a new size. The number of blocks of resized
|
| 590 | filesystem is passed in via 64 bit integer argument. The kernel
|
| 591 | allocates bitmaps and inode table, the userspace tool thus just passes
|
| 592 | the new number of blocks.
|
| 593 |
|
| 594 | EXT4_IOC_SWAP_BOOT
|
| 595 | Swap i_blocks and associated attributes (like i_blocks, i_size,
|
| 596 | i_flags, ...) from the specified inode with inode EXT4_BOOT_LOADER_INO
|
| 597 | (#5). This is typically used to store a boot loader in a secure part of
|
| 598 | the filesystem, where it can't be changed by a normal user by accident.
|
| 599 | The data blocks of the previous boot loader will be associated with the
|
| 600 | given inode.
|
| 601 |
|
| 602 | References
|
| 603 | ==========
|
| 604 |
|
| 605 | kernel source: <file:fs/ext4/>
|
| 606 | <file:fs/jbd2/>
|
| 607 |
|
| 608 | programs: http://e2fsprogs.sourceforge.net/
|
| 609 |
|
| 610 | useful links: https://fedoraproject.org/wiki/ext3-devel
|
| 611 | http://www.bullopensource.org/ext4/
|
| 612 | http://ext4.wiki.kernel.org/index.php/Main_Page
|
| 613 | https://fedoraproject.org/wiki/Features/Ext4
|