linux lanana org as part of the Linux Assigned Names And Numbers Authority mainline Linux kernel is now the maintained main document Note The original version of this document which was maintained at Last update 2005 01 17 version 1 4 Unicode support LANANA project is no longer existent So this version in the

Answer:
Unicode support
===============

		 Last update: 2005-01-17, version 1.4

Note: The original version of this document, which was maintained at
lanana.org as part of the Linux Assigned Names And Numbers Authority
(LANANA) project, is no longer existent.  So, this version in the
mainline Linux kernel is now the maintained main document.

Introduction
------------

The Linux kernel code has been rewritten to use Unicode to map
characters to fonts.  By downloading a single Unicode-to-font table,
both the eight-bit character sets and UTF-8 mode are changed to use
the font as indicated.

This changes the semantics of the eight-bit character tables subtly.
The four character tables are now:

=============== =============================== ================
Map symbol	Map name			Escape code (G0)
=============== =============================== ================
LAT1_MAP	Latin-1 (ISO 8859-1)		ESC ( B
GRAF_MAP	DEC VT100 pseudographics	ESC ( 0
IBMPC_MAP	IBM code page 437		ESC ( U
USER_MAP	User defined			ESC ( K
=============== =============================== ================

In particular, ESC ( U is no longer "straight to font", since the font
might be completely different than the IBM character set.  This
permits for example the use of block graphics even with a Latin-1 font
loaded.

Note that although these codes are similar to ISO 2022, neither the
codes nor their uses match ISO 2022; Linux has two 8-bit codes (G0 and
G1), whereas ISO 2022 has four 7-bit codes (G0-G3).

In accordance with the Unicode standard/ISO 10646 the range U+F000 to
U+F8FF has been reserved for OS-wide allocation (the Unicode Standard
refers to this as a "Corporate Zone", since this is inaccurate for
Linux we call it the "Linux Zone").  U+F000 was picked as the starting
point since it lets the direct-mapping area start on a large power of
two (in case 1024- or 2048-character fonts ever become necessary).
This leaves U+E000 to U+EFFF as End User Zone.

[v1.2]: The Unicodes range from U+F000 and up to U+F7FF have been
hard-coded to map directly to the loaded font, bypassing the
translation table.  The user-defined map now defaults to U+F000 to
U+F0FF, emulating the previous behaviour.  In practice, this range
might be shorter; for example, vgacon can only handle 256-character
(U+F000..U+F0FF) or 512-character (U+F000..U+F1FF) fonts.

Actual characters assigned in the Linux Zone
--------------------------------------------

In addition, the following characters not present in Unicode 1.1.4
have been defined; these are used by the DEC VT graphics map.  [v1.2]
THIS USE IS OBSOLETE AND SHOULD NO LONGER BE USED; PLEASE SEE BELOW.

====== ======================================
U+F800 DEC VT GRAPHICS HORIZONTAL LINE SCAN 1
U+F801 DEC VT GRAPHICS HORIZONTAL LINE SCAN 3
U+F803 DEC VT GRAPHICS HORIZONTAL LINE SCAN 7
U+F804 DEC VT GRAPHICS HORIZONTAL LINE SCAN 9
====== ======================================

The DEC VT220 uses a 6x10 character matrix, and these characters form
a smooth progression in the DEC VT graphics character set.  I have
omitted the scan 5 line, since it is also used as a block-graphics
character, and hence has been coded as U+2500 FORMS LIGHT HORIZONTAL.

[v1.3]: These characters have been officially added to Unicode 3.2.0;
they are added at U+23BA, U+23BB, U+23BC, U+23BD.  Linux now uses the
new values.

[v1.2]: The following characters have been added to represent common
keyboard symbols that are unlikely to ever be added to Unicode proper
since they are horribly vendor-specific.  This, of course, is an
excellent example of horrible design.

====== ======================================
U+F810 KEYBOARD SYMBOL FLYING FLAG
U+F811 KEYBOARD SYMBOL PULLDOWN MENU
U+F812 KEYBOARD SYMBOL OPEN APPLE
U+F813 KEYBOARD SYMBOL SOLID APPLE
====== ======================================

Klingon language support
------------------------

In 1996, Linux was the first operating system in the world to add
support for the artificial language Klingon, created by Marc Okrand
for the "Star Trek" television series.	This encoding was later
adopted by the ConScript Unicode Registry and proposed (but ultimately
rejected) for inclusion in Unicode Plane 1.  Thus, it remains as a
Linux/CSUR private assignment in the Linux Zone.

This encoding has been endorsed by the Klingon Language Institute.
For more information, contact them at:

	http://www.kli.org/

Since the characters in the beginning of the Linux CZ have been more
of the dingbats/symbols/forms type and this is a language, I have
located it at the end, on a 16-cell boundary in keeping with standard
Unicode practice.

.. note::

  This range is now officially managed by the ConScript Unicode
  Registry.  The normative reference is at:

	https://www.evertype.com/standards/csur/klingon.html

Klingon has an alphabet of 26 characters, a positional numeric writing
system with 10 digits, and is written left-to-right, top-to-bottom.

Several glyph forms for the Klingon alphabet have been proposed.
However, since the set of symbols appear to be consistent throughout,
with only the actual shapes being different, in keeping with standard
Unicode practice these differences are considered font variants.

======	=======================================================
U+F8D0	KLINGON LETTER A
U+F8D1	KLINGON LETTER B
U+F8D2	KLINGON LETTER CH
U+F8D3	KLINGON LETTER D
U+F8D4	KLINGON LETTER E
U+F8D5	KLINGON LETTER GH
U+F8D6	KLINGON LETTER H
U+F8D7	KLINGON LETTER I
U+F8D8	KLINGON LETTER J
U+F8D9	KLINGON LETTER L
U+F8DA	KLINGON LETTER M
U+F8DB	KLINGON LETTER N
U+F8DC	KLINGON LETTER NG
U+F8DD	KLINGON LETTER O
U+F8DE	KLINGON LETTER P
U+F8DF	KLINGON LETTER Q
	- Written <q> in standard Okrand Latin transliteration
U+F8E0	KLINGON LETTER QH
	- Written <Q> in standard Okrand Latin transliteration
U+F8E1	KLINGON LETTER R
U+F8E2	KLINGON LETTER S
U+F8E3	KLINGON LETTER T
U+F8E4	KLINGON LETTER TLH
U+F8E5	KLINGON LETTER U
U+F8E6	KLINGON LETTER V
U+F8E7	KLINGON LETTER W
U+F8E8	KLINGON LETTER Y
U+F8E9	KLINGON LETTER GLOTTAL STOP

U+F8F0	KLINGON DIGIT ZERO
U+F8F1	KLINGON DIGIT ONE
U+F8F2	KLINGON DIGIT TWO
U+F8F3	KLINGON DIGIT THREE
U+F8F4	KLINGON DIGIT FOUR
U+F8F5	KLINGON DIGIT FIVE
U+F8F6	KLINGON DIGIT SIX
U+F8F7	KLINGON DIGIT SEVEN
U+F8F8	KLINGON DIGIT EIGHT
U+F8F9	KLINGON DIGIT NINE

U+F8FD	KLINGON COMMA
U+F8FE	KLINGON FULL STOP
U+F8FF	KLINGON SYMBOL FOR EMPIRE
======	=======================================================

Other Fictional and Artificial Scripts
--------------------------------------

Since the assignment of the Klingon Linux Unicode block, a registry of
fictional and artificial scripts has been established by John Cowan
<jcowan@reutershealth.com> and Michael Everson <everson@evertype.com>.
The ConScript Unicode Registry is accessible at:

	  https://www.evertype.com/standards/csur/

The ranges used fall at the low end of the End User Zone and can hence
not be normatively assigned, but it is recommended that people who
wish to encode fictional scripts use these codes, in the interest of
interoperability.  For Klingon, CSUR has adopted the Linux encoding.
The CSUR people are driving adding Tengwar and Cirth into Unicode
Plane 1; the addition of Klingon to Unicode Plane 1 has been rejected
and so the above encoding remains official.

Unicode support                     Last update  2005 01 17  version 1 4  Note  The original version of this document  which was maintained at lanana org as part of the Linux Assigned Names And Numbers Authority  LANANA  project  is no longer existent   So  this version in the mainline Linux kernel is now the maintained main document   Introduction               The Linux kernel code has been rewritten to use Unicode to map characters to fonts   By downloading a single Unicode to font table  both the eight bit character sets and UTF 8 mode are changed to use the font as indicated   This changes the semantics of the eight bit character tables subtly  The four character tables are now                                                                    Map symbol Map name   Escape code  G0                                                                   LAT1 MAP Latin 1  ISO 8859 1   ESC   B GRAF MAP DEC VT100 pseudographics ESC   0 IBMPC MAP IBM code page 437  ESC   U USER MAP User defined   ESC   K                                                                   In particular  ESC   U is no longer  straight to font   since the font might be completely different than the IBM character set   This permits for example the use of block graphics even with a Latin 1 font loaded   Note that although these codes are similar to ISO 2022  neither the codes nor their uses match ISO 2022  Linux has two 8 bit codes  G0 and G1   whereas ISO 2022 has four 7 bit codes  G0 G3    In accordance with the Unicode standard ISO 10646 the range U F000 to U F8FF has been reserved for OS wide allocation  the Unicode Standard refers to this as a  Corporate Zone   since this is inaccurate for Linux we call it the  Linux Zone     U F000 was picked as the starting point since it lets the direct mapping area start on a large power of two  in case 1024  or 2048 character fonts ever become necessary   This leaves U E000 to U EFFF as End User Zone    v1 2   The Unicodes range from U F000 and up to U F7FF have been hard coded to map directly to the loaded font  bypassing the translation table   The user defined map now defaults to U F000 to U F0FF  emulating the previous behaviour   In practice  this range might be shorter  for example  vgacon can only handle 256 character  U F000  U F0FF  or 512 character  U F000  U F1FF  fonts    Actual characters assigned in the Linux Zone                                               In addition  the following characters not present in Unicode 1 1 4 have been defined  these are used by the DEC VT graphics map    v1 2  THIS USE IS OBSOLETE AND SHOULD NO LONGER BE USED  PLEASE SEE BELOW                                                 U F800 DEC VT GRAPHICS HORIZONTAL LINE SCAN 1 U F801 DEC VT GRAPHICS HORIZONTAL LINE SCAN 3 U F803 DEC VT GRAPHICS HORIZONTAL LINE SCAN 7 U F804 DEC VT GRAPHICS HORIZONTAL LINE SCAN 9                                                The DEC VT220 uses a 6x10 character matrix  and these characters form a smooth progression in the DEC VT graphics character set   I have omitted the scan 5 line  since it is also used as a block graphics character  and hence has been coded as U 2500 FORMS LIGHT HORIZONTAL    v1 3   These characters have been officially added to Unicode 3 2 0  they are added at U 23BA  U 23BB  U 23BC  U 23BD   Linux now uses the new values    v1 2   The following characters have been added to represent common keyboard symbols that are unlikely to ever be added to Unicode proper since they are horribly vendor specific   This  of course  is an excellent example of horrible design                                                 U F810 KEYBOARD SYMBOL FLYING FLAG U F811 KEYBOARD SYMBOL PULLDOWN MENU U F812 KEYBOARD SYMBOL OPEN APPLE U F813 KEYBOARD SYMBOL SOLID APPLE                                                Klingon language support                           In 1996  Linux was the first operating system in the world to add support for the artificial language Klingon  created by Marc Okrand for the  Star Trek  television series  This encoding was later adopted by the ConScript Unicode Registry and proposed  but ultimately rejected  for inclusion in Unicode Plane 1   Thus  it remains as a Linux CSUR private assignment in the Linux Zone   This encoding has been endorsed by the Klingon Language Institute  For more information  contact them at    http   www kli org   Since the characters in the beginning of the Linux CZ have been more of the dingbats symbols forms type and this is a language  I have located it at the end  on a 16 cell boundary in keeping with standard Unicode practice      note      This range is now officially managed by the ConScript Unicode   Registry   The normative reference is at    https   www evertype com standards csur klingon html  Klingon has an alphabet of 26 characters  a positional numeric writing system with 10 digits  and is written left to right  top to bottom   Several glyph forms for the Klingon alphabet have been proposed  However  since the set of symbols appear to be consistent throughout  with only the actual shapes being different  in keeping with standard Unicode practice these differences are considered font variants                                                                  U F8D0 KLINGON LETTER A U F8D1 KLINGON LETTER B U F8D2 KLINGON LETTER CH U F8D3 KLINGON LETTER D U F8D4 KLINGON LETTER E U F8D5 KLINGON LETTER GH U F8D6 KLINGON LETTER H U F8D7 KLINGON LETTER I U F8D8 KLINGON LETTER J U F8D9 KLINGON LETTER L U F8DA KLINGON LETTER M U F8DB KLINGON LETTER N U F8DC KLINGON LETTER NG U F8DD KLINGON LETTER O U F8DE KLINGON LETTER P U F8DF KLINGON LETTER Q    Written  q  in standard Okrand Latin transliteration U F8E0 KLINGON LETTER QH    Written  Q  in standard Okrand Latin transliteration U F8E1 KLINGON LETTER R U F8E2 KLINGON LETTER S U F8E3 KLINGON LETTER T U F8E4 KLINGON LETTER TLH U F8E5 KLINGON LETTER U U F8E6 KLINGON LETTER V U F8E7 KLINGON LETTER W U F8E8 KLINGON LETTER Y U F8E9 KLINGON LETTER GLOTTAL STOP  U F8F0 KLINGON DIGIT ZERO U F8F1 KLINGON DIGIT ONE U F8F2 KLINGON DIGIT TWO U F8F3 KLINGON DIGIT THREE U F8F4 KLINGON DIGIT FOUR U F8F5 KLINGON DIGIT FIVE U F8F6 KLINGON DIGIT SIX U F8F7 KLINGON DIGIT SEVEN U F8F8 KLINGON DIGIT EIGHT U F8F9 KLINGON DIGIT NINE  U F8FD KLINGON COMMA U F8FE KLINGON FULL STOP U F8FF KLINGON SYMBOL FOR EMPIRE                                                                 Other Fictional and Artificial Scripts                                         Since the assignment of the Klingon Linux Unicode block  a registry of fictional and artificial scripts has been established by John Cowan  jcowan reutershealth com  and Michael Everson  everson evertype com   The ConScript Unicode Registry is accessible at      https   www evertype com standards csur   The ranges used fall at the low end of the End User Zone and can hence not be normatively assigned  but it is recommended that people who wish to encode fictional scripts use these codes  in the interest of interoperability   For Klingon  CSUR has adopted the Linux encoding  The CSUR people are driving adding Tengwar and Cirth into Unicode Plane 1  the addition of Klingon to Unicode Plane 1 has been rejected and so the above encoding remains official


linux organization here this material was not written to be a single coherent The following is a collection of user oriented documents that have been document With luck things will improve quickly over time added to the kernel over time There is as yet little overall order or The Linux kernel user s and administrator s guide This initial section contains overall information including the README

Answer:
=================================================
The Linux kernel user's and administrator's guide
=================================================

The following is a collection of user-oriented documents that have been
added to the kernel over time.  There is, as yet, little overall order or
organization here — this material was not written to be a single, coherent
document!  With luck things will improve quickly over time.

This initial section contains overall information, including the README
file describing the kernel as a whole, documentation on kernel parameters,
etc.

.. toctree::
   :maxdepth: 1

   README
   kernel-parameters
   devices
   sysctl/index

   abi
   features

This section describes CPU vulnerabilities and their mitigations.

.. toctree::
   :maxdepth: 1

   hw-vuln/index

Here is a set of documents aimed at users who are trying to track down
problems and bugs in particular.

.. toctree::
   :maxdepth: 1

   reporting-issues
   reporting-regressions
   quickly-build-trimmed-linux
   verify-bugs-and-bisect-regressions
   bug-hunting
   bug-bisect
   tainted-kernels
   ramoops
   dynamic-debug-howto
   init
   kdump/index
   perf/index
   pstore-blk

This is the beginning of a section with information of interest to
application developers.  Documents covering various aspects of the kernel
ABI will be found here.

.. toctree::
   :maxdepth: 1

   sysfs-rules

This is the beginning of a section with information of interest to
application developers and system integrators doing analysis of the
Linux kernel for safety critical applications. Documents supporting
analysis of kernel interactions with applications, and key kernel
subsystems expectations will be found here.

.. toctree::
   :maxdepth: 1

   workload-tracing

The rest of this manual consists of various unordered guides on how to
configure specific aspects of kernel behavior to your liking.

.. toctree::
   :maxdepth: 1

   acpi/index
   aoe/index
   auxdisplay/index
   bcache
   binderfs
   binfmt-misc
   blockdev/index
   bootconfig
   braille-console
   btmrvl
   cgroup-v1/index
   cgroup-v2
   cifs/index
   clearing-warn-once
   cpu-load
   cputopology
   dell_rbu
   device-mapper/index
   edid
   efi-stub
   ext4
   filesystem-monitoring
   nfs/index
   gpio/index
   highuid
   hw_random
   initrd
   iostats
   java
   jfs
   kernel-per-CPU-kthreads
   laptops/index
   lcd-panel-cgram
   ldm
   lockup-watchdogs
   LSM/index
   md
   media/index
   mm/index
   module-signing
   mono
   namespaces/index
   numastat
   parport
   perf-security
   pm/index
   pnp
   rapidio
   RAS/index
   rtc
   serial-console
   svga
   syscall-user-dispatch
   sysrq
   thermal/index
   thunderbolt
   ufs
   unicode
   vga-softcursor
   video-output
   xfs

.. only::  subproject and html

   Indices
   =======

   * :ref:`genindex`

The Linux kernel user s and administrator s guide                                                    The following is a collection of user oriented documents that have been added to the kernel over time   There is  as yet  little overall order or organization here   this material was not written to be a single  coherent document   With luck things will improve quickly over time   This initial section contains overall information  including the README file describing the kernel as a whole  documentation on kernel parameters  etc      toctree       maxdepth  1     README    kernel parameters    devices    sysctl index     abi    features  This section describes CPU vulnerabilities and their mitigations      toctree       maxdepth  1     hw vuln index  Here is a set of documents aimed at users who are trying to track down problems and bugs in particular      toctree       maxdepth  1     reporting issues    reporting regressions    quickly build trimmed linux    verify bugs and bisect regressions    bug hunting    bug bisect    tainted kernels    ramoops    dynamic debug howto    init    kdump index    perf index    pstore blk  This is the beginning of a section with information of interest to application developers   Documents covering various aspects of the kernel ABI will be found here      toctree       maxdepth  1     sysfs rules  This is the beginning of a section with information of interest to application developers and system integrators doing analysis of the Linux kernel for safety critical applications  Documents supporting analysis of kernel interactions with applications  and key kernel subsystems expectations will be found here      toctree       maxdepth  1     workload tracing  The rest of this manual consists of various unordered guides on how to configure specific aspects of kernel behavior to your liking      toctree       maxdepth  1     acpi index    aoe index    auxdisplay index    bcache    binderfs    binfmt misc    blockdev index    bootconfig    braille console    btmrvl    cgroup v1 index    cgroup v2    cifs index    clearing warn once    cpu load    cputopology    dell rbu    device mapper index    edid    efi stub    ext4    filesystem monitoring    nfs index    gpio index    highuid    hw random    initrd    iostats    java    jfs    kernel per CPU kthreads    laptops index    lcd panel cgram    ldm    lockup watchdogs    LSM index    md    media index    mm index    module signing    mono    namespaces index    numastat    parport    perf security    pm index    pnp    rapidio    RAS index    rtc    serial console    svga    syscall user dispatch    sysrq    thermal index    thunderbolt    ufs    unicode    vga softcursor    video output    xfs     only    subproject and html     Indices                   ref  genindex


linux and depends on internal kernel structures and layout It is agreed upon may not be stable across kernel releases internal API Therefore there are aspects of the sysfs interface that The kernel exported sysfs exports internal kernel implementation details Rules on how to access information in sysfs by the kernel developers that the Linux kernel does not provide a stable To minimize the risk of breaking users of sysfs which are in most cases

Answer:
Rules on how to access information in sysfs
===========================================

The kernel-exported sysfs exports internal kernel implementation details
and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable
internal API. Therefore, there are aspects of the sysfs interface that
may not be stable across kernel releases.

To minimize the risk of breaking users of sysfs, which are in most cases
low-level userspace applications, with a new kernel release, the users
of sysfs must follow some rules to use an as-abstract-as-possible way to
access this filesystem. The current udev and HAL programs already
implement this and users are encouraged to plug, if possible, into the
abstractions these programs provide instead of accessing sysfs directly.

But if you really do want or need to access sysfs directly, please follow
the following rules and then your programs should work with future
versions of the sysfs interface.

- Do not use libsysfs
    It makes assumptions about sysfs which are not true. Its API does not
    offer any abstraction, it exposes all the kernel driver-core
    implementation details in its own API. Therefore it is not better than
    reading directories and opening the files yourself.
    Also, it is not actively maintained, in the sense of reflecting the
    current kernel development. The goal of providing a stable interface
    to sysfs has failed; it causes more problems than it solves. It
    violates many of the rules in this document.

- sysfs is always at ``/sys``
    Parsing ``/proc/mounts`` is a waste of time. Other mount points are a
    system configuration bug you should not try to solve. For test cases,
    possibly support a ``SYSFS_PATH`` environment variable to overwrite the
    application's behavior, but never try to search for sysfs. Never try
    to mount it, if you are not an early boot script.

- devices are only "devices"
    There is no such thing like class-, bus-, physical devices,
    interfaces, and such that you can rely on in userspace. Everything is
    just simply a "device". Class-, bus-, physical, ... types are just
    kernel implementation details which should not be expected by
    applications that look for devices in sysfs.

    The properties of a device are:

    - devpath (``/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0``)

      - identical to the DEVPATH value in the event sent from the kernel
        at device creation and removal
      - the unique key to the device at that point in time
      - the kernel's path to the device directory without the leading
        ``/sys``, and always starting with a slash
      - all elements of a devpath must be real directories. Symlinks
        pointing to /sys/devices must always be resolved to their real
        target and the target path must be used to access the device.
        That way the devpath to the device matches the devpath of the
        kernel used at event time.
      - using or exposing symlink values as elements in a devpath string
        is a bug in the application

    - kernel name (``sda``, ``tty``, ``0000:00:1f.2``, ...)

      - a directory name, identical to the last element of the devpath
      - applications need to handle spaces and characters like ``!`` in
        the name

    - subsystem (``block``, ``tty``, ``pci``, ...)

      - simple string, never a path or a link
      - retrieved by reading the "subsystem"-link and using only the
        last element of the target path

    - driver (``tg3``, ``ata_piix``, ``uhci_hcd``)

      - a simple string, which may contain spaces, never a path or a
        link
      - it is retrieved by reading the "driver"-link and using only the
        last element of the target path
      - devices which do not have "driver"-link just do not have a
        driver; copying the driver value in a child device context is a
        bug in the application

    - attributes

      - the files in the device directory or files below subdirectories
        of the same device directory
      - accessing attributes reached by a symlink pointing to another device,
        like the "device"-link, is a bug in the application

    Everything else is just a kernel driver-core implementation detail
    that should not be assumed to be stable across kernel releases.

- Properties of parent devices never belong into a child device.
    Always look at the parent devices themselves for determining device
    context properties. If the device ``eth0`` or ``sda`` does not have a
    "driver"-link, then this device does not have a driver. Its value is empty.
    Never copy any property of the parent-device into a child-device. Parent
    device properties may change dynamically without any notice to the
    child device.

- Hierarchy in a single device tree
    There is only one valid place in sysfs where hierarchy can be examined
    and this is below: ``/sys/devices.``
    It is planned that all device directories will end up in the tree
    below this directory.

- Classification by subsystem
    There are currently three places for classification of devices:
    ``/sys/block,`` ``/sys/class`` and ``/sys/bus.`` It is planned that these will
    not contain any device directories themselves, but only flat lists of
    symlinks pointing to the unified ``/sys/devices`` tree.
    All three places have completely different rules on how to access
    device information. It is planned to merge all three
    classification directories into one place at ``/sys/subsystem``,
    following the layout of the bus directories. All buses and
    classes, including the converted block subsystem, will show up
    there.
    The devices belonging to a subsystem will create a symlink in the
    "devices" directory at ``/sys/subsystem/<name>/devices``,

    If ``/sys/subsystem`` exists, ``/sys/bus``, ``/sys/class`` and ``/sys/block``
    can be ignored. If it does not exist, you always have to scan all three
    places, as the kernel is free to move a subsystem from one place to
    the other, as long as the devices are still reachable by the same
    subsystem name.

    Assuming ``/sys/class/<subsystem>`` and ``/sys/bus/<subsystem>``, or
    ``/sys/block`` and ``/sys/class/block`` are not interchangeable is a bug in
    the application.

- Block
    The converted block subsystem at ``/sys/class/block`` or
    ``/sys/subsystem/block`` will contain the links for disks and partitions
    at the same level, never in a hierarchy. Assuming the block subsystem to
    contain only disks and not partition devices in the same flat list is
    a bug in the application.

- "device"-link and <subsystem>:<kernel name>-links
    Never depend on the "device"-link. The "device"-link is a workaround
    for the old layout, where class devices are not created in
    ``/sys/devices/`` like the bus devices. If the link-resolving of a
    device directory does not end in ``/sys/devices/``, you can use the
    "device"-link to find the parent devices in ``/sys/devices/``, That is the
    single valid use of the "device"-link; it must never appear in any
    path as an element. Assuming the existence of the "device"-link for
    a device in ``/sys/devices/`` is a bug in the application.
    Accessing ``/sys/class/net/eth0/device`` is a bug in the application.

    Never depend on the class-specific links back to the ``/sys/class``
    directory.  These links are also a workaround for the design mistake
    that class devices are not created in ``/sys/devices.`` If a device
    directory does not contain directories for child devices, these links
    may be used to find the child devices in ``/sys/class.`` That is the single
    valid use of these links; they must never appear in any path as an
    element. Assuming the existence of these links for devices which are
    real child device directories in the ``/sys/devices`` tree is a bug in
    the application.

    It is planned to remove all these links when all class device
    directories live in ``/sys/devices.``

- Position of devices along device chain can change.
    Never depend on a specific parent device position in the devpath,
    or the chain of parent devices. The kernel is free to insert devices into
    the chain. You must always request the parent device you are looking for
    by its subsystem value. You need to walk up the chain until you find
    the device that matches the expected subsystem. Depending on a specific
    position of a parent device or exposing relative paths using ``../`` to
    access the chain of parents is a bug in the application.

- When reading and writing sysfs device attribute files, avoid dependency
    on specific error codes wherever possible. This minimizes coupling to
    the error handling implementation within the kernel.

    In general, failures to read or write sysfs device attributes shall
    propagate errors wherever possible. Common errors include, but are not
    limited to:

	``-EIO``: The read or store operation is not supported, typically
	returned by the sysfs system itself if the read or store pointer
	is ``NULL``.

	``-ENXIO``: The read or store operation failed

    Error codes will not be changed without good reason, and should a change
    to error codes result in user-space breakage, it will be fixed, or the
    the offending change will be reverted.

    Userspace applications can, however, expect the format and contents of
    the attribute files to remain consistent in the absence of a version
    attribute change in the context of a given attribute.

Rules on how to access information in sysfs                                              The kernel exported sysfs exports internal kernel implementation details and depends on internal kernel structures and layout  It is agreed upon by the kernel developers that the Linux kernel does not provide a stable internal API  Therefore  there are aspects of the sysfs interface that may not be stable across kernel releases   To minimize the risk of breaking users of sysfs  which are in most cases low level userspace applications  with a new kernel release  the users of sysfs must follow some rules to use an as abstract as possible way to access this filesystem  The current udev and HAL programs already implement this and users are encouraged to plug  if possible  into the abstractions these programs provide instead of accessing sysfs directly   But if you really do want or need to access sysfs directly  please follow the following rules and then your programs should work with future versions of the sysfs interface     Do not use libsysfs     It makes assumptions about sysfs which are not true  Its API does not     offer any abstraction  it exposes all the kernel driver core     implementation details in its own API  Therefore it is not better than     reading directories and opening the files yourself      Also  it is not actively maintained  in the sense of reflecting the     current kernel development  The goal of providing a stable interface     to sysfs has failed  it causes more problems than it solves  It     violates many of the rules in this document     sysfs is always at    sys       Parsing    proc mounts   is a waste of time  Other mount points are a     system configuration bug you should not try to solve  For test cases      possibly support a   SYSFS PATH   environment variable to overwrite the     application s behavior  but never try to search for sysfs  Never try     to mount it  if you are not an early boot script     devices are only  devices      There is no such thing like class   bus   physical devices      interfaces  and such that you can rely on in userspace  Everything is     just simply a  device   Class   bus   physical      types are just     kernel implementation details which should not be expected by     applications that look for devices in sysfs       The properties of a device are         devpath     devices pci0000 00 0000 00 1d 1 usb2 2 2 2 2 1 0             identical to the DEVPATH value in the event sent from the kernel         at device creation and removal         the unique key to the device at that point in time         the kernel s path to the device directory without the leading            sys    and always starting with a slash         all elements of a devpath must be real directories  Symlinks         pointing to  sys devices must always be resolved to their real         target and the target path must be used to access the device          That way the devpath to the device matches the devpath of the         kernel used at event time          using or exposing symlink values as elements in a devpath string         is a bug in the application        kernel name    sda      tty      0000 00 1f 2                  a directory name  identical to the last element of the devpath         applications need to handle spaces and characters like       in         the name        subsystem    block      tty      pci                  simple string  never a path or a link         retrieved by reading the  subsystem  link and using only the         last element of the target path        driver    tg3      ata piix      uhci hcd             a simple string  which may contain spaces  never a path or a         link         it is retrieved by reading the  driver  link and using only the         last element of the target path         devices which do not have  driver  link just do not have a         driver  copying the driver value in a child device context is a         bug in the application        attributes          the files in the device directory or files below subdirectories         of the same device directory         accessing attributes reached by a symlink pointing to another device          like the  device  link  is a bug in the application      Everything else is just a kernel driver core implementation detail     that should not be assumed to be stable across kernel releases     Properties of parent devices never belong into a child device      Always look at the parent devices themselves for determining device     context properties  If the device   eth0   or   sda   does not have a      driver  link  then this device does not have a driver  Its value is empty      Never copy any property of the parent device into a child device  Parent     device properties may change dynamically without any notice to the     child device     Hierarchy in a single device tree     There is only one valid place in sysfs where hierarchy can be examined     and this is below     sys devices        It is planned that all device directories will end up in the tree     below this directory     Classification by subsystem     There are currently three places for classification of devices         sys block       sys class   and    sys bus    It is planned that these will     not contain any device directories themselves  but only flat lists of     symlinks pointing to the unified    sys devices   tree      All three places have completely different rules on how to access     device information  It is planned to merge all three     classification directories into one place at    sys subsystem        following the layout of the bus directories  All buses and     classes  including the converted block subsystem  will show up     there      The devices belonging to a subsystem will create a symlink in the      devices  directory at    sys subsystem  name  devices         If    sys subsystem   exists     sys bus       sys class   and    sys block       can be ignored  If it does not exist  you always have to scan all three     places  as the kernel is free to move a subsystem from one place to     the other  as long as the devices are still reachable by the same     subsystem name       Assuming    sys class  subsystem    and    sys bus  subsystem     or        sys block   and    sys class block   are not interchangeable is a bug in     the application     Block     The converted block subsystem at    sys class block   or        sys subsystem block   will contain the links for disks and partitions     at the same level  never in a hierarchy  Assuming the block subsystem to     contain only disks and not partition devices in the same flat list is     a bug in the application      device  link and  subsystem   kernel name  links     Never depend on the  device  link  The  device  link is a workaround     for the old layout  where class devices are not created in        sys devices    like the bus devices  If the link resolving of a     device directory does not end in    sys devices     you can use the      device  link to find the parent devices in    sys devices     That is the     single valid use of the  device  link  it must never appear in any     path as an element  Assuming the existence of the  device  link for     a device in    sys devices    is a bug in the application      Accessing    sys class net eth0 device   is a bug in the application       Never depend on the class specific links back to the    sys class       directory   These links are also a workaround for the design mistake     that class devices are not created in    sys devices    If a device     directory does not contain directories for child devices  these links     may be used to find the child devices in    sys class    That is the single     valid use of these links  they must never appear in any path as an     element  Assuming the existence of these links for devices which are     real child device directories in the    sys devices   tree is a bug in     the application       It is planned to remove all these links when all class device     directories live in    sys devices       Position of devices along device chain can change      Never depend on a specific parent device position in the devpath      or the chain of parent devices  The kernel is free to insert devices into     the chain  You must always request the parent device you are looking for     by its subsystem value  You need to walk up the chain until you find     the device that matches the expected subsystem  Depending on a specific     position of a parent device or exposing relative paths using         to     access the chain of parents is a bug in the application     When reading and writing sysfs device attribute files  avoid dependency     on specific error codes wherever possible  This minimizes coupling to     the error handling implementation within the kernel       In general  failures to read or write sysfs device attributes shall     propagate errors wherever possible  Common errors include  but are not     limited to       EIO    The read or store operation is not supported  typically  returned by the sysfs system itself if the read or store pointer  is   NULL         ENXIO    The read or store operation failed      Error codes will not be changed without good reason  and should a change     to error codes result in user space breakage  it will be fixed  or the     the offending change will be reverted       Userspace applications can  however  expect the format and contents of     the attribute files to remain consistent in the absence of a version     attribute change in the context of a given attribute


linux Ext4 is an advanced level of the ext3 filesystem which incorporates scalability and reliability enhancements for supporting large filesystems 64 bit in keeping with increasing disk capacities and state of the art feature requirements ext4 General Information SPDX License Identifier GPL 2 0

Answer:
.. SPDX-License-Identifier: GPL-2.0

========================
ext4 General Information
========================

Ext4 is an advanced level of the ext3 filesystem which incorporates
scalability and reliability enhancements for supporting large filesystems
(64 bit) in keeping with increasing disk capacities and state-of-the-art
feature requirements.

Mailing list:	linux-ext4@vger.kernel.org
Web site:	http://ext4.wiki.kernel.org

Quick usage instructions
========================

Note: More extensive information for getting started with ext4 can be
found at the ext4 wiki site at the URL:
http://ext4.wiki.kernel.org/index.php/Ext4_Howto

  - The latest version of e2fsprogs can be found at:

    https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/

	or

    http://sourceforge.net/project/showfiles.php?group_id=2406

	or grab the latest git repository from:

   https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

  - Create a new filesystem using the ext4 filesystem type:

        # mke2fs -t ext4 /dev/hda1

    Or to configure an existing ext3 filesystem to support extents:

	# tune2fs -O extents /dev/hda1

    If the filesystem was created with 128 byte inodes, it can be
    converted to use 256 byte for greater efficiency via:

        # tune2fs -I 256 /dev/hda1

  - Mounting:

	# mount -t ext4 /dev/hda1 /wherever

  - When comparing performance with other filesystems, it's always
    important to try multiple workloads; very often a subtle change in a
    workload parameter can completely change the ranking of which
    filesystems do well compared to others.  When comparing versus ext3,
    note that ext4 enables write barriers by default, while ext3 does
    not enable write barriers by default.  So it is useful to use
    explicitly specify whether barriers are enabled or not when via the
    '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems
    for a fair comparison.  When tuning ext3 for best benchmark numbers,
    it is often worthwhile to try changing the data journaling mode; '-o
    data=writeback' can be faster for some workloads.  (Note however that
    running mounted with data=writeback can potentially leave stale data
    exposed in recently written files in case of an unclean shutdown,
    which could be a security exposure in some situations.)  Configuring
    the filesystem with a large journal can also be helpful for
    metadata-intensive workloads.

Features
========

Currently Available
-------------------

* ability to use filesystems > 16TB (e2fsprogs support not available yet)
* extent format reduces metadata overhead (RAM, IO for access, transactions)
* extent format more robust in face of on-disk corruption due to magics,
* internal redundancy in tree
* improved file allocation (multi-block alloc)
* lift 32000 subdirectory limit imposed by i_links_count[1]
* nsec timestamps for mtime, atime, ctime, create time
* inode version field on disk (NFSv4, Lustre)
* reduced e2fsck time via uninit_bg feature
* journal checksumming for robustness, performance
* persistent file preallocation (e.g for streaming media, databases)
* ability to pack bitmaps and inode tables into larger virtual groups via the
  flex_bg feature
* large file support
* inode allocation using large virtual block groups via flex_bg
* delayed allocation
* large block (up to pagesize) support
* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force
  the ordering)
* Case-insensitive file name lookups
* file-based encryption support (fscrypt)
* file-based verity support (fsverity)

[1] Filesystems with a block size of 1k may see a limit imposed by the
directory hash tree having a maximum depth of two.

case-insensitive file name lookups
======================================================

The case-insensitive file name lookup feature is supported on a
per-directory basis, allowing the user to mix case-insensitive and
case-sensitive directories in the same filesystem.  It is enabled by
flipping the +F inode attribute of an empty directory.  The
case-insensitive string match operation is only defined when we know how
text in encoded in a byte sequence.  For that reason, in order to enable
case-insensitive directories, the filesystem must have the
casefold feature, which stores the filesystem-wide encoding
model used.  By default, the charset adopted is the latest version of
Unicode (12.1.0, by the time of this writing), encoded in the UTF-8
form.  The comparison algorithm is implemented by normalizing the
strings to the Canonical decomposition form, as defined by Unicode,
followed by a byte per byte comparison.

The case-awareness is name-preserving on the disk, meaning that the file
name provided by userspace is a byte-per-byte match to what is actually
written in the disk.  The Unicode normalization format used by the
kernel is thus an internal representation, and not exposed to the
userspace nor to the disk, with the important exception of disk hashes,
used on large case-insensitive directories with DX feature.  On DX
directories, the hash must be calculated using the casefolded version of
the filename, meaning that the normalization format used actually has an
impact on where the directory entry is stored.

When we change from viewing filenames as opaque byte sequences to seeing
them as encoded strings we need to address what happens when a program
tries to create a file with an invalid name.  The Unicode subsystem
within the kernel leaves the decision of what to do in this case to the
filesystem, which select its preferred behavior by enabling/disabling
the strict mode.  When Ext4 encounters one of those strings and the
filesystem did not require strict mode, it falls back to considering the
entire string as an opaque byte sequence, which still allows the user to
operate on that file, but the case-insensitive lookups won't work.

Options
=======

When mounting an ext4 filesystem, the following option are accepted:
(*) == default

  ro
        Mount filesystem read only. Note that ext4 will replay the journal (and
        thus write to the partition) even when mounted "read only". The mount
        options "ro,noload" can be used to prevent writes to the filesystem.

  journal_checksum
        Enable checksumming of the journal transactions.  This will allow the
        recovery code in e2fsck and the kernel to detect corruption in the
        kernel.  It is a compatible change and will be ignored by older
        kernels.

  journal_async_commit
        Commit block can be written to disk without waiting for descriptor
        blocks. If enabled older kernels cannot mount the device. This will
        enable 'journal_checksum' internally.

  journal_path=path, journal_dev=devnum
        When the external journal device's major/minor numbers have changed,
        these options allow the user to specify the new journal location.  The
        journal device is identified through either its new major/minor numbers
        encoded in devnum, or via a path to the device.

  norecovery, noload
        Don't load the journal on mounting.  Note that if the filesystem was
        not unmounted cleanly, skipping the journal replay will lead to the
        filesystem containing inconsistencies that can lead to any number of
        problems.

  data=journal
        All data are committed into the journal prior to being written into the
        main file system.  Enabling this mode will disable delayed allocation
        and O_DIRECT support.

  data=ordered	(*)
        All data are forced directly out to the main file system prior to its
        metadata being committed to the journal.

  data=writeback
        Data ordering is not preserved, data may be written into the main file
        system after its metadata has been committed to the journal.

  commit=nrsec	(*)
        This setting limits the maximum age of the running transaction to
        'nrsec' seconds.  The default value is 5 seconds.  This means that if
        you lose your power, you will lose as much as the latest 5 seconds of
        metadata changes (your filesystem will not be damaged though, thanks
        to the journaling). This default value (or any low value) will hurt
        performance, but it's good for data-safety.  Setting it to 0 will have
        the same effect as leaving it at the default (5 seconds).  Setting it
        to very large values will improve performance.  Note that due to
        delayed allocation even older data can be lost on power failure since
        writeback of those data begins only after time set in
        /proc/sys/vm/dirty_expire_centisecs.

  barrier=<0|1(*)>, barrier(*), nobarrier
        This enables/disables the use of write barriers in the jbd code.
        barrier=0 disables, barrier=1 enables.  This also requires an IO stack
        which can support barriers, and if jbd gets an error on a barrier
        write, it will disable again with a warning.  Write barriers enforce
        proper on-disk ordering of journal commits, making volatile disk write
        caches safe to use, at some performance penalty.  If your disks are
        battery-backed in one way or another, disabling barriers may safely
        improve performance.  The mount options "barrier" and "nobarrier" can
        also be used to enable or disable barriers, for consistency with other
        ext4 mount options.

  inode_readahead_blks=n
        This tuning parameter controls the maximum number of inode table blocks
        that ext4's inode table readahead algorithm will pre-read into the
        buffer cache.  The default value is 32 blocks.

  bsddf	(*)
        Make 'df' act like BSD.

  minixdf
        Make 'df' act like Minix.

  debug
        Extra debugging information is sent to syslog.

  abort
        Simulate the effects of calling ext4_abort() for debugging purposes.
        This is normally used while remounting a filesystem which is already
        mounted.

  errors=remount-ro
        Remount the filesystem read-only on an error.

  errors=continue
        Keep going on a filesystem error.

  errors=panic
        Panic and halt the machine if an error occurs.  (These mount options
        override the errors behavior specified in the superblock, which can be
        configured using tune2fs)

  data_err=ignore(*)
        Just print an error message if an error occurs in a file data buffer in
        ordered mode.
  data_err=abort
        Abort the journal if an error occurs in a file data buffer in ordered
        mode.

  grpid | bsdgroups
        New objects have the group ID of their parent.

  nogrpid (*) | sysvgroups
        New objects have the group ID of their creator.

  resgid=n
        The group ID which may use the reserved blocks.

  resuid=n
        The user ID which may use the reserved blocks.

  sb=
        Use alternate superblock at this location.

  quota, noquota, grpquota, usrquota
        These options are ignored by the filesystem. They are used only by
        quota tools to recognize volumes where quota should be turned on. See
        documentation in the quota-tools package for more details
        (http://sourceforge.net/projects/linuxquota).

  jqfmt=<quota type>, usrjquota=<file>, grpjquota=<file>
        These options tell filesystem details about quota so that quota
        information can be properly updated during journal replay. They replace
        the above quota options. See documentation in the quota-tools package
        for more details (http://sourceforge.net/projects/linuxquota).

  stripe=n
        Number of filesystem blocks that mballoc will try to use for allocation
        size and alignment. For RAID5/6 systems this should be the number of
        data disks *  RAID chunk size in file system blocks.

  delalloc	(*)
        Defer block allocation until just before ext4 writes out the block(s)
        in question.  This allows ext4 to better allocation decisions more
        efficiently.

  nodelalloc
        Disable delayed allocation.  Blocks are allocated when the data is
        copied from userspace to the page cache, either via the write(2) system
        call or when an mmap'ed page which was previously unallocated is
        written for the first time.

  max_batch_time=usec
        Maximum amount of time ext4 should wait for additional filesystem
        operations to be batch together with a synchronous write operation.
        Since a synchronous write operation is going to force a commit and then
        a wait for the I/O complete, it doesn't cost much, and can be a huge
        throughput win, we wait for a small amount of time to see if any other
        transactions can piggyback on the synchronous write.   The algorithm
        used is designed to automatically tune for the speed of the disk, by
        measuring the amount of time (on average) that it takes to finish
        committing a transaction.  Call this time the "commit time".  If the
        time that the transaction has been running is less than the commit
        time, ext4 will try sleeping for the commit time to see if other
        operations will join the transaction.   The commit time is capped by
        the max_batch_time, which defaults to 15000us (15ms).   This
        optimization can be turned off entirely by setting max_batch_time to 0.

  min_batch_time=usec
        This parameter sets the commit time (as described above) to be at least
        min_batch_time.  It defaults to zero microseconds.  Increasing this
        parameter may improve the throughput of multi-threaded, synchronous
        workloads on very fast disks, at the cost of increasing latency.

  journal_ioprio=prio
        The I/O priority (from 0 to 7, where 0 is the highest priority) which
        should be used for I/O operations submitted by kjournald2 during a
        commit operation.  This defaults to 3, which is a slightly higher
        priority than the default I/O priority.

  auto_da_alloc(*), noauto_da_alloc
        Many broken applications don't use fsync() when replacing existing
        files via patterns such as fd = open("foo.new")/write(fd,..)/close(fd)/
        rename("foo.new", "foo"), or worse yet, fd = open("foo",
        O_TRUNC)/write(fd,..)/close(fd).  If auto_da_alloc is enabled, ext4
        will detect the replace-via-rename and replace-via-truncate patterns
        and force that any delayed allocation blocks are allocated such that at
        the next journal commit, in the default data=ordered mode, the data
        blocks of the new file are forced to disk before the rename() operation
        is committed.  This provides roughly the same level of guarantees as
        ext3, and avoids the "zero-length" problem that can happen when a
        system crashes before the delayed allocation blocks are forced to disk.

  noinit_itable
        Do not initialize any uninitialized inode table blocks in the
        background.  This feature may be used by installation CD's so that the
        install process can complete as quickly as possible; the inode table
        initialization process would then be deferred until the next time the
        file system is unmounted.

  init_itable=n
        The lazy itable init code will wait n times the number of milliseconds
        it took to zero out the previous block group's inode table.  This
        minimizes the impact on the system performance while file system's
        inode table is being initialized.

  discard, nodiscard(*)
        Controls whether ext4 should issue discard/TRIM commands to the
        underlying block device when blocks are freed.  This is useful for SSD
        devices and sparse/thinly-provisioned LUNs, but it is off by default
        until sufficient testing has been done.

  nouid32
        Disables 32-bit UIDs and GIDs.  This is for interoperability  with
        older kernels which only store and expect 16-bit values.

  block_validity(*), noblock_validity
        These options enable or disable the in-kernel facility for tracking
        filesystem metadata blocks within internal data structures.  This
        allows multi- block allocator and other routines to notice bugs or
        corrupted allocation bitmaps which cause blocks to be allocated which
        overlap with filesystem metadata blocks.

  dioread_lock, dioread_nolock
        Controls whether or not ext4 should use the DIO read locking. If the
        dioread_nolock option is specified ext4 will allocate uninitialized
        extent before buffer write and convert the extent to initialized after
        IO completes. This approach allows ext4 code to avoid using inode
        mutex, which improves scalability on high speed storages. However this
        does not work with data journaling and dioread_nolock option will be
        ignored with kernel warning. Note that dioread_nolock code path is only
        used for extent-based files.  Because of the restrictions this options
        comprises it is off by default (e.g. dioread_lock).

  max_dir_size_kb=n
        This limits the size of directories so that any attempt to expand them
        beyond the specified limit in kilobytes will cause an ENOSPC error.
        This is useful in memory constrained environments, where a very large
        directory can cause severe performance problems or even provoke the Out
        Of Memory killer.  (For example, if there is only 512mb memory
        available, a 176mb directory may seriously cramp the system's style.)

  i_version
        Enable 64-bit inode version support. This option is off by default.

  dax
        Use direct access (no page cache).  See
        Documentation/filesystems/dax.rst.  Note that this option is
        incompatible with data=journal.

  inlinecrypt
        When possible, encrypt/decrypt the contents of encrypted files using the
        blk-crypto framework rather than filesystem-layer encryption. This
        allows the use of inline encryption hardware. The on-disk format is
        unaffected. For more details, see
        Documentation/block/inline-encryption.rst.

Data Mode
=========
There are 3 different data modes:

* writeback mode

  In data=writeback mode, ext4 does not journal data at all.  This mode provides
  a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
  mode - metadata journaling.  A crash+recovery can cause incorrect data to
  appear in files which were written shortly before the crash.  This mode will
  typically provide the best ext4 performance.

* ordered mode

  In data=ordered mode, ext4 only officially journals metadata, but it logically
  groups metadata information related to data changes with the data blocks into
  a single unit called a transaction.  When it's time to write the new metadata
  out to disk, the associated data blocks are written first.  In general, this
  mode performs slightly slower than writeback but significantly faster than
  journal mode.

* journal mode

  data=journal mode provides full data and metadata journaling.  All new data is
  written to the journal first, and then to its final location.  In the event of
  a crash, the journal can be replayed, bringing both data and metadata into a
  consistent state.  This mode is the slowest except when data needs to be read
  from and written to disk at the same time where it outperforms all others
  modes.  Enabling this mode will disable delayed allocation and O_DIRECT
  support.

/proc entries
=============

Information about mounted ext4 file systems can be found in
/proc/fs/ext4.  Each mounted filesystem will have a directory in
/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
/proc/fs/ext4/dm-0).   The files in each per-device directory are shown
in table below.

Files in /proc/fs/ext4/<devname>

  mb_groups
        details of multiblock allocator buddy cache of free blocks

/sys entries
============

Information about mounted ext4 file systems can be found in
/sys/fs/ext4.  Each mounted filesystem will have a directory in
/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or
/sys/fs/ext4/dm-0).   The files in each per-device directory are shown
in table below.

Files in /sys/fs/ext4/<devname>:

(see also Documentation/ABI/testing/sysfs-fs-ext4)

  delayed_allocation_blocks
        This file is read-only and shows the number of blocks that are dirty in
        the page cache, but which do not have their location in the filesystem
        allocated yet.

  inode_goal
        Tuning parameter which (if non-zero) controls the goal inode used by
        the inode allocator in preference to all other allocation heuristics.
        This is intended for debugging use only, and should be 0 on production
        systems.

  inode_readahead_blks
        Tuning parameter which controls the maximum number of inode table
        blocks that ext4's inode table readahead algorithm will pre-read into
        the buffer cache.

  lifetime_write_kbytes
        This file is read-only and shows the number of kilobytes of data that
        have been written to this filesystem since it was created.

  max_writeback_mb_bump
        The maximum number of megabytes the writeback code will try to write
        out before move on to another inode.

  mb_group_prealloc
        The multiblock allocator will round up allocation requests to a
        multiple of this tuning parameter if the stripe size is not set in the
        ext4 superblock

  mb_max_to_scan
        The maximum number of extents the multiblock allocator will search to
        find the best extent.

  mb_min_to_scan
        The minimum number of extents the multiblock allocator will search to
        find the best extent.

  mb_order2_req
        Tuning parameter which controls the minimum size for requests (as a
        power of 2) where the buddy cache is used.

  mb_stats
        Controls whether the multiblock allocator should collect statistics,
        which are shown during the unmount. 1 means to collect statistics, 0
        means not to collect statistics.

  mb_stream_req
        Files which have fewer blocks than this tunable parameter will have
        their blocks allocated out of a block group specific preallocation
        pool, so that small files are packed closely together.  Each large file
        will have its blocks allocated out of its own unique preallocation
        pool.

  session_write_kbytes
        This file is read-only and shows the number of kilobytes of data that
        have been written to this filesystem since it was mounted.

  reserved_clusters
        This is RW file and contains number of reserved clusters in the file
        system which will be used in the specific situations to avoid costly
        zeroout, unexpected ENOSPC, or possible data loss. The default is 2% or
        4096 clusters, whichever is smaller and this can be changed however it
        can never exceed number of clusters in the file system. If there is not
        enough space for the reserved space when mounting the file mount will
        _not_ fail.

Ioctls
======

Ext4 implements various ioctls which can be used by applications to access
ext4-specific functionality. An incomplete list of these ioctls is shown in the
table below. This list includes truly ext4-specific ioctls (``EXT4_IOC_*``) as
well as ioctls that may have been ext4-specific originally but are now supported
by some other filesystem(s) too (``FS_IOC_*``).

Table of Ext4 ioctls

  FS_IOC_GETFLAGS
        Get additional attributes associated with inode.  The ioctl argument is
        an integer bitfield, with bit values described in ext4.h.

  FS_IOC_SETFLAGS
        Set additional attributes associated with inode.  The ioctl argument is
        an integer bitfield, with bit values described in ext4.h.

  EXT4_IOC_GETVERSION, EXT4_IOC_GETVERSION_OLD
        Get the inode i_generation number stored for each inode. The
        i_generation number is normally changed only when new inode is created
        and it is particularly useful for network filesystems. The '_OLD'
        version of this ioctl is an alias for FS_IOC_GETVERSION.

  EXT4_IOC_SETVERSION, EXT4_IOC_SETVERSION_OLD
        Set the inode i_generation number stored for each inode. The '_OLD'
        version of this ioctl is an alias for FS_IOC_SETVERSION.

  EXT4_IOC_GROUP_EXTEND
        This ioctl has the same purpose as the resize mount option. It allows
        to resize filesystem to the end of the last existing block group,
        further resize has to be done with resize2fs, either online, or
        offline. The argument points to the unsigned logn number representing
        the filesystem new block count.

  EXT4_IOC_MOVE_EXT
        Move the block extents from orig_fd (the one this ioctl is pointing to)
        to the donor_fd (the one specified in move_extent structure passed as
        an argument to this ioctl). Then, exchange inode metadata between
        orig_fd and donor_fd.  This is especially useful for online
        defragmentation, because the allocator has the opportunity to allocate
        moved blocks better, ideally into one contiguous extent.

  EXT4_IOC_GROUP_ADD
        Add a new group descriptor to an existing or new group descriptor
        block. The new group descriptor is described by ext4_new_group_input
        structure, which is passed as an argument to this ioctl. This is
        especially useful in conjunction with EXT4_IOC_GROUP_EXTEND, which
        allows online resize of the filesystem to the end of the last existing
        block group.  Those two ioctls combined is used in userspace online
        resize tool (e.g. resize2fs).

  EXT4_IOC_MIGRATE
        This ioctl operates on the filesystem itself.  It converts (migrates)
        ext3 indirect block mapped inode to ext4 extent mapped inode by walking
        through indirect block mapping of the original inode and converting
        contiguous block ranges into ext4 extents of the temporary inode. Then,
        inodes are swapped. This ioctl might help, when migrating from ext3 to
        ext4 filesystem, however suggestion is to create fresh ext4 filesystem
        and copy data from the backup. Note, that filesystem has to support
        extents for this ioctl to work.

  EXT4_IOC_ALLOC_DA_BLKS
        Force all of the delay allocated blocks to be allocated to preserve
        application-expected ext3 behaviour. Note that this will also start
        triggering a write of the data blocks, but this behaviour may change in
        the future as it is not necessary and has been done this way only for
        sake of simplicity.

  EXT4_IOC_RESIZE_FS
        Resize the filesystem to a new size.  The number of blocks of resized
        filesystem is passed in via 64 bit integer argument.  The kernel
        allocates bitmaps and inode table, the userspace tool thus just passes
        the new number of blocks.

  EXT4_IOC_SWAP_BOOT
        Swap i_blocks and associated attributes (like i_blocks, i_size,
        i_flags, ...) from the specified inode with inode EXT4_BOOT_LOADER_INO
        (#5). This is typically used to store a boot loader in a secure part of
        the filesystem, where it can't be changed by a normal user by accident.
        The data blocks of the previous boot loader will be associated with the
        given inode.

References
==========

kernel source:	<file:fs/ext4/>
		<file:fs/jbd2/>

programs:	http://e2fsprogs.sourceforge.net/

useful links:	https://fedoraproject.org/wiki/ext3-devel
		http://www.bullopensource.org/ext4/
		http://ext4.wiki.kernel.org/index.php/Main_Page
		https://fedoraproject.org/wiki/Features/Ext4

SPDX License Identifier  GPL 2 0                           ext4 General Information                           Ext4 is an advanced level of the ext3 filesystem which incorporates scalability and reliability enhancements for supporting large filesystems  64 bit  in keeping with increasing disk capacities and state of the art feature requirements   Mailing list  linux ext4 vger kernel org Web site  http   ext4 wiki kernel org   Quick usage instructions                           Note  More extensive information for getting started with ext4 can be found at the ext4 wiki site at the URL  http   ext4 wiki kernel org index php Ext4 Howto      The latest version of e2fsprogs can be found at       https   www kernel org pub linux kernel people tytso e2fsprogs    or      http   sourceforge net project showfiles php group id 2406   or grab the latest git repository from      https   git kernel org pub scm fs ext2 e2fsprogs git      Create a new filesystem using the ext4 filesystem type             mke2fs  t ext4  dev hda1      Or to configure an existing ext3 filesystem to support extents      tune2fs  O extents  dev hda1      If the filesystem was created with 128 byte inodes  it can be     converted to use 256 byte for greater efficiency via             tune2fs  I 256  dev hda1      Mounting      mount  t ext4  dev hda1  wherever      When comparing performance with other filesystems  it s always     important to try multiple workloads  very often a subtle change in a     workload parameter can completely change the ranking of which     filesystems do well compared to others   When comparing versus ext3      note that ext4 enables write barriers by default  while ext3 does     not enable write barriers by default   So it is useful to use     explicitly specify whether barriers are enabled or not when via the       o barriers  0 1   mount option for both ext3 and ext4 filesystems     for a fair comparison   When tuning ext3 for best benchmark numbers      it is often worthwhile to try changing the data journaling mode    o     data writeback  can be faster for some workloads    Note however that     running mounted with data writeback can potentially leave stale data     exposed in recently written files in case of an unclean shutdown      which could be a security exposure in some situations    Configuring     the filesystem with a large journal can also be helpful for     metadata intensive workloads   Features           Currently Available                        ability to use filesystems   16TB  e2fsprogs support not available yet    extent format reduces metadata overhead  RAM  IO for access  transactions    extent format more robust in face of on disk corruption due to magics    internal redundancy in tree   improved file allocation  multi block alloc    lift 32000 subdirectory limit imposed by i links count 1    nsec timestamps for mtime  atime  ctime  create time   inode version field on disk  NFSv4  Lustre    reduced e2fsck time via uninit bg feature   journal checksumming for robustness  performance   persistent file preallocation  e g for streaming media  databases    ability to pack bitmaps and inode tables into larger virtual groups via the   flex bg feature   large file support   inode allocation using large virtual block groups via flex bg   delayed allocation   large block  up to pagesize  support   efficient new ordered mode in JBD2 and ext4  avoid using buffer head to force   the ordering    Case insensitive file name lookups   file based encryption support  fscrypt    file based verity support  fsverity    1  Filesystems with a block size of 1k may see a limit imposed by the directory hash tree having a maximum depth of two   case insensitive file name lookups                                                         The case insensitive file name lookup feature is supported on a per directory basis  allowing the user to mix case insensitive and case sensitive directories in the same filesystem   It is enabled by flipping the  F inode attribute of an empty directory   The case insensitive string match operation is only defined when we know how text in encoded in a byte sequence   For that reason  in order to enable case insensitive directories  the filesystem must have the casefold feature  which stores the filesystem wide encoding model used   By default  the charset adopted is the latest version of Unicode  12 1 0  by the time of this writing   encoded in the UTF 8 form   The comparison algorithm is implemented by normalizing the strings to the Canonical decomposition form  as defined by Unicode  followed by a byte per byte comparison   The case awareness is name preserving on the disk  meaning that the file name provided by userspace is a byte per byte match to what is actually written in the disk   The Unicode normalization format used by the kernel is thus an internal representation  and not exposed to the userspace nor to the disk  with the important exception of disk hashes  used on large case insensitive directories with DX feature   On DX directories  the hash must be calculated using the casefolded version of the filename  meaning that the normalization format used actually has an impact on where the directory entry is stored   When we change from viewing filenames as opaque byte sequences to seeing them as encoded strings we need to address what happens when a program tries to create a file with an invalid name   The Unicode subsystem within the kernel leaves the decision of what to do in this case to the filesystem  which select its preferred behavior by enabling disabling the strict mode   When Ext4 encounters one of those strings and the filesystem did not require strict mode  it falls back to considering the entire string as an opaque byte sequence  which still allows the user to operate on that file  but the case insensitive lookups won t work   Options          When mounting an ext4 filesystem  the following option are accepted         default    ro         Mount filesystem read only  Note that ext4 will replay the journal  and         thus write to the partition  even when mounted  read only   The mount         options  ro noload  can be used to prevent writes to the filesystem     journal checksum         Enable checksumming of the journal transactions   This will allow the         recovery code in e2fsck and the kernel to detect corruption in the         kernel   It is a compatible change and will be ignored by older         kernels     journal async commit         Commit block can be written to disk without waiting for descriptor         blocks  If enabled older kernels cannot mount the device  This will         enable  journal checksum  internally     journal path path  journal dev devnum         When the external journal device s major minor numbers have changed          these options allow the user to specify the new journal location   The         journal device is identified through either its new major minor numbers         encoded in devnum  or via a path to the device     norecovery  noload         Don t load the journal on mounting   Note that if the filesystem was         not unmounted cleanly  skipping the journal replay will lead to the         filesystem containing inconsistencies that can lead to any number of         problems     data journal         All data are committed into the journal prior to being written into the         main file system   Enabling this mode will disable delayed allocation         and O DIRECT support     data ordered             All data are forced directly out to the main file system prior to its         metadata being committed to the journal     data writeback         Data ordering is not preserved  data may be written into the main file         system after its metadata has been committed to the journal     commit nrsec             This setting limits the maximum age of the running transaction to          nrsec  seconds   The default value is 5 seconds   This means that if         you lose your power  you will lose as much as the latest 5 seconds of         metadata changes  your filesystem will not be damaged though  thanks         to the journaling   This default value  or any low value  will hurt         performance  but it s good for data safety   Setting it to 0 will have         the same effect as leaving it at the default  5 seconds    Setting it         to very large values will improve performance   Note that due to         delayed allocation even older data can be lost on power failure since         writeback of those data begins only after time set in          proc sys vm dirty expire centisecs     barrier  0 1      barrier     nobarrier         This enables disables the use of write barriers in the jbd code          barrier 0 disables  barrier 1 enables   This also requires an IO stack         which can support barriers  and if jbd gets an error on a barrier         write  it will disable again with a warning   Write barriers enforce         proper on disk ordering of journal commits  making volatile disk write         caches safe to use  at some performance penalty   If your disks are         battery backed in one way or another  disabling barriers may safely         improve performance   The mount options  barrier  and  nobarrier  can         also be used to enable or disable barriers  for consistency with other         ext4 mount options     inode readahead blks n         This tuning parameter controls the maximum number of inode table blocks         that ext4 s inode table readahead algorithm will pre read into the         buffer cache   The default value is 32 blocks     bsddf             Make  df  act like BSD     minixdf         Make  df  act like Minix     debug         Extra debugging information is sent to syslog     abort         Simulate the effects of calling ext4 abort   for debugging purposes          This is normally used while remounting a filesystem which is already         mounted     errors remount ro         Remount the filesystem read only on an error     errors continue         Keep going on a filesystem error     errors panic         Panic and halt the machine if an error occurs    These mount options         override the errors behavior specified in the superblock  which can be         configured using tune2fs     data err ignore            Just print an error message if an error occurs in a file data buffer in         ordered mode    data err abort         Abort the journal if an error occurs in a file data buffer in ordered         mode     grpid   bsdgroups         New objects have the group ID of their parent     nogrpid       sysvgroups         New objects have the group ID of their creator     resgid n         The group ID which may use the reserved blocks     resuid n         The user ID which may use the reserved blocks     sb          Use alternate superblock at this location     quota  noquota  grpquota  usrquota         These options are ignored by the filesystem  They are used only by         quota tools to recognize volumes where quota should be turned on  See         documentation in the quota tools package for more details          http   sourceforge net projects linuxquota      jqfmt  quota type   usrjquota  file   grpjquota  file          These options tell filesystem details about quota so that quota         information can be properly updated during journal replay  They replace         the above quota options  See documentation in the quota tools package         for more details  http   sourceforge net projects linuxquota      stripe n         Number of filesystem blocks that mballoc will try to use for allocation         size and alignment  For RAID5 6 systems this should be the number of         data disks    RAID chunk size in file system blocks     delalloc             Defer block allocation until just before ext4 writes out the block s          in question   This allows ext4 to better allocation decisions more         efficiently     nodelalloc         Disable delayed allocation   Blocks are allocated when the data is         copied from userspace to the page cache  either via the write 2  system         call or when an mmap ed page which was previously unallocated is         written for the first time     max batch time usec         Maximum amount of time ext4 should wait for additional filesystem         operations to be batch together with a synchronous write operation          Since a synchronous write operation is going to force a commit and then         a wait for the I O complete  it doesn t cost much  and can be a huge         throughput win  we wait for a small amount of time to see if any other         transactions can piggyback on the synchronous write    The algorithm         used is designed to automatically tune for the speed of the disk  by         measuring the amount of time  on average  that it takes to finish         committing a transaction   Call this time the  commit time    If the         time that the transaction has been running is less than the commit         time  ext4 will try sleeping for the commit time to see if other         operations will join the transaction    The commit time is capped by         the max batch time  which defaults to 15000us  15ms     This         optimization can be turned off entirely by setting max batch time to 0     min batch time usec         This parameter sets the commit time  as described above  to be at least         min batch time   It defaults to zero microseconds   Increasing this         parameter may improve the throughput of multi threaded  synchronous         workloads on very fast disks  at the cost of increasing latency     journal ioprio prio         The I O priority  from 0 to 7  where 0 is the highest priority  which         should be used for I O operations submitted by kjournald2 during a         commit operation   This defaults to 3  which is a slightly higher         priority than the default I O priority     auto da alloc     noauto da alloc         Many broken applications don t use fsync   when replacing existing         files via patterns such as fd   open  foo new   write fd     close fd           rename  foo new    foo    or worse yet  fd   open  foo           O TRUNC  write fd     close fd    If auto da alloc is enabled  ext4         will detect the replace via rename and replace via truncate patterns         and force that any delayed allocation blocks are allocated such that at         the next journal commit  in the default data ordered mode  the data         blocks of the new file are forced to disk before the rename   operation         is committed   This provides roughly the same level of guarantees as         ext3  and avoids the  zero length  problem that can happen when a         system crashes before the delayed allocation blocks are forced to disk     noinit itable         Do not initialize any uninitialized inode table blocks in the         background   This feature may be used by installation CD s so that the         install process can complete as quickly as possible  the inode table         initialization process would then be deferred until the next time the         file system is unmounted     init itable n         The lazy itable init code will wait n times the number of milliseconds         it took to zero out the previous block group s inode table   This         minimizes the impact on the system performance while file system s         inode table is being initialized     discard  nodiscard            Controls whether ext4 should issue discard TRIM commands to the         underlying block device when blocks are freed   This is useful for SSD         devices and sparse thinly provisioned LUNs  but it is off by default         until sufficient testing has been done     nouid32         Disables 32 bit UIDs and GIDs   This is for interoperability  with         older kernels which only store and expect 16 bit values     block validity     noblock validity         These options enable or disable the in kernel facility for tracking         filesystem metadata blocks within internal data structures   This         allows multi  block allocator and other routines to notice bugs or         corrupted allocation bitmaps which cause blocks to be allocated which         overlap with filesystem metadata blocks     dioread lock  dioread nolock         Controls whether or not ext4 should use the DIO read locking  If the         dioread nolock option is specified ext4 will allocate uninitialized         extent before buffer write and convert the extent to initialized after         IO completes  This approach allows ext4 code to avoid using inode         mutex  which improves scalability on high speed storages  However this         does not work with data journaling and dioread nolock option will be         ignored with kernel warning  Note that dioread nolock code path is only         used for extent based files   Because of the restrictions this options         comprises it is off by default  e g  dioread lock      max dir size kb n         This limits the size of directories so that any attempt to expand them         beyond the specified limit in kilobytes will cause an ENOSPC error          This is useful in memory constrained environments  where a very large         directory can cause severe performance problems or even provoke the Out         Of Memory killer    For example  if there is only 512mb memory         available  a 176mb directory may seriously cramp the system s style      i version         Enable 64 bit inode version support  This option is off by default     dax         Use direct access  no page cache    See         Documentation filesystems dax rst   Note that this option is         incompatible with data journal     inlinecrypt         When possible  encrypt decrypt the contents of encrypted files using the         blk crypto framework rather than filesystem layer encryption  This         allows the use of inline encryption hardware  The on disk format is         unaffected  For more details  see         Documentation block inline encryption rst   Data Mode           There are 3 different data modes     writeback mode    In data writeback mode  ext4 does not journal data at all   This mode provides   a similar level of journaling as that of XFS  JFS  and ReiserFS in its default   mode   metadata journaling   A crash recovery can cause incorrect data to   appear in files which were written shortly before the crash   This mode will   typically provide the best ext4 performance     ordered mode    In data ordered mode  ext4 only officially journals metadata  but it logically   groups metadata information related to data changes with the data blocks into   a single unit called a transaction   When it s time to write the new metadata   out to disk  the associated data blocks are written first   In general  this   mode performs slightly slower than writeback but significantly faster than   journal mode     journal mode    data journal mode provides full data and metadata journaling   All new data is   written to the journal first  and then to its final location   In the event of   a crash  the journal can be replayed  bringing both data and metadata into a   consistent state   This mode is the slowest except when data needs to be read   from and written to disk at the same time where it outperforms all others   modes   Enabling this mode will disable delayed allocation and O DIRECT   support    proc entries                Information about mounted ext4 file systems can be found in  proc fs ext4   Each mounted filesystem will have a directory in  proc fs ext4 based on its device name  i e    proc fs ext4 hdc or  proc fs ext4 dm 0     The files in each per device directory are shown in table below   Files in  proc fs ext4  devname     mb groups         details of multiblock allocator buddy cache of free blocks   sys entries               Information about mounted ext4 file systems can be found in  sys fs ext4   Each mounted filesystem will have a directory in  sys fs ext4 based on its device name  i e    sys fs ext4 hdc or  sys fs ext4 dm 0     The files in each per device directory are shown in table below   Files in  sys fs ext4  devname     see also Documentation ABI testing sysfs fs ext4     delayed allocation blocks         This file is read only and shows the number of blocks that are dirty in         the page cache  but which do not have their location in the filesystem         allocated yet     inode goal         Tuning parameter which  if non zero  controls the goal inode used by         the inode allocator in preference to all other allocation heuristics          This is intended for debugging use only  and should be 0 on production         systems     inode readahead blks         Tuning parameter which controls the maximum number of inode table         blocks that ext4 s inode table readahead algorithm will pre read into         the buffer cache     lifetime write kbytes         This file is read only and shows the number of kilobytes of data that         have been written to this filesystem since it was created     max writeback mb bump         The maximum number of megabytes the writeback code will try to write         out before move on to another inode     mb group prealloc         The multiblock allocator will round up allocation requests to a         multiple of this tuning parameter if the stripe size is not set in the         ext4 superblock    mb max to scan         The maximum number of extents the multiblock allocator will search to         find the best extent     mb min to scan         The minimum number of extents the multiblock allocator will search to         find the best extent     mb order2 req         Tuning parameter which controls the minimum size for requests  as a         power of 2  where the buddy cache is used     mb stats         Controls whether the multiblock allocator should collect statistics          which are shown during the unmount  1 means to collect statistics  0         means not to collect statistics     mb stream req         Files which have fewer blocks than this tunable parameter will have         their blocks allocated out of a block group specific preallocation         pool  so that small files are packed closely together   Each large file         will have its blocks allocated out of its own unique preallocation         pool     session write kbytes         This file is read only and shows the number of kilobytes of data that         have been written to this filesystem since it was mounted     reserved clusters         This is RW file and contains number of reserved clusters in the file         system which will be used in the specific situations to avoid costly         zeroout  unexpected ENOSPC  or possible data loss  The default is 2  or         4096 clusters  whichever is smaller and this can be changed however it         can never exceed number of clusters in the file system  If there is not         enough space for the reserved space when mounting the file mount will          not  fail   Ioctls         Ext4 implements various ioctls which can be used by applications to access ext4 specific functionality  An incomplete list of these ioctls is shown in the table below  This list includes truly ext4 specific ioctls    EXT4 IOC      as well as ioctls that may have been ext4 specific originally but are now supported by some other filesystem s  too    FS IOC        Table of Ext4 ioctls    FS IOC GETFLAGS         Get additional attributes associated with inode   The ioctl argument is         an integer bitfield  with bit values described in ext4 h     FS IOC SETFLAGS         Set additional attributes associated with inode   The ioctl argument is         an integer bitfield  with bit values described in ext4 h     EXT4 IOC GETVERSION  EXT4 IOC GETVERSION OLD         Get the inode i generation number stored for each inode  The         i generation number is normally changed only when new inode is created         and it is particularly useful for network filesystems  The   OLD          version of this ioctl is an alias for FS IOC GETVERSION     EXT4 IOC SETVERSION  EXT4 IOC SETVERSION OLD         Set the inode i generation number stored for each inode  The   OLD          version of this ioctl is an alias for FS IOC SETVERSION     EXT4 IOC GROUP EXTEND         This ioctl has the same purpose as the resize mount option  It allows         to resize filesystem to the end of the last existing block group          further resize has to be done with resize2fs  either online  or         offline  The argument points to the unsigned logn number representing         the filesystem new block count     EXT4 IOC MOVE EXT         Move the block extents from orig fd  the one this ioctl is pointing to          to the donor fd  the one specified in move extent structure passed as         an argument to this ioctl   Then  exchange inode metadata between         orig fd and donor fd   This is especially useful for online         defragmentation  because the allocator has the opportunity to allocate         moved blocks better  ideally into one contiguous extent     EXT4 IOC GROUP ADD         Add a new group descriptor to an existing or new group descriptor         block  The new group descriptor is described by ext4 new group input         structure  which is passed as an argument to this ioctl  This is         especially useful in conjunction with EXT4 IOC GROUP EXTEND  which         allows online resize of the filesystem to the end of the last existing         block group   Those two ioctls combined is used in userspace online         resize tool  e g  resize2fs      EXT4 IOC MIGRATE         This ioctl operates on the filesystem itself   It converts  migrates          ext3 indirect block mapped inode to ext4 extent mapped inode by walking         through indirect block mapping of the original inode and converting         contiguous block ranges into ext4 extents of the temporary inode  Then          inodes are swapped  This ioctl might help  when migrating from ext3 to         ext4 filesystem  however suggestion is to create fresh ext4 filesystem         and copy data from the backup  Note  that filesystem has to support         extents for this ioctl to work     EXT4 IOC ALLOC DA BLKS         Force all of the delay allocated blocks to be allocated to preserve         application expected ext3 behaviour  Note that this will also start         triggering a write of the data blocks  but this behaviour may change in         the future as it is not necessary and has been done this way only for         sake of simplicity     EXT4 IOC RESIZE FS         Resize the filesystem to a new size   The number of blocks of resized         filesystem is passed in via 64 bit integer argument   The kernel         allocates bitmaps and inode table  the userspace tool thus just passes         the new number of blocks     EXT4 IOC SWAP BOOT         Swap i blocks and associated attributes  like i blocks  i size          i flags       from the specified inode with inode EXT4 BOOT LOADER INO           5   This is typically used to store a boot loader in a secure part of         the filesystem  where it can t be changed by a normal user by accident          The data blocks of the previous boot loader will be associated with the         given inode   References             kernel source   file fs ext4      file fs jbd2    programs  http   e2fsprogs sourceforge net   useful links  https   fedoraproject org wiki ext3 devel   http   www bullopensource org ext4    http   ext4 wiki kernel org index php Main Page   https   fedoraproject org wiki Features Ext4