code:
What:		/sys/firmware/dmi/tables/
Date:		April 2015
Contact:	Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
Description:
		The firmware provides DMI structures as a packed list of
		data referenced by a SMBIOS table entry point. The SMBIOS
		entry point contains general information, like SMBIOS
		version, DMI table size, etc. The structure, content and
		size of SMBIOS entry point is dependent on SMBIOS version.
		The format of SMBIOS entry point and DMI structures
		can be read in SMBIOS specification.

		The dmi/tables provides raw SMBIOS entry point and DMI tables
		through sysfs as an alternative to utilities reading them
		from /dev/mem. The raw SMBIOS entry point and DMI table are
		presented as binary attributes and are accessible via:

		/sys/firmware/dmi/tables/smbios_entry_point
		/sys/firmware/dmi/tables/DMI

		The complete DMI information can be obtained using these two
		tables.


code:
What:		/sys/firmware/efi/fw_vendor
Date:		December 2013
Contact:	Dave Young <dyoung@redhat.com>
Description:	It shows the physical address of firmware vendor field in the
		EFI system table.
Users:		Kexec

What:		/sys/firmware/efi/runtime
Date:		December 2013
Contact:	Dave Young <dyoung@redhat.com>
Description:	It shows the physical address of runtime service table entry in
		the EFI system table.
Users:		Kexec

What:		/sys/firmware/efi/config_table
Date:		December 2013
Contact:	Dave Young <dyoung@redhat.com>
Description:	It shows the physical address of config table entry in the EFI
		system table.
Users:		Kexec

What:		/sys/firmware/efi/systab
Date:		April 2005
Contact:	linux-efi@vger.kernel.org
Description:	Displays the physical addresses of all EFI Configuration
		Tables found via the EFI System Table. The order in
		which the tables are printed forms an ABI and newer
		versions are always printed first, i.e. ACPI20 comes
		before ACPI.
Users:		dmidecode

What:		/sys/firmware/efi/tables/rci2
Date:		July 2019
Contact:	Narendra K <Narendra.K@dell.com>, linux-bugs@dell.com
Description:	Displays the content of the Runtime Configuration Interface
		Table version 2 on Dell EMC PowerEdge systems in binary format
Users:		It is used by Dell EMC OpenManage Server Administrator tool to
		populate BIOS setup page.

repo_name: angery/linux


code:
What:		/sys/firmware/efi/esrt/
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	Provides userland access to read the EFI System Resource Table
		(ESRT), a catalog of firmware for which can be updated with
		the UEFI UpdateCapsule mechanism described in section 7.5 of
		the UEFI Standard.
Users:		fwupdate - https://github.com/rhinstaller/fwupdate

What:		/sys/firmware/efi/esrt/fw_resource_count
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The number of entries in the ESRT

What:		/sys/firmware/efi/esrt/fw_resource_count_max
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The maximum number of entries that /could/ be registered
		in the allocation the table is currently in.  This is
		really only useful to the system firmware itself.

What:		/sys/firmware/efi/esrt/fw_resource_version
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The version of the ESRT structure provided by the firmware.

What:		/sys/firmware/efi/esrt/entries/entry<N>/
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	Each ESRT entry is identified by a GUID, and each gets a
		subdirectory under entries/ .
		example: /sys/firmware/efi/esrt/entries/entry0/

What:		/sys/firmware/efi/esrt/entries/entry<N>/fw_type
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	What kind of firmware entry this is:

		==  ===============
		0   Unknown
		1   System Firmware
		2   Device Firmware
		3   UEFI Driver
		==  ===============

What:		/sys/firmware/efi/esrt/entries/entry<N>/fw_class
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	This is the entry's guid, and will match the directory name.

What:		/sys/firmware/efi/esrt/entries/entry<N>/fw_version
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The version of the firmware currently installed.  This is a
		32-bit unsigned integer.

What:		/sys/firmware/efi/esrt/entries/entry<N>/lowest_supported_fw_version
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The lowest version of the firmware that can be installed.

What:		/sys/firmware/efi/esrt/entries/entry<N>/capsule_flags
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	Flags that must be passed to UpdateCapsule()

What:		/sys/firmware/efi/esrt/entries/entry<N>/last_attempt_version
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The last firmware version for which an update was attempted.

What:		/sys/firmware/efi/esrt/entries/entry<N>/last_attempt_status
Date:		February 2015
Contact:	Peter Jones <pjones@redhat.com>
Description:	The result of the last firmware update attempt for the
		firmware resource entry.

		==  ======================
		0   Success
		1   Insufficient resources
		2   Incorrect version
		3   Invalid format
		4   Authentication error
		5   AC power event
		6   Battery power event
		==  ======================


code:
What:		/sys/firmware/efi/runtime-map/
Date:		December 2013
Contact:	Dave Young <dyoung@redhat.com>
Description:	Switching efi runtime services to virtual mode requires
		that all efi memory ranges which have the runtime attribute
		bit set to be mapped to virtual addresses.

		The efi runtime services can only be switched to virtual
		mode once without rebooting. The kexec kernel must maintain
		the same physical to virtual address mappings as the first
		kernel. The mappings are exported to sysfs so userspace tools
		can reassemble them and pass them into the kexec kernel.

		/sys/firmware/efi/runtime-map/ is the directory the kernel
		exports that information in.

		subdirectories are named with the number of the memory range::

			/sys/firmware/efi/runtime-map/0
			/sys/firmware/efi/runtime-map/1
			/sys/firmware/efi/runtime-map/2
			/sys/firmware/efi/runtime-map/3
			...

		Each subdirectory contains five files:

		=========   =========================================
		attribute   The attributes of the memory range.
		num_pages   The size of the memory range in pages.
		phys_addr   The physical address of the memory range.
		type        The type of the memory range.
		virt_addr   The virtual address of the memory range.
		=========   =========================================

		Above values are all hexadecimal numbers with the '0x' prefix.
Users:		Kexec


code:
What:		/sys/firmware/gsmi
Date:		March 2011
Contact:	Mike Waychison <mikew@google.com>
Description:
		Some servers used internally at Google have firmware
		that provides callback functionality via explicit SMI
		triggers.  Some of the callbacks are similar to those
		provided by the EFI runtime services page, but due to
		historical reasons this different entry-point has been
		used.

		The gsmi driver implements the kernel's abstraction for
		these firmware callbacks.  Currently, this functionality
		is limited to handling the system event log and getting
		access to EFI-style variables stored in nvram.

		Layout:

		/sys/firmware/gsmi/vars:

			This directory has the same layout (and
			underlying implementation as /sys/firmware/efi/vars.
			See `Documentation/ABI/*/sysfs-firmware-efi-vars`
			for more information on how to interact with
			this structure.

		/sys/firmware/gsmi/append_to_eventlog - write-only:

			This file takes a binary blob and passes it onto
			the firmware to be timestamped and appended to
			the system eventlog.  The binary format is
			interpreted by the firmware and may change from
			platform to platform.  The only kernel-enforced
			requirement is that the blob be prefixed with a
			32bit host-endian type used as part of the
			firmware call.

		/sys/firmware/gsmi/clear_config - write-only:

			Writing any value to this file will cause the
			entire firmware configuration to be reset to
			"factory defaults".  Callers should assume that
			a reboot is required for the configuration to be
			cleared.

		/sys/firmware/gsmi/clear_eventlog - write-only:

			This file is used to clear out a portion/the
			whole of the system event log.  Values written
			should be values between 1 and 100 inclusive (in
			ASCII) representing the fraction of the log to
			clear.  Not all platforms support fractional
			clearing though, and this writes to this file
			will error out if the firmware doesn't like your
			submitted fraction.

			Callers should assume that a reboot is needed
			for this operation to complete.


code:
What:		/sys/firmware/lefi/boardinfo
Date:		October 2020
Contact:	Tiezhu Yang <yangtiezhu@loongson.cn>
Description:
		Get mainboard and BIOS info easily on the Loongson platform,
		this is useful to point out the current used mainboard type
		and BIOS version when there exists problems related with
		hardware or firmware.

		The related structures are already defined in the interface
		specification about firmware and kernel which are common
		requirement and specific for Loongson64, so only add a new
		boardinfo.c file in arch/mips/loongson64.

		For example:

		[loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo
		Board Info
		Manufacturer            : LEMOTE
		Board Name              : LEMOTE-LS3A4000-7A1000-1w-V01-pc
		Family                  : LOONGSON3

		BIOS Info
		Vendor                  : Kunlun
		Version                 : Kunlun-A1901-V4.1.3-20200414093938
		ROM Size                : 4 KB
		Release Date            : 2020-04-14

		By the way, using dmidecode command can get the similar info if there
		exists SMBIOS in firmware, but the fact is that there is no SMBIOS on
		some machines, we can see nothing when execute dmidecode, like this:

		[root@linux loongson]# dmidecode
		# dmidecode 2.12
		# No SMBIOS nor DMI entry point found, sorry.


code:
What:		/sys/firmware/log
Date:		February 2011
Contact:	Mike Waychison <mikew@google.com>
Description:
		The /sys/firmware/log is a binary file that represents a
		read-only copy of the firmware's log if one is
		available.


code:
What:		/sys/firmware/memmap/
Date:		June 2008
Contact:	Bernhard Walle <bernhard.walle@gmx.de>
Description:
		On all platforms, the firmware provides a memory map which the
		kernel reads. The resources from that memory map are registered
		in the kernel resource tree and exposed to userspace via
		/proc/iomem (together with other resources).

		However, on most architectures that firmware-provided memory
		map is modified afterwards by the kernel itself, either because
		the kernel merges that memory map with other information or
		just because the user overwrites that memory map via command
		line.

		kexec needs the raw firmware-provided memory map to setup the
		parameter segment of the kernel that should be booted with
		kexec. Also, the raw memory map is useful for debugging. For
		that reason, /sys/firmware/memmap is an interface that provides
		the raw memory map to userspace.

		The structure is as follows: Under /sys/firmware/memmap there
		are subdirectories with the number of the entry as their name::

			/sys/firmware/memmap/0
			/sys/firmware/memmap/1
			/sys/firmware/memmap/2
			/sys/firmware/memmap/3
			...

		The maximum depends on the number of memory map entries provided
		by the firmware. The order is just the order that the firmware
		provides.

		Each directory contains three files:

		========  =====================================================
		start	  The start address (as hexadecimal number with the
			  '0x' prefix).
		end	  The end address, inclusive (regardless whether the
			  firmware provides inclusive or exclusive ranges).
		type	  Type of the entry as string. See below for a list of
			  valid types.
		========  =====================================================

		So, for example::

			/sys/firmware/memmap/0/start
			/sys/firmware/memmap/0/end
			/sys/firmware/memmap/0/type
			/sys/firmware/memmap/1/start
			...

		Currently following types exist:

		  - System RAM
		  - ACPI Tables
		  - ACPI Non-volatile Storage
		  - Unusable memory
		  - Persistent Memory (legacy)
		  - Persistent Memory
		  - Soft Reserved
		  - reserved

		Following shell snippet can be used to display that memory
		map in a human-readable format::

		  #!/bin/bash
		  cd /sys/firmware/memmap
		  for dir in * ; do
		      start=$(cat $dir/start)
		      end=$(cat $dir/end)
		      type=$(cat $dir/type)
		      printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
		  done


code:
What:		/sys/firmware/devicetree/*
Date:		November 2013
Contact:	Grant Likely <grant.likely@arm.com>, devicetree@vger.kernel.org
Description:
		When using OpenFirmware or a Flattened Device Tree to enumerate
		hardware, the device tree structure will be exposed in this
		directory.

		It is possible for multiple device-tree directories to exist.
		Some device drivers use a separate detached device tree which
		have no attachment to the system tree and will appear in a
		different subdirectory under /sys/firmware/devicetree.

		Userspace must not use the /sys/firmware/devicetree/base
		path directly, but instead should follow /proc/device-tree
		symlink. It is possible that the absolute path will change
		in the future, but the symlink is the stable ABI.

		The /proc/device-tree symlink replaces the devicetree /proc
		filesystem support, and has largely the same semantics and
		should be compatible with existing userspace.

		The contents of /sys/firmware/devicetree/ is a
		hierarchy of directories, one per device tree node. The
		directory name is the resolved path component name (node
		name plus address). Properties are represented as files
		in the directory. The contents of each file is the exact
		binary data from the device tree.

What:		/sys/firmware/fdt
Date:		February 2015
KernelVersion:	3.19
Contact:	Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org
Description:
		Exports the FDT blob that was passed to the kernel by
		the bootloader. This allows userland applications such
		as kexec to access the raw binary. This blob is also
		useful when debugging since it contains any changes
		made to the blob by the bootloader.

		The fact that this node does not reside under
		/sys/firmware/device-tree is deliberate: FDT is also used
		on arm64 UEFI/ACPI systems to communicate just the UEFI
		and ACPI entry points, but the FDT is never unflattened
		and used to configure the system.

		A CRC32 checksum is calculated over the entire FDT
		blob, and verified at late_initcall time. The sysfs
		entry is instantiated only if the checksum is valid,
		i.e., if the FDT blob has not been modified in the mean
		time. Otherwise, a warning is printed.
Users:		kexec, debugging


code:
What:		/sys/firmware/opal/powercap
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Powercap directory for Powernv (P8, P9) servers

		Each folder in this directory contains a
		power-cappable component.

What:		/sys/firmware/opal/powercap/system-powercap
		/sys/firmware/opal/powercap/system-powercap/powercap-min
		/sys/firmware/opal/powercap/system-powercap/powercap-max
		/sys/firmware/opal/powercap/system-powercap/powercap-current
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	System powercap directory and attributes applicable for
		Powernv (P8, P9) servers

		This directory provides powercap information. It
		contains below sysfs attributes:

		- powercap-min : This file provides the minimum
		  possible powercap in Watt units

		- powercap-max : This file provides the maximum
		  possible powercap in Watt units

		- powercap-current : This file provides the current
		  powercap set on the system. Writing to this file
		  creates a request for setting a new-powercap. The
		  powercap requested must be between powercap-min
		  and powercap-max.


code:
What:		/sys/firmware/opal/psr
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Power-Shift-Ratio directory for Powernv P9 servers

		Power-Shift-Ratio allows to provide hints the firmware
		to shift/throttle power between different entities in
		the system. Each attribute in this directory indicates
		a settable PSR.

What:		/sys/firmware/opal/psr/cpu_to_gpu_X
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	PSR sysfs attributes for Powernv P9 servers

		Power-Shift-Ratio between CPU and GPU for a given chip
		with chip-id X. This file gives the ratio (0-100)
		which is used by OCC for power-capping.


code:
What:		/sys/firmware/opal/sensor_groups
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Sensor groups directory for POWER9 powernv servers

		Each folder in this directory contains a sensor group
		which are classified based on type of the sensor
		like power, temperature, frequency, current, etc. They
		can also indicate the group of sensors belonging to
		different owners like CSM, Profiler, Job-Scheduler

What:		/sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
Date:		August 2017
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Sysfs file to clear the min-max of all the sensors
		belonging to the group.

		Writing 1 to this file will clear the minimum and
		maximum values of all the sensors in the group.
		In POWER9, the min-max of a sensor is the historical minimum
		and maximum value of the sensor cached by OCC.


code:
What:		/sys/firmware/papr/energy_scale_info
Date:		February 2022
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Directory hosting a set of platform attributes like
		energy/frequency on Linux running as a PAPR guest.

		Each file in a directory contains a platform
		attribute hierarchy pertaining to performance/
		energy-savings mode and processor frequency.

What:		/sys/firmware/papr/energy_scale_info/<id>
Date:		February 2022
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Energy, frequency attributes directory for POWERVM servers

What:		/sys/firmware/papr/energy_scale_info/<id>/desc
Date:		February 2022
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	String description of the energy attribute of <id>

What:		/sys/firmware/papr/energy_scale_info/<id>/value
Date:		February 2022
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	Numeric value of the energy attribute of <id>

What:		/sys/firmware/papr/energy_scale_info/<id>/value_desc
Date:		February 2022
Contact:	Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description:	String value of the energy attribute of <id>


code:
What:		/sys/firmware/qemu_fw_cfg/
Date:		August 2015
Contact:	Gabriel Somlo <somlo@cmu.edu>
Description:
		Several different architectures supported by QEMU (x86, arm,
		sun4*, ppc/mac) are provisioned with a firmware configuration
		(fw_cfg) device, originally intended as a way for the host to
		provide configuration data to the guest firmware. Starting
		with QEMU v2.4, arbitrary fw_cfg file entries may be specified
		by the user on the command line, which makes fw_cfg additionally
		useful as an out-of-band, asynchronous mechanism for providing
		configuration data to the guest userspace.

		The authoritative guest-side hardware interface documentation
		to the fw_cfg device can be found in "docs/specs/fw_cfg.rst"
		in the QEMU source tree, or online at:
		https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html

		**SysFS fw_cfg Interface**

		The fw_cfg sysfs interface described in this document is only
		intended to display discoverable blobs (i.e., those registered
		with the file directory), as there is no way to determine the
		presence or size of "legacy" blobs (with selector keys between
		0x0002 and 0x0018) programmatically.

		All fw_cfg information is shown under:

			/sys/firmware/qemu_fw_cfg/

		The only legacy blob displayed is the fw_cfg device revision:

			/sys/firmware/qemu_fw_cfg/rev

		**Discoverable fw_cfg blobs by selector key**

		All discoverable blobs listed in the fw_cfg file directory are
		displayed as entries named after their unique selector key
		value, e.g.:

			/sys/firmware/qemu_fw_cfg/by_key/32
			/sys/firmware/qemu_fw_cfg/by_key/33
			/sys/firmware/qemu_fw_cfg/by_key/34
			...

		Each such fw_cfg sysfs entry has the following values exported
		as attributes:

		====	  ====================================================
		name	  The 56-byte nul-terminated ASCII string used as the
			  blob's 'file name' in the fw_cfg directory.
		size	  The length of the blob, as given in the fw_cfg
			  directory.
		key	  The value of the blob's selector key as given in the
			  fw_cfg directory. This value is the same as used in
			  the parent directory name.
		raw	  The raw bytes of the blob, obtained by selecting the
			  entry via the control register, and reading a number
			  of bytes equal to the blob size from the data
			  register.
		====	  ====================================================

		**Listing fw_cfg blobs by file name**

		While the fw_cfg device does not impose any specific naming
		convention on the blobs registered in the file directory,
		QEMU developers have traditionally used path name semantics
		to give each blob a descriptive name. For example::

			"bootorder"
			"genroms/kvmvapic.bin"
			"etc/e820"
			"etc/boot-fail-wait"
			"etc/system-states"
			"etc/table-loader"
			"etc/acpi/rsdp"
			"etc/acpi/tables"
			"etc/smbios/smbios-tables"
			"etc/smbios/smbios-anchor"
			...

		In addition to the listing by unique selector key described
		above, the fw_cfg sysfs driver also attempts to build a tree
		of directories matching the path name components of fw_cfg
		blob names, ending in symlinks to the by_key entry for each
		"basename", as illustrated below (assume current directory is
		/sys/firmware)::

		    qemu_fw_cfg/by_name/bootorder -> ../by_key/38
		    qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
		    qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
		    ...

		Construction of the directory tree and symlinks is done on a
		"best-effort" basis, as there is no guarantee that components
		of fw_cfg blob names are always "well behaved". I.e., there is
		the possibility that a symlink (basename) will conflict with
		a dirname component of another fw_cfg blob, in which case the
		creation of the offending /sys/firmware/qemu_fw_cfg/by_name
		entry will be skipped.

		The authoritative list of entries will continue to be found
		under the /sys/firmware/qemu_fw_cfg/by_key directory.


code:
What:		/sys/firmware/sgi_uv/
Date:		September 2020
Contact:	Justin Ernst <justin.ernst@hpe.com>
Description:
		The /sys/firmware/sgi_uv directory contains information
		about the UV platform.

		Under that directory are a number of read-only attributes::

			archtype
			hub_type
			hubless
			partition_id
			coherence_id
			uv_type

		The archtype entry contains the UV architecture type that
		is used to select arch-dependent addresses and features.
		It can be set via the OEM_ID in the ACPI MADT table or by
		UVsystab entry both passed from UV BIOS.

		The hub_type entry is used to select the type of hub which is
		similar to uv_type but encoded in a binary format.  Include
		the file uv_hub.h to get the definitions.

		The hubless entry basically is present and set only if there
		is no hub.  In this case the hub_type entry is not present.

		The partition_id entry contains the partition id.
		UV systems can be partitioned into multiple physical
		machines, which each partition running a unique copy
		of the operating system. Each partition will have a unique
		partition id.

		The coherence_id entry contains the coherence id.
		A partitioned UV system can have one or more coherence
		domains. The coherence id indicates which coherence domain
		this partition is in.

		The uv_type entry contains the hub revision number.
		This value can be used to identify the UV system version::

			"0.*" = Hubless UV ('*' is subtype)
			"3.0" = UV2
			"5.0" = UV3
			"7.0" = UV4
			"7.1" = UV4a
			"9.0" = UV5

		The /sys/firmware/sgi_uv directory also contains two directories::

			hubs/
			pcibuses/

		The hubs directory contains a number of hub objects, each representing
		a UV Hub visible to the BIOS. Each hub object's name is appended by a
		unique ordinal value (ex. /sys/firmware/sgi_uv/hubs/hub_5)

		Each hub object directory contains a number of read-only attributes::

			cnode
			location
			name
			nasid
			shared
			this_partition

		The cnode entry contains the cnode number of the corresponding hub.
		If a cnode value is not applicable, the value returned will be -1.

		The location entry contains the location string of the corresponding hub.
		This value is used to physically identify a hub within a system.

		The name entry contains the name of the corresponding hub. This name can
		be two variants::

			"UVHub x.x" = A 'node' ASIC, connecting a CPU to the interconnect
			fabric. The 'x.x' value represents the ASIC revision.
			(ex. 'UVHub 5.0')

			"NLxRouter" = A 'router ASIC, only connecting other ASICs to
			the interconnect fabric. The 'x' value representing
			the fabric technology version. (ex. 'NL8Router')

		The nasid entry contains the nasid number of the corresponding hub.
		If a nasid value is not applicable, the value returned will be -1.

		The shared entry contains a boolean value describing whether the
		corresponding hub is shared between system partitions.

		The this_partition entry contains a boolean value describing whether
		the corresponding hub is local to the current partition.

		Each hub object directory also contains a number of port objects,
		each representing a fabric port on the corresponding hub.
		A port object's name is appended by a unique ordinal value
		(ex. /sys/firmware/sgi_uv/hubs/hub_5/port_3)

		Each port object directory contains a number of read-only attributes::

			conn_hub
			conn_port

		The conn_hub entry contains a value representing the unique
		oridinal value of the hub on the other end of the fabric
		cable plugged into the port. If the port is disconnected,
		the value returned will be -1.

		The conn_port entry contains a value representing the unique
		oridinal value of the port on the other end of the fabric cable
		plugged into the port. If the port is disconnected, the value
		returned will be -1.

		Ex:
			A value of '3' is read from:
				/sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_hub

			and a value of '6' is read from:
				/sys/firmware/sgi_uv/hubs/hub_5/port_3/conn_port

			representing that this port is connected to:
				/sys/firmware/sgi_uv/hubs/hub_3/port_6

		The pcibuses directory contains a number of PCI bus objects.
		Each PCI bus object's name is appended by its PCI bus address.
		(ex. pcibus_0003:80)

		Each pcibus object has a number of possible read-only attributes::

			type
			location
			slot
			ppb_addr
			iio_stack

		The type entry contains a value describing the type of IO at
		the corresponding PCI bus address. Known possible values
		across all UV versions are::

			BASE IO
			PCIe IO
			PCIe SLOT
			NODE IO
			Riser
			PPB

		The location entry contains the location string of the UV Hub
		of the CPU physically connected to the corresponding PCI bus.

		The slot entry contains the physical slot number of the
		corresponding PCI bus. This value is used to physically locate
		PCI cards within a system.

		The ppb_addr entry contains the PCI address string of the
		bridged PCI bus. This entry is only present when the PCI bus
		object type is 'PPB'.

		The iio_stack entry contains a value describing the IIO stack
		number that the corresponding PCI bus object is connected to.


code:
What:		/sys/firmware/turris-mox-rwtm/board_version
Date:		August 2019
KernelVersion:	5.4
Contact:	Marek Behún <kabel@kernel.org>
Description:	(Read) Board version burned into eFuses of this Turris Mox board.
		Format: %i

What:		/sys/firmware/turris-mox-rwtm/mac_address*
Date:		August 2019
KernelVersion:	5.4
Contact:	Marek Behún <kabel@kernel.org>
Description:	(Read) MAC addresses burned into eFuses of this Turris Mox board.
		Format: %pM

What:		/sys/firmware/turris-mox-rwtm/pubkey
Date:		August 2019
KernelVersion:	5.4
Contact:	Marek Behún <kabel@kernel.org>
Description:	(Read) ECDSA public key (in pubkey hex compressed form) computed
		as pair to the ECDSA private key burned into eFuses of this
		Turris Mox Board.
		Format: string

What:		/sys/firmware/turris-mox-rwtm/ram_size
Date:		August 2019
KernelVersion:	5.4
Contact:	Marek Behún <kabel@kernel.org>
Description:	(Read) RAM size in MiB of this Turris Mox board as was detected
		during manufacturing and burned into eFuses. Can be 512 or 1024.
		Format: %i

What:		/sys/firmware/turris-mox-rwtm/serial_number
Date:		August 2019
KernelVersion:	5.4
Contact:	Marek Behún <kabel@kernel.org>
Description:	(Read) Serial number burned into eFuses of this Turris Mox device.
		Format: %016X


code:
What:		/sys/fs/erofs/features/
Date:		November 2021
Contact:	"Huang Jianan" <huangjianan@oppo.com>
Description:	Shows all enabled kernel features.
		Supported features:
		zero_padding, compr_cfgs, big_pcluster, chunked_file,
		device_table, compr_head2, sb_chksum.

What:		/sys/fs/erofs/<disk>/sync_decompress
Date:		November 2021
Contact:	"Huang Jianan" <huangjianan@oppo.com>
Description:	Control strategy of sync decompression:

		- 0 (default, auto): enable for readpage, and enable for
		  readahead on atomic contexts only.
		- 1 (force on): enable for readpage and readahead.
		- 2 (force off): disable for all situations.


code:
What:		/sys/fs/ext4/<disk>/mb_stats
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		 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

What:		/sys/fs/ext4/<disk>/mb_group_prealloc
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		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

What:		/sys/fs/ext4/<disk>/mb_max_to_scan
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		The maximum number of extents the multiblock allocator
		will search to find the best extent

What:		/sys/fs/ext4/<disk>/mb_min_to_scan
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		The minimum number of extents the multiblock allocator
		will search to find the best extent

What:		/sys/fs/ext4/<disk>/mb_order2_req
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		Tuning parameter which controls the minimum size for
		requests (as a power of 2) where the buddy cache is
		used

What:		/sys/fs/ext4/<disk>/mb_stream_req
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		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.

What:		/sys/fs/ext4/<disk>/inode_readahead_blks
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		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

What:		/sys/fs/ext4/<disk>/delayed_allocation_blocks
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		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.

What:		/sys/fs/ext4/<disk>/lifetime_write_kbytes
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		This file is read-only and shows the number of kilobytes
		of data that have been written to this filesystem since it was
		created.

What:		/sys/fs/ext4/<disk>/session_write_kbytes
Date:		March 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		This file is read-only and shows the number of
		kilobytes of data that have been written to this
		filesystem since it was mounted.

What:		/sys/fs/ext4/<disk>/inode_goal
Date:		June 2008
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		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.

What:		/sys/fs/ext4/<disk>/max_writeback_mb_bump
Date:		September 2009
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		The maximum number of megabytes the writeback code will
		try to write out before move on to another inode.

What:		/sys/fs/ext4/<disk>/extent_max_zeroout_kb
Date:		August 2012
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		The maximum number of kilobytes which will be zeroed
		out in preference to creating a new uninitialized
		extent when manipulating an inode's extent tree.  Note
		that using a larger value will increase the
		variability of time necessary to complete a random
		write operation (since a 4k random write might turn
		into a much larger write due to the zeroout
		operation).

What:		/sys/fs/ext4/<disk>/journal_task
Date:		February 2019
Contact:	"Theodore Ts'o" <tytso@mit.edu>
Description:
		This file is read-only and shows the pid of journal thread in
		current pid-namespace or 0 if task is unreachable.


code:
What:		/sys/fs/f2fs/<disk>/gc_max_sleep_time
Date:		July 2013
Contact:	"Namjae Jeon" <namjae.jeon@samsung.com>
Description:	Controls the maximum sleep time for gc_thread. Time
		is in milliseconds.

What:		/sys/fs/f2fs/<disk>/gc_min_sleep_time
Date:		July 2013
Contact:	"Namjae Jeon" <namjae.jeon@samsung.com>
Description:	Controls the minimum sleep time for gc_thread. Time
		is in milliseconds.

What:		/sys/fs/f2fs/<disk>/gc_no_gc_sleep_time
Date:		July 2013
Contact:	"Namjae Jeon" <namjae.jeon@samsung.com>
Description:	Controls the default sleep time for gc_thread. Time
		is in milliseconds.

What:		/sys/fs/f2fs/<disk>/gc_idle
Date:		July 2013
Contact:	"Namjae Jeon" <namjae.jeon@samsung.com>
Description:	Controls the victim selection policy for garbage collection.
		Setting gc_idle = 0(default) will disable this option. Setting:

		===========  ===============================================
		gc_idle = 1  will select the Cost Benefit approach & setting
		gc_idle = 2  will select the greedy approach & setting
		gc_idle = 3  will select the age-threshold based approach.
		===========  ===============================================

What:		/sys/fs/f2fs/<disk>/reclaim_segments
Date:		October 2013
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	This parameter controls the number of prefree segments to be
		reclaimed. If the number of prefree segments is larger than
		the number of segments in the proportion to the percentage
		over total volume size, f2fs tries to conduct checkpoint to
		reclaim the prefree segments to free segments.
		By default, 5% over total # of segments.

What:		/sys/fs/f2fs/<disk>/main_blkaddr
Date:		November 2019
Contact:	"Ramon Pantin" <pantin@google.com>
Description:	Shows first block address of MAIN area.

What:		/sys/fs/f2fs/<disk>/ipu_policy
Date:		November 2013
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the in-place-update policy.
		updates in f2fs. User can set:

		====  =================
		0x01  F2FS_IPU_FORCE
		0x02  F2FS_IPU_SSR
		0x04  F2FS_IPU_UTIL
		0x08  F2FS_IPU_SSR_UTIL
		0x10  F2FS_IPU_FSYNC
		0x20  F2FS_IPU_ASYNC
		0x40  F2FS_IPU_NOCACHE
		0x80  F2FS_IPU_HONOR_OPU_WRITE
		====  =================

		Refer segment.h for details.

What:		/sys/fs/f2fs/<disk>/min_ipu_util
Date:		November 2013
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the FS utilization condition for the in-place-update
		policies. It is used by F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.

What:		/sys/fs/f2fs/<disk>/min_fsync_blocks
Date:		September 2014
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the dirty page count condition for the in-place-update
		policies.

What:		/sys/fs/f2fs/<disk>/min_seq_blocks
Date:		August 2018
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the dirty page count condition for batched sequential
		writes in writepages.

What:		/sys/fs/f2fs/<disk>/min_hot_blocks
Date:		March 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the dirty page count condition for redefining hot data.

What:		/sys/fs/f2fs/<disk>/min_ssr_sections
Date:		October 2017
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Controls the free section threshold to trigger SSR allocation.
		If this is large, SSR mode will be enabled early.

What:		/sys/fs/f2fs/<disk>/max_small_discards
Date:		November 2013
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the issue rate of discard commands that consist of small
		blocks less than 2MB. The candidates to be discarded are cached until
		checkpoint is triggered, and issued during the checkpoint.
		By default, it is disabled with 0.

What:		/sys/fs/f2fs/<disk>/max_ordered_discard
Date:		October 2022
Contact:	"Yangtao Li" <frank.li@vivo.com>
Description:	Controls the maximum ordered discard, the unit size is one block(4KB).
		Set it to 16 by default.

What:		/sys/fs/f2fs/<disk>/max_discard_request
Date:		December 2021
Contact:	"Konstantin Vyshetsky" <vkon@google.com>
Description:	Controls the number of discards a thread will issue at a time.
		Higher number will allow the discard thread to finish its work
		faster, at the cost of higher latency for incomming I/O.

What:		/sys/fs/f2fs/<disk>/min_discard_issue_time
Date:		December 2021
Contact:	"Konstantin Vyshetsky" <vkon@google.com>
Description:	Controls the interval the discard thread will wait between
		issuing discard requests when there are discards to be issued and
		no I/O aware interruptions occur.

What:		/sys/fs/f2fs/<disk>/mid_discard_issue_time
Date:		December 2021
Contact:	"Konstantin Vyshetsky" <vkon@google.com>
Description:	Controls the interval the discard thread will wait between
		issuing discard requests when there are discards to be issued and
		an I/O aware interruption occurs.

What:		/sys/fs/f2fs/<disk>/max_discard_issue_time
Date:		December 2021
Contact:	"Konstantin Vyshetsky" <vkon@google.com>
Description:	Controls the interval the discard thread will wait when there are
		no discard operations to be issued.

What:		/sys/fs/f2fs/<disk>/discard_granularity
Date:		July 2017
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Controls discard granularity of inner discard thread. Inner thread
		will not issue discards with size that is smaller than granularity.
		The unit size is one block(4KB), now only support configuring
		in range of [1, 512]. Default value is 16.
		For small devices, default value is 1.

What:		/sys/fs/f2fs/<disk>/umount_discard_timeout
Date:		January 2019
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Set timeout to issue discard commands during umount.
	        Default: 5 secs

What:		/sys/fs/f2fs/<disk>/pending_discard
Date:		November 2021
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Shows the number of pending discard commands in the queue.

What:		/sys/fs/f2fs/<disk>/max_victim_search
Date:		January 2014
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the number of trials to find a victim segment
		when conducting SSR and cleaning operations. The default value
		is 4096 which covers 8GB block address range.

What:		/sys/fs/f2fs/<disk>/migration_granularity
Date:		October 2018
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Controls migration granularity of garbage collection on large
		section, it can let GC move partial segment{s} of one section
		in one GC cycle, so that dispersing heavy overhead GC to
		multiple lightweight one.

What:		/sys/fs/f2fs/<disk>/dir_level
Date:		March 2014
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the directory level for large directory. If a
		directory has a number of files, it can reduce the file lookup
		latency by increasing this dir_level value. Otherwise, it
		needs to decrease this value to reduce the space overhead.
		The default value is 0.

What:		/sys/fs/f2fs/<disk>/ram_thresh
Date:		March 2014
Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:	Controls the memory footprint used by free nids and cached
		nat entries. By default, 1 is set, which indicates
		10 MB / 1 GB RAM.

What:		/sys/fs/f2fs/<disk>/batched_trim_sections
Date:		February 2015
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the trimming rate in batch mode.
		<deprecated>

What:		/sys/fs/f2fs/<disk>/cp_interval
Date:		October 2015
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the checkpoint timing, set to 60 seconds by default.

What:		/sys/fs/f2fs/<disk>/idle_interval
Date:		January 2016
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls the idle timing of system, if there is no FS operation
		during given interval.
		Set to 5 seconds by default.

What:		/sys/fs/f2fs/<disk>/discard_idle_interval
Date:		September 2018
Contact:	"Chao Yu" <yuchao0@huawei.com>
Contact:	"Sahitya Tummala" <stummala@codeaurora.org>
Description:	Controls the idle timing of discard thread given
		this time interval.
		Default is 5 secs.

What:		/sys/fs/f2fs/<disk>/gc_idle_interval
Date:		September 2018
Contact:	"Chao Yu" <yuchao0@huawei.com>
Contact:	"Sahitya Tummala" <stummala@codeaurora.org>
Description:    Controls the idle timing for gc path. Set to 5 seconds by default.

What:		/sys/fs/f2fs/<disk>/iostat_enable
Date:		August 2017
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Controls to enable/disable IO stat.

What:		/sys/fs/f2fs/<disk>/ra_nid_pages
Date:		October 2015
Contact:	"Chao Yu" <chao2.yu@samsung.com>
Description:	Controls the count of nid pages to be readaheaded.
		When building free nids, F2FS reads NAT blocks ahead for
		speed up. Default is 0.

What:		/sys/fs/f2fs/<disk>/dirty_nats_ratio
Date:		January 2016
Contact:	"Chao Yu" <chao2.yu@samsung.com>
Description:	Controls dirty nat entries ratio threshold, if current
		ratio exceeds configured threshold, checkpoint will
		be triggered for flushing dirty nat entries.

What:		/sys/fs/f2fs/<disk>/lifetime_write_kbytes
Date:		January 2016
Contact:	"Shuoran Liu" <liushuoran@huawei.com>
Description:	Shows total written kbytes issued to disk.

What:		/sys/fs/f2fs/<disk>/features
Date:		July 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	<deprecated: should use /sys/fs/f2fs/<disk>/feature_list/>
		Shows all enabled features in current device.
		Supported features:
		encryption, blkzoned, extra_attr, projquota, inode_checksum,
		flexible_inline_xattr, quota_ino, inode_crtime, lost_found,
		verity, sb_checksum, casefold, readonly, compression, pin_file.

What:		/sys/fs/f2fs/<disk>/feature_list/
Date:		June 2021
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Expand /sys/fs/f2fs/<disk>/features to meet sysfs rule.
		Supported on-disk features:
		encryption, block_zoned (aka blkzoned), extra_attr,
		project_quota (aka projquota), inode_checksum,
		flexible_inline_xattr, quota_ino, inode_crtime, lost_found,
		verity, sb_checksum, casefold, readonly, compression.
		Note that, pin_file is moved into /sys/fs/f2fs/features/.

What:		/sys/fs/f2fs/features/
Date:		July 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Shows all enabled kernel features.
		Supported features:
		encryption, block_zoned, extra_attr, project_quota,
		inode_checksum, flexible_inline_xattr, quota_ino,
		inode_crtime, lost_found, verity, sb_checksum,
		casefold, readonly, compression, test_dummy_encryption_v2,
		atomic_write, pin_file, encrypted_casefold.

What:		/sys/fs/f2fs/<disk>/inject_rate
Date:		May 2016
Contact:	"Sheng Yong" <shengyong1@huawei.com>
Description:	Controls the injection rate of arbitrary faults.

What:		/sys/fs/f2fs/<disk>/inject_type
Date:		May 2016
Contact:	"Sheng Yong" <shengyong1@huawei.com>
Description:	Controls the injection type of arbitrary faults.

What:		/sys/fs/f2fs/<disk>/dirty_segments
Date:		October 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Shows the number of dirty segments.

What:		/sys/fs/f2fs/<disk>/reserved_blocks
Date:		June 2017
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Controls target reserved blocks in system, the threshold
		is soft, it could exceed current available user space.

What:		/sys/fs/f2fs/<disk>/current_reserved_blocks
Date:		October 2017
Contact:	"Yunlong Song" <yunlong.song@huawei.com>
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Shows current reserved blocks in system, it may be temporarily
		smaller than target_reserved_blocks, but will gradually
		increase to target_reserved_blocks when more free blocks are
		freed by user later.

What:		/sys/fs/f2fs/<disk>/gc_urgent
Date:		August 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Do background GC aggressively when set. Set to 0 by default.
		gc urgent high(1): does GC forcibly in a period of given
		gc_urgent_sleep_time and ignores I/O idling check. uses greedy
		GC approach and turns SSR mode on.
		gc urgent low(2): lowers the bar of checking I/O idling in
		order to process outstanding discard commands and GC a
		little bit aggressively. uses cost benefit GC approach.
		gc urgent mid(3): does GC forcibly in a period of given
		gc_urgent_sleep_time and executes a mid level of I/O idling check.
		uses cost benefit GC approach.

What:		/sys/fs/f2fs/<disk>/gc_urgent_sleep_time
Date:		August 2017
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls sleep time of GC urgent mode. Set to 500ms by default.

What:		/sys/fs/f2fs/<disk>/readdir_ra
Date:		November 2017
Contact:	"Sheng Yong" <shengyong1@huawei.com>
Description:	Controls readahead inode block in readdir. Enabled by default.

What:		/sys/fs/f2fs/<disk>/gc_pin_file_thresh
Date:		January 2018
Contact:	Jaegeuk Kim <jaegeuk@kernel.org>
Description:	This indicates how many GC can be failed for the pinned
		file. If it exceeds this, F2FS doesn't guarantee its pinning
		state. 2048 trials is set by default.

What:		/sys/fs/f2fs/<disk>/extension_list
Date:		Feburary 2018
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Used to control configure extension list:
		- Query: cat /sys/fs/f2fs/<disk>/extension_list
		- Add: echo '[h/c]extension' > /sys/fs/f2fs/<disk>/extension_list
		- Del: echo '[h/c]!extension' > /sys/fs/f2fs/<disk>/extension_list
		- [h] means add/del hot file extension
		- [c] means add/del cold file extension

What:		/sys/fs/f2fs/<disk>/unusable
Date		April 2019
Contact:	"Daniel Rosenberg" <drosen@google.com>
Description:	If checkpoint=disable, it displays the number of blocks that
		are unusable.
		If checkpoint=enable it displays the number of blocks that
		would be unusable if checkpoint=disable were to be set.

What:		/sys/fs/f2fs/<disk>/encoding
Date		July 2019
Contact:	"Daniel Rosenberg" <drosen@google.com>
Description:	Displays name and version of the encoding set for the filesystem.
		If no encoding is set, displays (none)

What:		/sys/fs/f2fs/<disk>/free_segments
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of free segments in disk.

What:		/sys/fs/f2fs/<disk>/cp_foreground_calls
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of checkpoint operations performed on demand. Available when
		CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/cp_background_calls
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of checkpoint operations performed in the background to
		free segments. Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/gc_foreground_calls
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of garbage collection operations performed on demand.
		Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/gc_background_calls
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of garbage collection operations triggered in background.
		Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/moved_blocks_foreground
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of blocks moved by garbage collection in foreground.
		Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/moved_blocks_background
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Number of blocks moved by garbage collection in background.
		Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/avg_vblocks
Date:		September 2019
Contact:	"Hridya Valsaraju" <hridya@google.com>
Description:	Average number of valid blocks.
		Available when CONFIG_F2FS_STAT_FS=y.

What:		/sys/fs/f2fs/<disk>/mounted_time_sec
Date:		February 2020
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Show the mounted time in secs of this partition.

What:		/sys/fs/f2fs/<disk>/data_io_flag
Date:		April 2020
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Give a way to attach REQ_META|FUA to data writes
		given temperature-based bits. Now the bits indicate:

		+-------------------+-------------------+
		|      REQ_META     |      REQ_FUA      |
		+------+------+-----+------+------+-----+
		|    5 |    4 |   3 |    2 |    1 |   0 |
		+------+------+-----+------+------+-----+
		| Cold | Warm | Hot | Cold | Warm | Hot |
		+------+------+-----+------+------+-----+

What:		/sys/fs/f2fs/<disk>/node_io_flag
Date:		June 2020
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Give a way to attach REQ_META|FUA to node writes
		given temperature-based bits. Now the bits indicate:

		+-------------------+-------------------+
		|      REQ_META     |      REQ_FUA      |
		+------+------+-----+------+------+-----+
		|    5 |    4 |   3 |    2 |    1 |   0 |
		+------+------+-----+------+------+-----+
		| Cold | Warm | Hot | Cold | Warm | Hot |
		+------+------+-----+------+------+-----+

What:		/sys/fs/f2fs/<disk>/iostat_period_ms
Date:		April 2020
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Give a way to change iostat_period time. 3secs by default.
		The new iostat trace gives stats gap given the period.
What:		/sys/fs/f2fs/<disk>/max_io_bytes
Date:		December 2020
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	This gives a control to limit the bio size in f2fs.
		Default is zero, which will follow underlying block layer limit,
		whereas, if it has a certain bytes value, f2fs won't submit a
		bio larger than that size.

What:		/sys/fs/f2fs/<disk>/stat/sb_status
Date:		December 2020
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	Show status of f2fs superblock in real time.

		====== ===================== =================================
		value  sb status macro       description
		0x1    SBI_IS_DIRTY          dirty flag for checkpoint
		0x2    SBI_IS_CLOSE          specify unmounting
		0x4    SBI_NEED_FSCK         need fsck.f2fs to fix
		0x8    SBI_POR_DOING         recovery is doing or not
		0x10   SBI_NEED_SB_WRITE     need to recover superblock
		0x20   SBI_NEED_CP           need to checkpoint
		0x40   SBI_IS_SHUTDOWN       shutdown by ioctl
		0x80   SBI_IS_RECOVERED      recovered orphan/data
		0x100  SBI_CP_DISABLED       CP was disabled last mount
		0x200  SBI_CP_DISABLED_QUICK CP was disabled quickly
		0x400  SBI_QUOTA_NEED_FLUSH  need to flush quota info in CP
		0x800  SBI_QUOTA_SKIP_FLUSH  skip flushing quota in current CP
		0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted
		0x2000 SBI_IS_RESIZEFS       resizefs is in process
		0x4000 SBI_IS_FREEZING       freefs is in process
		====== ===================== =================================

What:		/sys/fs/f2fs/<disk>/stat/cp_status
Date:		September 2022
Contact:	"Chao Yu" <chao.yu@oppo.com>
Description:	Show status of f2fs checkpoint in real time.

		=============================== ==============================
		cp flag				value
		CP_UMOUNT_FLAG			0x00000001
		CP_ORPHAN_PRESENT_FLAG		0x00000002
		CP_COMPACT_SUM_FLAG		0x00000004
		CP_ERROR_FLAG			0x00000008
		CP_FSCK_FLAG			0x00000010
		CP_FASTBOOT_FLAG		0x00000020
		CP_CRC_RECOVERY_FLAG		0x00000040
		CP_NAT_BITS_FLAG		0x00000080
		CP_TRIMMED_FLAG			0x00000100
		CP_NOCRC_RECOVERY_FLAG		0x00000200
		CP_LARGE_NAT_BITMAP_FLAG	0x00000400
		CP_QUOTA_NEED_FSCK_FLAG		0x00000800
		CP_DISABLED_FLAG		0x00001000
		CP_DISABLED_QUICK_FLAG		0x00002000
		CP_RESIZEFS_FLAG		0x00004000
		=============================== ==============================

What:		/sys/fs/f2fs/<disk>/ckpt_thread_ioprio
Date:		January 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Give a way to change checkpoint merge daemon's io priority.
		Its default value is "be,3", which means "BE" I/O class and
		I/O priority "3". We can select the class between "rt" and "be",
		and set the I/O priority within valid range of it. "," delimiter
		is necessary in between I/O class and priority number.

What:		/sys/fs/f2fs/<disk>/ovp_segments
Date:		March 2021
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Shows the number of overprovision segments.

What:		/sys/fs/f2fs/<disk>/compr_written_block
Date:		March 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the block count written after compression since mount. Note
		that when the compressed blocks are deleted, this count doesn't
		decrease. If you write "0" here, you can initialize
		compr_written_block and compr_saved_block to "0".

What:		/sys/fs/f2fs/<disk>/compr_saved_block
Date:		March 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the saved block count with compression since mount. Note
		that when the compressed blocks are deleted, this count doesn't
		decrease. If you write "0" here, you can initialize
		compr_written_block and compr_saved_block to "0".

What:		/sys/fs/f2fs/<disk>/compr_new_inode
Date:		March 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the count of inode newly enabled for compression since mount.
		Note that when the compression is disabled for the files, this count
		doesn't decrease. If you write "0" here, you can initialize
		compr_new_inode to "0".

What:		/sys/fs/f2fs/<disk>/atgc_candidate_ratio
Date:		May 2021
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	When ATGC is on, it controls candidate ratio in order to limit total
		number of potential victim in all candidates, the value should be in
		range of [0, 100], by default it was initialized as 20(%).

What:		/sys/fs/f2fs/<disk>/atgc_candidate_count
Date:		May 2021
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	When ATGC is on, it controls candidate count in order to limit total
		number of potential victim in all candidates, by default it was
		initialized as 10 (sections).

What:		/sys/fs/f2fs/<disk>/atgc_age_weight
Date:		May 2021
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	When ATGC is on, it controls age weight to balance weight proportion
		in between aging and valid blocks, the value should be in range of
		[0, 100], by default it was initialized as 60(%).

What:		/sys/fs/f2fs/<disk>/atgc_age_threshold
Date:		May 2021
Contact:	"Chao Yu" <yuchao0@huawei.com>
Description:	When ATGC is on, it controls age threshold to bypass GCing young
		candidates whose age is not beyond the threshold, by default it was
		initialized as 604800 seconds (equals to 7 days).

What:		/sys/fs/f2fs/<disk>/gc_reclaimed_segments
Date:		July 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show how many segments have been reclaimed by GC during a specific
		GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy,
		3: GC idle AT, 4: GC urgent high, 5: GC urgent low 6: GC urgent mid)
		You can re-initialize this value to "0".

What:		/sys/fs/f2fs/<disk>/gc_segment_mode
Date:		July 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	You can control for which gc mode the "gc_reclaimed_segments" node shows.
		Refer to the description of the modes in "gc_reclaimed_segments".

What:		/sys/fs/f2fs/<disk>/seq_file_ra_mul
Date:		July 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	You can	control the multiplier value of	bdi device readahead window size
		between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option.

What:		/sys/fs/f2fs/<disk>/max_fragment_chunk
Date:		August 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	With "mode=fragment:block" mount options, we can scatter block allocation.
		f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole
		in the length of 1..<max_fragment_hole> by turns. This value can be set
		between 1..512 and the default value is 4.

What:		/sys/fs/f2fs/<disk>/max_fragment_hole
Date:		August 2021
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	With "mode=fragment:block" mount options, we can scatter block allocation.
		f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole
		in the length of 1..<max_fragment_hole> by turns. This value can be set
		between 1..512 and the default value is 4.

What:		/sys/fs/f2fs/<disk>/gc_remaining_trials
Date:		October 2022
Contact:	"Yangtao Li" <frank.li@vivo.com>
Description:	You can set the trial count limit for GC urgent and idle mode with this value.
		If GC thread gets to the limit, the mode will turn back to GC normal mode.
		By default, the value is zero, which means there is no limit like before.

What:		/sys/fs/f2fs/<disk>/max_roll_forward_node_blocks
Date:		January 2022
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Controls max # of node block writes to be used for roll forward
		recovery. This can limit the roll forward recovery time.

What:		/sys/fs/f2fs/<disk>/unusable_blocks_per_sec
Date:		June 2022
Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
Description:	Shows the number of unusable blocks in a section which was defined by
		the zone capacity reported by underlying zoned device.

What:		/sys/fs/f2fs/<disk>/current_atomic_write
Date:		July 2022
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the total current atomic write block count, which is not committed yet.
		This is a read-only entry.

What:		/sys/fs/f2fs/<disk>/peak_atomic_write
Date:		July 2022
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the peak value of total current atomic write block count after boot.
		If you write "0" here, you can initialize to "0".

What:		/sys/fs/f2fs/<disk>/committed_atomic_block
Date:		July 2022
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the accumulated total committed atomic write block count after boot.
		If you write "0" here, you can initialize to "0".

What:		/sys/fs/f2fs/<disk>/revoked_atomic_block
Date:		July 2022
Contact:	"Daeho Jeong" <daehojeong@google.com>
Description:	Show the accumulated total revoked atomic write block count after boot.
		If you write "0" here, you can initialize to "0".

What:		/sys/fs/f2fs/<disk>/gc_mode
Date:		October 2022
Contact:	"Yangtao Li" <frank.li@vivo.com>
Description:	Show the current gc_mode as a string.
		This is a read-only entry.

What:		/sys/fs/f2fs/<disk>/discard_urgent_util
Date:		November 2022
Contact:	"Yangtao Li" <frank.li@vivo.com>
Description:	When space utilization exceeds this, do background DISCARD aggressively.
		Does DISCARD forcibly in a period of given min_discard_issue_time when the number
		of discards is not 0 and set discard granularity to 1.
		Default: 80

What:		/sys/fs/f2fs/<disk>/hot_data_age_threshold
Date:		November 2022
Contact:	"Ping Xiong" <xiongping1@xiaomi.com>
Description:	When DATA SEPARATION is on, it controls the age threshold to indicate
		the data blocks as hot. By default it was initialized as 262144 blocks
		(equals to 1GB).

What:		/sys/fs/f2fs/<disk>/warm_data_age_threshold
Date:		November 2022
Contact:	"Ping Xiong" <xiongping1@xiaomi.com>
Description:	When DATA SEPARATION is on, it controls the age threshold to indicate
		the data blocks as warm. By default it was initialized as 2621440 blocks
		(equals to 10GB).


code:
What:		/sys/fs/nilfs2/features/revision
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show current revision of NILFS file system driver.
		This value informs about file system revision that
		driver is ready to support.

What:		/sys/fs/nilfs2/features/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/features group.

What:		/sys/fs/nilfs2/<device>/revision
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show NILFS file system revision on volume.
		This value informs about metadata structures'
		revision on mounted volume.

What:		/sys/fs/nilfs2/<device>/blocksize
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show volume's block size in bytes.

What:		/sys/fs/nilfs2/<device>/device_size
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show volume size in bytes.

What:		/sys/fs/nilfs2/<device>/free_blocks
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show count of free blocks on volume.

What:		/sys/fs/nilfs2/<device>/uuid
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show volume's UUID (Universally Unique Identifier).

What:		/sys/fs/nilfs2/<device>/volume_name
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show volume's label.

What:		/sys/fs/nilfs2/<device>/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device> group.

What:		/sys/fs/nilfs2/<device>/superblock/sb_write_time
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show last write time of super block in human-readable
		format.

What:		/sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show last write time of super block in seconds.

What:		/sys/fs/nilfs2/<device>/superblock/sb_write_count
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show current write count of super block.

What:		/sys/fs/nilfs2/<device>/superblock/sb_update_frequency
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show/Set interval of periodical update of superblock
		(in seconds).

What:		/sys/fs/nilfs2/<device>/superblock/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device>/superblock
		group.

What:		/sys/fs/nilfs2/<device>/segctor/last_pseg_block
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show start block number of the latest segment.

What:		/sys/fs/nilfs2/<device>/segctor/last_seg_sequence
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show sequence value of the latest segment.

What:		/sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show checkpoint number of the latest segment.

What:		/sys/fs/nilfs2/<device>/segctor/current_seg_sequence
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show segment sequence counter.

What:		/sys/fs/nilfs2/<device>/segctor/current_last_full_seg
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show index number of the latest full segment.

What:		/sys/fs/nilfs2/<device>/segctor/next_full_seg
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show index number of the full segment index
		to be used next.

What:		/sys/fs/nilfs2/<device>/segctor/next_pseg_offset
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show offset of next partial segment in the current
		full segment.

What:		/sys/fs/nilfs2/<device>/segctor/next_checkpoint
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show next checkpoint number.

What:		/sys/fs/nilfs2/<device>/segctor/last_seg_write_time
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show write time of the last segment in
		human-readable format.

What:		/sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show write time of the last segment in seconds.

What:		/sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show write time of the last segment not for cleaner
		operation in human-readable format.

What:		/sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show write time of the last segment not for cleaner
		operation in seconds.

What:		/sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of dirty data blocks.

What:		/sys/fs/nilfs2/<device>/segctor/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device>/segctor
		group.

What:		/sys/fs/nilfs2/<device>/segments/segments_number
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of segments on a volume.

What:		/sys/fs/nilfs2/<device>/segments/blocks_per_segment
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of blocks in segment.

What:		/sys/fs/nilfs2/<device>/segments/clean_segments
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show count of clean segments.

What:		/sys/fs/nilfs2/<device>/segments/dirty_segments
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show count of dirty segments.

What:		/sys/fs/nilfs2/<device>/segments/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device>/segments
		group.

What:		/sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of checkpoints on volume.

What:		/sys/fs/nilfs2/<device>/checkpoints/snapshots_number
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of snapshots on volume.

What:		/sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show checkpoint number of the latest segment.

What:		/sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show next checkpoint number.

What:		/sys/fs/nilfs2/<device>/checkpoints/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
		group.

What:		/sys/fs/nilfs2/<device>/mounted_snapshots/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
		group.

What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of inodes for snapshot.

What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Show number of blocks for snapshot.

What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
Date:		April 2014
Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
		Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
		group.


code:
What:		/sys/fs/ubifsX_Y/error_magic
Date:		October 2021
KernelVersion:	5.16
Contact:	linux-mtd@lists.infradead.org
Description:
		Exposes magic errors: every node starts with a magic number.

		This counter keeps track of the number of accesses of nodes
		with a corrupted magic number.

		The counter is reset to 0 with a remount.

What:		/sys/fs/ubifsX_Y/error_node
Date:		October 2021
KernelVersion:	5.16
Contact:	linux-mtd@lists.infradead.org
Description:
		Exposes node errors. Every node embeds its type.

		This counter keeps track of the number of accesses of nodes
		with a corrupted node type.

		The counter is reset to 0 with a remount.

What:		/sys/fs/ubifsX_Y/error_crc
Date:		October 2021
KernelVersion:	5.16
Contact:	linux-mtd@lists.infradead.org
Description:
		Exposes crc errors: every node embeds a crc checksum.

		This counter keeps track of the number of accesses of nodes
		with a bad crc checksum.

		The counter is reset to 0 with a remount.


code:
What:		/sys/fs/xfs/<disk>/log/log_head_lsn
Date:		July 2014
KernelVersion:	3.17
Contact:	xfs@oss.sgi.com
Description:
		The log sequence number (LSN) of the current head of the
		log. The LSN is exported in "cycle:basic block" format.
Users:		xfstests

What:		/sys/fs/xfs/<disk>/log/log_tail_lsn
Date:		July 2014
KernelVersion:	3.17
Contact:	xfs@oss.sgi.com
Description:
		The log sequence number (LSN) of the current tail of the
		log. The LSN is exported in "cycle:basic block" format.

What:		/sys/fs/xfs/<disk>/log/reserve_grant_head
Date:		July 2014
KernelVersion:	3.17
Contact:	xfs@oss.sgi.com
Description:
		The current state of the log reserve grant head. It
		represents the total log reservation of all currently
		outstanding transactions. The grant head is exported in
		"cycle:bytes" format.
Users:		xfstests

What:		/sys/fs/xfs/<disk>/log/write_grant_head
Date:		July 2014
KernelVersion:	3.17
Contact:	xfs@oss.sgi.com
Description:
		The current state of the log write grant head. It
		represents the total log reservation of all currently
		outstanding transactions, including regrants due to
		rolling transactions. The grant head is exported in
		"cycle:bytes" format.
Users:		xfstests

path: Documentation/ABI/testing/sysfs-fs-xfs


code:
What:		/sys/hypervisor/guest_type
Date:		June 2017
KernelVersion:	4.13
Contact:	xen-devel@lists.xenproject.org
Description:	If running under Xen:
		Type of guest:
		"Xen": standard guest type on arm
		"HVM": fully virtualized guest (x86)
		"PV": paravirtualized guest (x86)
		"PVH": fully virtualized guest without legacy emulation (x86)

What:		/sys/hypervisor/pmu/pmu_mode
Date:		August 2015
KernelVersion:	4.3
Contact:	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Description:	If running under Xen:
		Describes mode that Xen's performance-monitoring unit (PMU)
		uses. Accepted values are:

			======    ============================================
			"off"     PMU is disabled
			"self"    The guest can profile itself
			"hv"      The guest can profile itself and, if it is
				  privileged (e.g. dom0), the hypervisor
			"all"     The guest can profile itself, the hypervisor
				  and all other guests. Only available to
				  privileged guests.
			======    ============================================

What:           /sys/hypervisor/pmu/pmu_features
Date:           August 2015
KernelVersion:  4.3
Contact:        Boris Ostrovsky <boris.ostrovsky@oracle.com>
Description:	If running under Xen:
		Describes Xen PMU features (as an integer). A set bit indicates
		that the corresponding feature is enabled. See
		include/xen/interface/xenpmu.h for available features

What:		/sys/hypervisor/properties/buildid
Date:		June 2017
KernelVersion:	4.13
Contact:	xen-devel@lists.xenproject.org
Description:	If running under Xen:
		Build id of the hypervisor, needed for hypervisor live patching.
		Might return "<denied>" in case of special security settings
		in the hypervisor.


code:
What:		/sys/firmware/ibft/initiator
Date:		November 2007
Contact:	Konrad Rzeszutek <ketuzsezr@darnok.org>
Description:	The /sys/firmware/ibft/initiator directory will contain
		files that expose the iSCSI Boot Firmware Table initiator data.
		Usually this contains the Initiator name.

What:		/sys/firmware/ibft/targetX
Date:		November 2007
Contact:	Konrad Rzeszutek <ketuzsezr@darnok.org>
Description:	The /sys/firmware/ibft/targetX directory will contain
		files that expose the iSCSI Boot Firmware Table target data.
		Usually this contains the target's IP address, boot LUN,
		target name, and what NIC it is associated with. It can also
		contain the CHAP name (and password), the reverse CHAP
		name (and password)

What:		/sys/firmware/ibft/ethernetX
Date:		November 2007
Contact:	Konrad Rzeszutek <ketuzsezr@darnok.org>
Description:	The /sys/firmware/ibft/ethernetX directory will contain
		files that expose the iSCSI Boot Firmware Table NIC data.
		Usually this contains the IP address, MAC, and gateway of the NIC.

What:		/sys/firmware/ibft/acpi_header
Date:		March 2016
Contact:	David Bond <dbond@suse.com>
Description:	The /sys/firmware/ibft/acpi_header directory will contain files
		that expose the SIGNATURE, OEM_ID, and OEM_TABLE_ID fields of the
		acpi table header of the iBFT structure.  This will allow for
		identification of the creator of the table which is useful in
		determining quirks associated with some adapters when used in
		hardware vs software iscsi initiator mode.

path: Documentation/ABI/testing/sysfs-ibft


code:
What:		/sys/kernel/boot_params
Date:		December 2013
Contact:	Dave Young <dyoung@redhat.com>
Description:	The /sys/kernel/boot_params directory contains two
		files: "data" and "version" and one subdirectory "setup_data".
		It is used to export the kernel boot parameters of an x86
		platform to userspace for kexec and debugging purpose.

		If there's no setup_data in boot_params the subdirectory will
		not be created.

		"data" file is the binary representation of struct boot_params.

		"version" file is the string representation of boot
		protocol version.

		"setup_data" subdirectory contains the setup_data data
		structure in boot_params. setup_data is maintained in kernel
		as a link list. In "setup_data" subdirectory there's one
		subdirectory for each link list node named with the number
		of the list nodes. The list node subdirectory contains two
		files "type" and "data". "type" file is the string
		representation of setup_data type. "data" file is the binary
		representation of setup_data payload.

		The whole boot_params directory structure is like below::

		  /sys/kernel/boot_params
		  |__ data
		  |__ setup_data
		  |   |__ 0
		  |   |   |__ data
		  |   |   |__ type
		  |   |__ 1
		  |       |__ data
		  |       |__ type
		  |__ version

Users:		Kexec


code:
What:		/sys/kernel/btf
Date:		Aug 2019
KernelVersion:	5.5
Contact:	bpf@vger.kernel.org
Description:
		Contains BTF type information and related data for kernel and
		kernel modules.

What:		/sys/kernel/btf/vmlinux
Date:		Aug 2019
KernelVersion:	5.5
Contact:	bpf@vger.kernel.org
Description:
		Read-only binary attribute exposing kernel's own BTF type
		information with description of all internal kernel types. See
		Documentation/bpf/btf.rst for detailed description of format
		itself.

What:		/sys/kernel/btf/<module-name>
Date:		Nov 2020
KernelVersion:	5.11
Contact:	bpf@vger.kernel.org
Description:
		Read-only binary attribute exposing kernel module's BTF type
		information as an add-on to the kernel's BTF (/sys/kernel/btf/vmlinux).


code:
What:		/sys/kernel/cpu_byteorder
Date:		February 2023
KernelVersion:	6.2
Contact:	Thomas Weißschuh <linux@weissschuh.net>
Description:
		The endianness of the running kernel.

		Access: Read

		Valid values:
			"little", "big"
Users:		util-linux


code:
What:		/sys/kernel/dmabuf/buffers
Date:		May 2021
KernelVersion:	v5.13
Contact:	Hridya Valsaraju <hridya@google.com>
Description:	The /sys/kernel/dmabuf/buffers directory contains a
		snapshot of the internal state of every DMA-BUF.
		/sys/kernel/dmabuf/buffers/<inode_number> will contain the
		statistics for the DMA-BUF with the unique inode number
		<inode_number>
Users:		kernel memory tuning/debugging tools

What:		/sys/kernel/dmabuf/buffers/<inode_number>/exporter_name
Date:		May 2021
KernelVersion:	v5.13
Contact:	Hridya Valsaraju <hridya@google.com>
Description:	This file is read-only and contains the name of the exporter of
		the DMA-BUF.

What:		/sys/kernel/dmabuf/buffers/<inode_number>/size
Date:		May 2021
KernelVersion:	v5.13
Contact:	Hridya Valsaraju <hridya@google.com>
Description:	This file is read-only and specifies the size of the DMA-BUF in
		bytes.


code:
What:		/sys/kernel/fadump/*
Date:		Dec 2019
Contact:	linuxppc-dev@lists.ozlabs.org
Description:
		The /sys/kernel/fadump/* is a collection of FADump sysfs
		file provide information about the configuration status
		of Firmware Assisted Dump (FADump).

What:		/sys/kernel/fadump/enabled
Date:		Dec 2019
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	read only
		Primarily used to identify whether the FADump is enabled in
		the kernel or not.
User:		Kdump service

What:		/sys/kernel/fadump/registered
Date:		Dec 2019
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	read/write
		Helps to control the dump collect feature from userspace.
		Setting 1 to this file enables the system to collect the
		dump and 0 to disable it.
User:		Kdump service

What:		/sys/kernel/fadump/release_mem
Date:		Dec 2019
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	write only
		This is a special sysfs file and only available when
		the system is booted to capture the vmcore using FADump.
		It is used to release the memory reserved by FADump to
		save the crash dump.

What:		/sys/kernel/fadump/mem_reserved
Date:		Dec 2019
Contact:	linuxppc-dev@lists.ozlabs.org
Description:	read only
		Provide information about the amount of memory reserved by
		FADump to save the crash dump in bytes.


code:
What:		/sys/kernel/fscaps
Date:		February 2011
KernelVersion:	2.6.38
Contact:	Ludwig Nussel <ludwig.nussel@suse.de>
Description:
		Shows whether file system capabilities are honored
		when executing a binary


code:
What:		/sys/kernel/iommu_groups/
Date:		May 2012
KernelVersion:	v3.5
Contact:	Alex Williamson <alex.williamson@redhat.com>
Description:	/sys/kernel/iommu_groups/ contains a number of sub-
		directories, each representing an IOMMU group.  The
		name of the sub-directory matches the iommu_group_id()
		for the group, which is an integer value.  Within each
		subdirectory is another directory named "devices" with
		links to the sysfs devices contained in this group.
		The group directory also optionally contains a "name"
		file if the IOMMU driver has chosen to register a more
		common name for the group.
Users:

What:		/sys/kernel/iommu_groups/reserved_regions
Date: 		January 2017
KernelVersion:  v4.11
Contact: 	Eric Auger <eric.auger@redhat.com>
Description:    /sys/kernel/iommu_groups/reserved_regions list IOVA
		regions that are reserved. Not necessarily all
		reserved regions are listed. This is typically used to
		output direct-mapped, MSI, non mappable regions. Each
		region is described on a single line: the 1st field is
		the base IOVA, the second is the end IOVA and the third
		field describes the type of the region.

		Since kernel 5.3, in case an RMRR is used only by graphics or
		USB devices it is now exposed as "direct-relaxable" instead
		of "direct". In device assignment use case, for instance,
		those RMRR are considered to be relaxable and safe.

What:		/sys/kernel/iommu_groups/<grp_id>/type
Date:		November 2020
KernelVersion:	v5.11
Contact:	Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Description:	/sys/kernel/iommu_groups/<grp_id>/type shows the type of default
		domain in use by iommu for this group. See include/linux/iommu.h
		for possible read values. A privileged user could request kernel to
		change the group type by writing to this file. Valid write values:

		========  ======================================================
		DMA       All the DMA transactions from the device in this group
		          are translated by the iommu.
		DMA-FQ    As above, but using batched invalidation to lazily
		          remove translations after use. This may offer reduced
			  overhead at the cost of reduced memory protection.
		identity  All the DMA transactions from the device in this group
		          are not translated by the iommu. Maximum performance
			  but zero protection.
		auto      Change to the type the device was booted with.
		========  ======================================================

		The default domain type of a group may be modified only when

		- The group has only one device.
		- The device in the group is not bound to any device driver.
		  So, the users must unbind the appropriate driver before
		  changing the default domain type.

		Unbinding a device driver will take away the driver's control
		over the device and if done on devices that host root file
		system could lead to catastrophic effects (the users might
		need to reboot the machine to get it to normal state). So, it's
		expected that the users understand what they're doing.


code:
What:		/sys/kernel/irq
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	Directory containing information about the system's IRQs.
		Specifically, data from the associated struct irq_desc.
		The information here is similar to that in /proc/interrupts
		but in a more machine-friendly format.  This directory contains
		one subdirectory for each Linux IRQ number.

What:		/sys/kernel/irq/<irq>/actions
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	The IRQ action chain.  A comma-separated list of zero or more
		device names associated with this interrupt.

What:		/sys/kernel/irq/<irq>/chip_name
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	Human-readable chip name supplied by the associated device
		driver.

What:		/sys/kernel/irq/<irq>/hwirq
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	When interrupt translation domains are used, this file contains
		the underlying hardware IRQ number used for this Linux IRQ.

What:		/sys/kernel/irq/<irq>/name
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	Human-readable flow handler name as defined by the irq chip
		driver.

What:		/sys/kernel/irq/<irq>/per_cpu_count
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	The number of times the interrupt has fired since boot.  This
		is a comma-separated list of counters; one per CPU in CPU id
		order.  NOTE: This file consistently shows counters for all
		CPU ids.  This differs from the behavior of /proc/interrupts
		which only shows counters for online CPUs.

What:		/sys/kernel/irq/<irq>/type
Date:		September 2016
KernelVersion:	4.9
Contact:	Craig Gallek <kraig@google.com>
Description:	The type of the interrupt.  Either the string 'level' or 'edge'.

What:		/sys/kernel/irq/<irq>/wakeup
Date:		March 2018
KernelVersion:	4.17
Contact:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Description:	The wakeup state of the interrupt. Either the string
		'enabled' or 'disabled'.


code:
What:		/sys/kernel/livepatch
Date:		Nov 2014
KernelVersion:	3.19.0
Contact:	live-patching@vger.kernel.org
Description:
		Interface for kernel live patching

		The /sys/kernel/livepatch directory contains subdirectories for
		each loaded live patch module.

What:		/sys/kernel/livepatch/<patch>
Date:		Nov 2014
KernelVersion:	3.19.0
Contact:	live-patching@vger.kernel.org
Description:
		The patch directory contains subdirectories for each kernel
		object (vmlinux or a module) in which it patched functions.

What:		/sys/kernel/livepatch/<patch>/enabled
Date:		Nov 2014
KernelVersion:	3.19.0
Contact:	live-patching@vger.kernel.org
Description:
		A writable attribute that indicates whether the patched
		code is currently applied.  Writing 0 will disable the patch
		while writing 1 will re-enable the patch.

What:		/sys/kernel/livepatch/<patch>/transition
Date:		Feb 2017
KernelVersion:	4.12.0
Contact:	live-patching@vger.kernel.org
Description:
		An attribute which indicates whether the patch is currently in
		transition.

What:		/sys/kernel/livepatch/<patch>/force
Date:		Nov 2017
KernelVersion:	4.15.0
Contact:	live-patching@vger.kernel.org
Description:
		A writable attribute that allows administrator to affect the
		course of an existing transition. Writing 1 clears
		TIF_PATCH_PENDING flag of all tasks and thus forces the tasks to
		the patched or unpatched state. Administrator should not
		use this feature without a clearance from a patch
		distributor. Removal (rmmod) of patch modules is permanently
		disabled when the feature is used. See
		Documentation/livepatch/livepatch.rst for more information.

What:		/sys/kernel/livepatch/<patch>/<object>
Date:		Nov 2014
KernelVersion:	3.19.0
Contact:	live-patching@vger.kernel.org
Description:
		The object directory contains subdirectories for each function
		that is patched within the object.

What:		/sys/kernel/livepatch/<patch>/<object>/patched
Date:		August 2022
KernelVersion:	6.1.0
Contact:	live-patching@vger.kernel.org
Description:
		An attribute which indicates whether the object is currently
		patched.

What:		/sys/kernel/livepatch/<patch>/<object>/<function,sympos>
Date:		Nov 2014
KernelVersion:	3.19.0
Contact:	live-patching@vger.kernel.org
Description:
		The function directory contains attributes regarding the
		properties and state of the patched function.

		The directory name contains the patched function name and a
		sympos number corresponding to the nth occurrence of the symbol
		name in kallsyms for the patched object.

		There are currently no such attributes.


code:
What:		/sys/kernel/mm
Date:		July 2008
Contact:	Nishanth Aravamudan <nacc@us.ibm.com>, VM maintainers
Description:
		/sys/kernel/mm/ should contain any and all VM
		related information in /sys/kernel/.


code:
What:		/sys/kernel/mm/cma/
Date:		Feb 2021
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		/sys/kernel/mm/cma/ contains a subdirectory for each CMA
		heap name (also sometimes called CMA areas).

		Each CMA heap subdirectory (that is, each
		/sys/kernel/mm/cma/<cma-heap-name> directory) contains the
		following items:

			alloc_pages_success
			alloc_pages_fail

What:		/sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_success
Date:		Feb 2021
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		the number of pages CMA API succeeded to allocate

What:		/sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_fail
Date:		Feb 2021
Contact:	Minchan Kim <minchan@kernel.org>
Description:
		the number of pages CMA API failed to allocate