fsck.ocfs2.checks(8)

📦
version 1.8.9 · 3 versions
, in fedora 44, ubuntu resolute, ubuntu stonking

🦋 fsck.ocfs2.checks — OCFS2 Manual Pages, section 8 🦋

okay bestie, listen up 💖 this is the fsck.ocfs2.checks(8) page and it's literally the gossip column of your OCFS2 file system: every problem fsck.ocfs2(8) might clock, and every glow-up it's willing to perform on the spot. no cap.

✨ NAME ✨

fsck.ocfs2.checks — the consistency checks that fsck.ocfs2(8) performs, plus the ways it fixes the inconsistencies it finds. it's giving "diagnosis + treatment plan" energy 🩺✨

🌸 DESCRIPTION 🌸

fsck.ocfs2(8) is the tool you run to check an OCFS2 file system. it does so many consistency checks, and when it catches a fault it will offer to fix it. this man page is basically the master list of every problem it might find, with a full breakdown of each fix.

the problems are indexed by the error number that fsck.ocfs2(8) emits when it describes the problem and asks whether it should fix it. so like, each heading down there is a little name tag for a specific error 👑

and here's the important vibe check about the prompts: they're constructed so that answering 'no' results in no changes to the file system. which sounds safe, sure, but it may result in errors later on that stop fsck.ocfs2(8) from proceeding. so no, you can't just say no to everything and expect to coast through 🙈

🔥 CHECKS 🔥

🌈 EB_BLKNO

extent blocks carry a little receipt: a record of the disk block where they're located. well, one was found at a block that didn't match its recorded location. awkward 💀

answering yes updates the data structure in the extent block to reflect its real location on disk.

🌈 EB_GEN

extent blocks are created with a generation number that matches the generation number of the volume at the time of creation. an extent block was found with a generation number that just... doesn't match.

answering yes implies the generation number is correct and that the extent block is from a previous file system. the extent block will be ignored, and the file that contains it will lose the data it referenced. 😭

🌈 EB_GEN_FIX

same setup, bestie: extent blocks are created with a generation number matching the volume's generation number at creation time, and an extent block was found whose generation number doesn't match.

answering yes implies the opposite of the last one — that the generation number in the extent block is the incorrect one and the extent block itself is valid. the generation number in the block gets updated to match the generation number in the volume. 💅

🌈 EXTENT_MARKED_UNWRITTEN

an extent record has the UNWRITTEN flag set, but the filesystem feature set does not include unwritten extents.

answering yes clears the UNWRITTEN flag. this is safe to do — the feature is disabled anyway. 🫶

🌈 EXTENT_MARKED_REFCOUNTED

an extent record has the REFCOUNTED flag set, but neither the filesystem nor the file has the REFCOUNTED flag set.

answering yes clears the REFCOUNTED flag.

🌈 EXTENT_BLKNO_UNALIGNED

the block that marks the start of an extent should always fall on the start of a cluster. an extent was found that starts part-way into a cluster. like, half a step into the doorway 🚪

answering yes moves the start of the extent back to the start of the addressed cluster. heads up: this may add data to the middle of the file that contains this extent.

🌈 EXTENT_CLUSTERS_OVERRUN

an extent was found claiming to contain clusters that are beyond the end of the volume. bold. 💀

answering yes clamps the extent to the end of the volume. this may result in a reduced file size for the file that contains the extent — but fr, it couldn't have addressed those final clusters anyway. one can imagine this problem arising if there are problems shrinking a volume.

🌈 EXTENT_EB_INVALID

deep extent trees are built by forming a tree out of extent blocks. an extent tree references an invalid extent block.

answering yes stops the tree from referencing the invalid extent block. this may truncate data from the file which contains the tree. 😬

🌈 EXTENT_LIST_DEPTH

extent lists keep a record of their depth in the tree. an extent list was found whose recorded depth doesn't match the position it actually has in the tree.

answering yes updates the depth field in the list to match the tree on disk.

🌈 EXTENT_LIST_COUNT

the number of entries in an extent list is bounded by either the size of the inode or the size of the block that contains it. an extent list was found claiming to have more entries than would fit in its container. it's giving overpacked suitcase 🧳

answering yes updates the count field in the extent list to match the container. answering no to this one may stop further fixes from being done, because the count value can not be trusted. 👑

🌈 EXTENT_LIST_FREE

the number of free entries in an extent list must be less than the total number of entries in the list. a list was found claiming to have more free entries than possible entries. math is not mathing 📉

answering yes sets the number of free entries in the list equal to the total possible entries.

🌈 EXTENT_BLKNO_RANGE

an extent record was found referencing a block that can not be referenced by an extent. the referenced block is either very early in the volume, and thus reserved, or beyond the end of the volume.

answering yes removes this extent record from the tree. this may remove data from the file which owns the tree — but any such data was inaccessible anyway. 🫠

🌈 CHAIN_CPG

the bitmap inode indicates a different clusters per group than the group descriptor. this value is typically static, and it's only modified by tunefs during volume resize — and that too only on volumes having only one cluster group.

answering yes updates the clusters per group on the bitmap inode to the corresponding value in the group descriptor.

🌈 SUPERBLOCK_CLUSTERS

the super block indicates a different total clusters value than the global bitmap. this is only possible due to a failed volume resize operation. 💀

answering yes updates the total clusters in the super block to the value specified in the global bitmap.

🌈 FIXED_CHAIN_CLUSTERS

the global bitmap inode was repaired, resulting in a change to the total cluster count of the filesystem.

answering yes updates the total clusters in the super block to the value specified in the global bitmap.

🌈 GROUP_UNEXPECTED_DESC

the group descriptors that make up the global bitmap chain allocator live at predictable locations on disk. a group descriptor was found in the global bitmap allocator which isn't at one of these locations — so it shouldn't be in the allocator at all. uninvited guest energy 🚫

answering yes removes this descriptor from the global bitmap allocator.

🌈 GROUP_EXPECTED_DESC

same lore: the group descriptors making up the global bitmap chain allocator reside at predictable locations on disk. a group descriptor at one of these locations was not linked into the global bitmap allocator. it was supposed to be at the party and never showed 😭

answering yes will relink this group into the allocator.

🌈 GROUP_GEN

a group descriptor was found with a generation number that doesn't match the generation number of the volume.

answering yes sets the group descriptor's generation equal to the generation number in the volume.

🌈 GROUP_PARENT

group descriptors contain a pointer to the allocator inode that contains the chain they belong to. a group descriptor was found in an allocator inode that doesn't match the descriptor's parent pointer. who's your parent?? 👀

answering yes updates the group descriptor's parent pointer to match the inode it resides in.

🌈 GROUP_DUPLICATE

group descriptors contain a pointer to the allocator inode that contains the chain they belong to. a group descriptor was found in two allocator inodes, so it may be duplicated. two places at once, main character behaviour ✨

answering yes removes the group descriptor from the current allocator inode.

🌈 GROUP_BLKNO

group descriptors have a field recording their block location on disk. a group descriptor was found at a given location but is recorded as being somewhere else.

answering yes updates the group descriptor's recorded location to match where it actually is found on disk.

🌈 GROUP_CHAIN

group descriptors are found in a number of different singly-linked chains in an allocator inode. a group descriptor records the chain number it's linked in. a group descriptor was found whose chain field doesn't match the chain it was found in.

answering yes sets the group descriptor's chain field to match the chain it is found in.

🌈 GROUP_FREE_BITS

a group descriptor records the number of bits in its bitmap that are free. a group descriptor was found claiming to have more free bits than are valid in its bitmap. delulu 🌙

answering yes decreases the number of recorded free bits so that it equals the total number of bits in the group descriptor's bitmap.

🌈 GROUP_CHAIN_LOOP

a chain may loop if the next field of the group descriptor points to one of the previous group descriptors in the chain. this causes the ocfs2 code — both user space and kernel module — to loop forever. 🌀🔁 yeah, that's the bad one.

answering yes breaks the loop at an optimum location so that all the existing group descriptors are in the chain. however, it cannot re-connect stray group descriptors and must rely on the rest of the fsck code to fix it.

🌈 CHAIN_COUNT

the chain list embedded in an inode is limited by the block size and the number of bytes consumed by the rest of the inode. a chain list header was found claiming there are more entries in the list than could fit in the inode.

answering yes resets the header's cl_count member to the maximum size allowed by the block size after accounting for the space consumed by the inode.

🌈 CHAIN_NEXT_FREE

this is identical to CHAIN_COUNT except that it's testing and fixing the pointer to the next free list entry recorded in the cl_next_free_rec member, instead of the total number of entries. same vibe, different field 💅

🌈 CHAIN_EMPTY

chain entries need to be packed such that there are no chains without descriptors found before the chain that is marked as free by the chain header. a chain without descriptors was found before the chain that was marked free. gap in the lineup 🙈

answering yes will remove the unused chain and shift the remaining chains forward in the list.

🌈 CHAIN_I_CLUSTERS

chain allocator inodes have an i_clusters value representing the number of clusters used by the allocator. an inode was found whose i_clusters value doesn't match the number of clusters its chains cover.

answering yes updates i_clusters in the inode to reflect what was actually found by walking the chain.

🌈 CHAIN_I_SIZE

chain allocator inodes multiply the number of bytes per cluster by their i_clusters value and store it in i_size. an inode was found which didn't have the correct value in its i_size.

answering yes updates i_size to be the product of i_clusters and the cluster size. nothing else uses this value, and previous versions of tools didn't calculate it properly, so don't be too worried if this error appears. 🫶 chill.

🌈 CHAIN_GROUP_BITS

the inode that contains an embedded chain list has fields recording the total number of bits covered by the chain as well as the amount free. these fields didn't match what was found in the chain.

answering yes updates the fields in the inode to reflect what was actually found by walking the chain.

the header that starts a chain tried to reference a group descriptor at a block number that couldn't be valid.

answering yes will clear the reference to this invalid block and truncate the chain that it started.

okay we're not done yet bestie, there's more coming 👀✨

Somebody pointed at a group descriptor whose generation number does not match the generation number of the volume. Rude.

  • Say yes and it means that group descriptor is straight-up invalid, and the chain gets truncated right at the spot where it referred to this bogus descriptor.
  • Say no and the group descriptor gets treated as valid, and its generation may be fixed.

Chains are built out of chain headers and group descriptors, all linked together by block references. Someone made a reference to a group descriptor at a given block, but when we looked at that block there was no valid group descriptor signature there. It's giving "fake".

  • Say yes and the reference to that invalid block gets cleared, and the chain gets truncated right at the point of the reference.

Chains = chain headers + group descriptors, linked together by block references. We found a reference to a block that cannot possibly be valid, because it was either too small or it extended past the end of the volume.

  • Say yes and the chain in question gets truncated by zeroing out that invalid block reference. Heads up: this shortens the chain, and it could mean more fixes later if the part of the chain that couldn't be referenced was valid at some point. 🙈

✨ CHAIN_BITS

A chain's header has members that record the total number of bits in the chain, plus how many of those bits are free. After walking through a chain, the number of bits recorded in the header turned out to not match what we got by totalling up the group descriptors.

  • Say yes and it updates the c_total and c_free members of the header to reflect what was actually found in the group descriptors in the chain.

🎀 DISCONTIG_BG_DEPTH

A discontiguous block group has an extent list that records all the clusters allocated to it. Discontiguous block groups only support extent lists with a tree depth of 0. This one claims to have a tree depth greater than 0. Not allowed, bestie.

  • Say yes and it sets the tree depth of the extent list to 0.

🍓 DISCONTIG_BG_COUNT

A discontiguous block group has an extent list recording all the clusters allocated to it. A block group claims to have more records than can actually fit. Math is not mathing.

  • Say yes and it sets the record count to the maximum possible.

🌸 DISCONTIG_BG_REC_RANGE

Block groups set aside clusters to be used for metadata. A discontiguous block group claims to contain clusters beyond the end of the volume. Ma'am, there is no volume there.

  • Say yes and it removes the block group.

💜 DISCONTIG_BG_CORRUPT_LEAVES

A discontiguous block group has an extent list recording all the clusters allocated to it. A group has more than one extent claiming to have an impossible number of clusters.

  • Say yes and it removes the block group.

🔥 DISCONTIG_BG_CLUSTERS

Extent records in a discontiguous block group were found having more clusters allocated than a block group can have.

  • Say yes and it removes the block group.

🧚 DISCONTIG_BG_LESS_CLUSTERS

Extent records in a discontiguous block group were found having less clusters allocated than a block group can have.

  • Say yes and it removes the block group.

⭐ DISCONTIG_BG_NEXT_FREE_REC

A discontiguous block group has an extent list recording all the clusters allocated to it. A group was found with fewer filled-in extents than it claims to have, and the filled-in extents describe a complete and correct group. So like… the truth is right there.

  • Say yes and it sets the used extent count to the number of filled extents.

💅 DISCONTIG_BG_LIST_CORRUPT

A discontiguous block group has an extent list recording all the clusters allocated to it. The group claims to have more extents than is possible, and the existing extents contain errors. Double trouble.

  • Say yes and it removes the block group.

🌈 DISCONTIG_BG_REC_CORRUPT

A discontiguous block group has an extent list recording all the clusters allocated to it. A group was found with one extent claiming too many clusters, but the sum of the remaining extents is equal to the total clusters a group must have.

  • Say yes and it removes the block group.

🫶 DISCONTIG_BG_LEAF_CLUSTERS

A discontiguous block group has an extent list recording all the clusters allocated to it. A group was found with one extent claiming too many clusters, but the remaining extents are correct.

  • Say yes and it sets the number of clusters on the broken extent to the difference between the total clusters a group must have and the sum of the remaining extents.

👑 INODE_ALLOC_REPAIR

The inode allocator did not accurately reflect the set of inodes that are free and in use in the volume. It lied, basically.

  • Say yes and it updates the inode allocator bitmaps. Every bit that doesn't match the state of its inode gets inverted. 🔄

🎀 INODE_SUBALLOC

Each inode records which node's allocator is responsible for it. An inode was found in a given node's allocator, but the inode itself claimed to belong to a different node. Identity crisis.

  • Say yes and it corrects the inode to point to the node's allocator that it actually belongs to.

✨ LALLOC_SIZE

Each node has a local allocator contained in a block, used to allocate clusters in batches. A node's local allocator claims to reflect more bytes than are possible for the volume's block size.

  • Say yes and it decreases the local allocator's size to reflect the volume's block size.

🦋 LALLOC_NZ_USED

A given node's local allocator isn't in use, but it claims to have bits in use in its bitmap. Contradictory queen.

  • Say yes and it zeros this used field.

🍓 LALLOC_NZ_BM

A given node's local allocator isn't in use, but it has a field which records the bitmap as starting at a non-zero cluster offset.

  • Say yes and it zeros the bm_off field.

🌸 LALLOC_BM_OVERRUN

Each local allocator contains a reference to the first cluster that its bitmap addresses. A given local allocator was found referencing a starting cluster that is beyond the end of the volume.

  • Say yes and it resets the given local allocator. Good news: no allocated data will be lost. 💖

💜 LALLOC_BM_SIZE

The given local allocator claims to cover more bits than are possible for the size in bytes of its bitmap.

  • Say yes and it decreases the number of bits the allocator covers to reflect the size in bytes of the bitmap, and resets the allocator. No allocated data will be lost.

🔥 LALLOC_BM_STRADDLE

The given local allocator claims to cover a region of clusters which extends beyond the end of the volume.

  • Say yes and it resets the given local allocator. No allocated data will be lost.

🧚 LALLOC_USED_OVERRUN

The given local allocator claims to have more bits in use than it has total bits in its bitmap. That's not a thing.

  • Say yes and it decreases the number of bits used so that it equals the total number of available bits.

⭐ LALLOC_CLEAR

A local allocator inode was found to have problems. This gives the operator a chance to just… reset the local allocator inode. Fresh start energy. ✨

  • Say yes and it clears the local allocator. No information is lost, but heads up: the global bitmap allocator may need to be updated to reflect clusters that were reserved for the local allocator but were actually free.

💅 DEALLOC_COUNT

The given truncate log inode contains a count that is greater than the value that is possible given the size of the inode.

  • Say yes and it resets the count value to the possible maximum.

🌈 DEALLOC_USED

The given truncate log inode claims to have more records in use than it is possible to store in the inode.

  • Say yes and it resets the record of the number used to the maximum value possible.

🫶 TRUNCATE_REC_START_RANGE

A truncate record was found which claims to start at a cluster that is beyond the number of clusters in the volume.

  • Say yes and it will clear the truncate record. This may result in previously freed space being marked as allocated — but don't panic, that gets fixed up later as the allocator is updated to match what is used by the file system. 🛠️

👑 TRUNCATE_REC_WRAP

Clusters are recorded as 32bit values. A truncate record was found which claims to have enough clusters to cause this value to wrap. That could never be the case and is a sure sign of corruption. 🚩

  • Say yes and it will clear the truncate record. This may result in previously freed space being marked as allocated — fixed up later as the allocator is updated to match what is used by the file system.

🎀 TRUNCATE_REC_RANGE

A truncate record was found which claims to reference a region of clusters that partially extends beyond the number of clusters in the volume.

  • Say yes and it will clear the truncate record. This may result in previously freed space being marked as allocated — fixed up later as the allocator is updated to match what is used by the file system.

✨ INODE_GEN

Inodes are created with a generation number to match the generation number of the volume at the time of creation. An inode was found which contains a generation number that doesn't match.

  • Say yes and it implies the generation number is correct and that the inode is from a previous file system. The inode will be recorded as free.

🦋 INODE_GEN_FIX

Inodes are created with a generation number to match the generation number of the volume at the time of creation. An inode was found which contains a generation number that doesn't match.

  • Say yes and it implies the generation number in the inode is incorrect and that the inode is valid. The generation number in the inode gets updated to match the generation number in the volume.

🍓 INODE_BLKNO

Inodes contain a field that must match the block that they reside in. An inode was found at a block that doesn't match the field in the inode.

  • Say yes and it updates the field to match the inode's position on disk.

🌸 ROOT_NOTDIR

The super block contains a reference to the inode that contains the root directory. This block was found to contain an inode that isn't a directory. 😭

  • Say yes and it clears this inode. The operator will be asked to recreate the root directory at a point in the near future.

💜 INODE_NZ_DTIME

Inodes contain a field describing the time at which they were deleted. This can not be set for an inode that is still in use. An inode was found which is in use but which contains a non-zero dtime.

  • Say yes and it implies the inode is still valid, and resets its dtime to zero.

The target name for a symbolic link is stored either as file contents for that inode, or in the inode structure itself on disk. Only small destination names are stored in the inode structure. The i_blocks field of the inode indicates that the name is stored in the inode when it is zero. An inode was found that has both i_blocks set to zero and file contents.

  • Say yes and it clears the inode — which means it deletes the link.

The targets of links on disk must be null terminated. A link was found whose target wasn't null terminated.

Answering yes clears the inode and so deletes the link. bye bestie 💀

The size of a link on disk has to match the length of its target string. Like, that's the whole vibe. And we found a link whose size just… doesn't. 🙈

Answering yes updates the link's size so it actually reflects the length of its target string. glow-up complete ✨

Links can not be sparse, okay? There must be exactly as many blocks allocated as are needed to cover its size — no more, no less, we don't do half measures here. A link was found which doesn't have enough blocks allocated to cover its size. not it 😭

Answering yes clears the link's inode, thus deleting the link. gone, reduced to atoms 💅

DIR_ZERO 🌸

Directories must at least contain a block that has the "." and ".." entries. Bare minimum, babes. A directory was found which doesn't contain any blocks at all. zero blocks, zero thoughts 💀

Answering yes to this question clears the directory's inode, thus deleting the directory.

INODE_SIZE ⭐

Certain inodes record the size of the data they reference in an i_size field. This can be the number of bytes in a file, directory, or symlink target which are stored in data mapped by extents of clusters. This error occurs when the extent lists are walked and the amount of data found does not match what is stored in i_size. the math is not mathing 😭

Answering yes to this question updates the inode's i_size to match the amount of data referenced by the extent lists. It is vitally important that i_size matches the extent lists, and so answering yes is strongly encouraged. like, please. 🫶

INODE_SPARSE_SIZE 💜

Certain inodes record the size of the data they reference in an i_size field. This can be the number of bytes in a file, directory, or symlink target which are stored in data mapped by extents of clusters. This error occurs when a sparse inode was found that had data allocated past its i_size. girl, you're spilling over 👑

Answering yes to this question will update the inode's i_size to cover all of its allocated storage. It is vitally important that i_size matches the extent lists, and so answering yes is strongly encouraged.

INODE_INLINE_SIZE 🧚

Inodes can only fit a certain amount of inline data. This inode has its data inline but claims an i_size larger than will actually fit. delulu is not the solulu 💀

Answering yes to this question updates the inode's i_size to the maximum available inline space. realistic queen ✨

INODE_CLUSTERS 🔥

Inodes contain a record of how many clusters are allocated to them. An inode was found whose recorded number of clusters doesn't match the number of blocks that were found associated with the inode. receipts don't match the story 📋

Answering yes resets the inode's number of clusters to reflect the number of blocks that were associated with the file.

INODE_SPARSE_CLUSTERS 🌈

Inodes contain a record of how many clusters are allocated to them. A sparse inode was found whose recorded number of clusters doesn't match the number of blocks that were found associated with the inode. sparse and lying, a whole mood 😭

Answering yes resets the inode's number of clusters to reflect the number of blocks that were associated with the file.

INODE_INLINE_CLUSTERS 🍓

An inlined inode should not have allocated clusters. An inode who has the inline data flag set was found with clusters allocated. pick a lane bestie 💅

Answering yes resets the inode's number of clusters to zero.

LALLOC_REPAIR 🛠️

An active local allocator did not accurately reflect the set of clusters that are free and in use in its region. the vibes were off, fr fr

Answering yes will update the local allocator bitmap. Each bit that doesn't match the use of its cluster will be inverted. flip it, reverse it 🪞

LALLOC_USED 🔢

A local allocator records the number of bits that are used in its bitmap. An allocator was found whose used value doesn't reflect the number of bits that are set in its bitmap.

Answering yes sets the used value to match the number of bits set in the allocator's bitmap.

CLUSTER_ALLOC_BIT 💠

A specific cluster's use didn't match the setting of its bit in the cluster allocator. one cluster living a double life 🎭

Answering yes will invert the bit in the allocator to match the use of the cluster — either allocated and in use, or free. no in-between, periodt.

REFCOUNT_FLAG_INVALID 🚩

A refcount file can only exist in a volume with refcount supported. Fsck has found that a file in a non-refcount volume has the refcount flag set. that flag does not belong here 🙅

Answering yes removes this flag from the file.

REFCOUNT_LOC_INVALID 📍

Refcount loc can only be valid if the file has the refcount flag set. Fsck has found that a file has a refcount loc while it doesn't have the refcount flag set. loc without the flag? girl, unhinged 💀

Answering yes resets refcount loc to zero for the file.

RB_BLKNO 🏠

Refcount blocks contain a record of the disk block where they are located. A refcount block was found at a block that didn't match its recorded location. lost, confused, doesn't know where it lives 😭

Answering yes will update the data structure in the refcount block to reflect its real location on disk.

RB_GEN 🕰️

Refcount blocks are created with a generation number to match the generation number of the volume at the time of creation. A refcount block was found which contains a generation number that doesn't match.

Answering yes implies that the generation number is correct and that the refcount block is from a previous file system. The refcount block will be removed and the file that uses it will lose the refcounted information, but it may be regenerated later. it's giving time traveler 🧳

RB_GEN_FIX 🔧

Refcount blocks are created with a generation number to match the generation number of the volume at the time of creation. A refcount block was found which contains a generation number that doesn't match.

Answering yes implies that the generation number in the refcount block is incorrect and that the refcount block is valid. The generation number in the block is updated to match the generation number in the volume. fixed, no cap ✨

RB_PARENT 👑

Refcount blocks contain a record of the parent this disk block belongs to. A refcount block was found storing a wrong parent location.

Answering yes will update the data structure in the refcount block to reflect its parent's real location on disk. found family, but the correct one 🫶

REFCOUNT_LIST_COUNT 🔢

The number of entries in a refcount list is bounded by the size of the block which contains it. A refcount list was found which claims to have more entries than would fit in its container. ma'am that does not fit 💅

Answering yes updates the count field in the refcount list to match the container. Answering no to this question may stop further fixes from being done because the count value can not be trusted. so like, tread carefully 🚨

REFCOUNT_LIST_USED 📊

The number of free entries in a refcount list must be less than the total number of entries in the list. A list was found which claims to have more free entries than possible entries. the math, bestie, the math 😭

Answering yes sets the number of free entries in the list equal to the total possible entries.

REFCOUNT_CLUSTER_RANGE 🚧

A refcount record was found which references a cluster which can not be referenced by a refcount. The referenced cluster is either very early in the volume, and thus reserved, or beyond the end of the volume. either way, off-limits 👮

Answering yes removes this refcount record from the tree.

REFCOUNT_CLUSTER_COLLISION 💥

A refcount record was found which references a cluster which has a collision with the previous valid refcount record. two records, one cluster, drama 📢

Answering yes removes this refcount record from the tree.

REFCOUNT_LIST_EMPTY 🕳️

A refcount list was found which has no refcount record in it. It is normally caused by a corrupted refcount record. empty. void. nothing. 💀

Answering yes removes this refcount block from the tree. It will be re-generated in the refcounted extent records handler if all the other information is sane. glow-up pending ✨

REFCOUNT_BLOCK_INVALID 🚫

A refcount block stores the refcount record for physical clusters of a file. It is found referring an invalid refcount block.

Answering yes removes this refcount block.

REFCOUNT_CLUSTERS 🧮

A refcount tree contains a record of how many clusters are allocated to them. A tree was found whose recorded number of clusters doesn't match the number of blocks that were found associated with it.

Answering yes resets the number of clusters to reflect the real number of clusters that were associated with the tree. the real numbers are realing 📈

REFCOUNT_ROOT_BLOCK_INVALID 🌱

The root refcount block is the root of the refcount record for a file. It is found referring an invalid refcount block.

Answering yes removes this refcount block and clears the refcount flag from this file. root cause found and it's the root itself, iconic 💅

REFCOUNT_REC_REDUNDANT 🙈

A refcount record is used to store the refcount for physical clusters. Some refcount record is found to have no physical clusters corresponding to it. record with no clusters? unemployed, freeloading 😭

Answering yes removes the refcount record.

REFCOUNT_COUNT_INVALID 🔍

A refcount record is used to store the refcount for physical clusters. A refcount record is found which claims the wrong refcount for some physical clusters.

Answering yes updates the corresponding refcount record.

REFCOUNT_COUNT 👯

A refcount tree contains a record of how many files refer to this tree. A tree was found whose recorded number of files doesn't match the real files referring to the tree.

Answering yes resets the number of files to reflect the real number of files that were associated with the tree.

DUP_CLUSTERS_SYSFILE_CLONE 🧬

A system file inode claims clusters that are also claimed by another inode. ocfs2 does not allow this. System files may be cloned but may not be deleted. Allocation system files may not be cloned or deleted. rules are rules, i don't make them 📜

Answering yes will copy the data of this inode to newly allocated extents. This will break the claim on the overcommitted clusters. fresh start, new extents, no drama 🦋

DUP_CLUSTERS_CLONE 🪄

An inode claims clusters that are also claimed by another inode. ocfs2 does not allow this.

Answering yes will copy the data of this inode to newly allocated extents. This will break the claim on the overcommitted clusters.

DUP_CLUSTERS_DELETE 🗑️

An inode claims clusters that are also claimed by another inode. ocfs2 does not allow this.

Answering yes will remove this inode, thus breaking its claim on the overcommitted clusters. sorry babe, you gotta go 💀

DUP_CLUSTERS_ADD_REFCOUNT 🤝

An inode claims clusters that are also claimed by another inode. ocfs2 does not allow this.

Answering yes will try to add a refcount record for all these inodes, so that they will share the cluster. sharing is caring, actually 🫶

DIRENT_DOTTY_DUP 👯‍♀️

There can be only one instance of both the "." and ".." entries in a directory. A directory entry was found which duplicated one of these entries. copycat behaviour, we don't stan 🙅

Answering yes will remove the duplicate directory entry.

DIRENT_NOT_DOTTY 😤

The first and second directory entries in a directory must be "." and ".." respectively. One of these directory entries was found to not match these rules. girl you had ONE job and it was to be in the correct order 💅

Answering yes will force the directory entry to be either "." or "..". This might consume otherwise valid entries and cause some files to appear in lost+found. so like, be aware 👀

DIRENT_DOT_INODE 🔗

The inode field of the "." directory entry must refer to the directory inode that contains the given directory block. A "." entry was found which doesn't do so.

Answering yes sets the directory entry's inode reference to the parent directory that contains the entry. pointing it back home where it belongs 🏡

DIRENT_DOT_EXCESS 💅

okay so there was a "." directory entry, and its length is lowkey too big for just the single dot in the name. Like, why so much room bestie? 🙈

Answering yes creates another empty directory entry in that excess space. Recycling! ♻️

DIRENT_ZERO 🎀

a directory entry showed up with a name that's zero length. literally no name. the audacity 💀

Answering yes clears that directory entry so its space can be reused. 🫶

DIRENT_NAME_CHARS ✨

directory entries can NOT contain the NULL character (ASCII 0) or the forward slash (ASCII 47). we found an entry with one of those forbidden lil guys in it 😭

Answering yes will change each instance of these forbidden characters into a period (ASCII 46). Periodt. 💅

DIRENT_INODE_RANGE 🔥

every directory entry has an inode field that its name corresponds to. this one referenced an inode number that is invalid for the current volume — not it, not on this volume, no thank you.

Answering yes clears this entry so its space can be reused. Quick note tho: if the entry once corresponded to a real inode and got corrupted, this inode may show up in lost+found. 🦋

DIRENT_INODE_FREE 🌸

same deal — each entry has an inode field. this one referenced an inode number that isn't in use.

Answering yes clears this directory entry. gone. 🫶

DIRENT_TYPE 👑

each directory entry has a field describing the type of file it refers to. we found an entry whose type doesn't match the inode it's pointing at. it's giving liar 🙈

Answering yes resets the entry's type to match the target inode. ✨

DIR_PARENT_DUP 💀

a directory can only be pointed to by one directory entry in a parent directory. we found a second entry pointing to a given directory inode. two parents? in this economy?

Answering yes clears this entry which was the second to refer to a given directory. this reflects the policy that hard links to directories are not allowed. periodt. 💅

DIRENT_DUPLICATE 🍓

file names within a directory must be unique, bestie. this name showed up in more than one directory entry in a given directory 😭

Answering yes renames the duplicate entry to a name that doesn't collide with recent entries and is unlikely to collide with future entries in the directory. main character gets a new name. 👑

DIRENT_LENGTH 🔥

there are very few directory entry lengths that are valid, and the vibe check is strict:

  • the length must be greater than the minimum required to record a single character directory
  • it must be rounded to 12 bytes
  • it must be within the amount of space remaining in a directory block
  • it must be properly rounded for the size of the name of the directory entry

an entry was found that didn't meet these criteria. 🙈

Answering yes will try to repair the directory entry.

⚠️ real talk: this runs a very good chance of invalidating all the entries in the directory block. orphaned inodes may appear in lost+found. proceed with the awareness, bestie. 💀

DIR_TRAILER_INODE 🧚

so a directory block trailer is a fake directory entry at the end of the block. it has compatibility fields for when it's viewed as a directory entry, and the inode field must be zero.

Answering yes will set the inode field to zero. ✨

DIR_TRAILER_NAME_LEN 🎀

same trailer, fake directory entry at the end of the block, compatibility fields and all. the name length field must be zero.

Answering yes will set the name length field to zero. 🫶

DIR_TRAILER_REC_LEN 🌈

trailer again 💫 the record length field must be equal to the size of the trailer.

Answering yes will set the record length field to the size of the trailer. matching, as it should be. ✨

DIR_TRAILER_BLKNO 🌸

the directory block trailer's self-referential block number is incorrect. it's lying about which block it is 😭

Answering yes will set the block number to the correct block on disk. fixed. 🫶

DIR_TRAILER_PARENT_INODE 💜

the trailer has a pointer to the directory inode it belongs to, and that pointer is incorrect. wrong parent, tragic. 🙈

Answering yes will set the parent inode pointer to the inode referencing this directory block. 💅

ROOT_DIR_MISSING 👑

the super block contains a reference to the inode that serves as the root directory, and that reference points to an inode that isn't in use. the root?? missing?? not on my watch 🔥

Answering yes will create a new inode and update the super block to refer to this inode as the root directory. ✨

LOSTFOUND_MISSING 🦋

same energy — the super block references the inode that serves as the lost+found directory, and that reference points to an inode that isn't in use.

Answering yes will create a new lost+found directory in the root directory. we love a comeback. 🫶

DIR_NOT_CONNECTED 🧚

every directory in the file system should be reachable by a directory entry in its parent directory — this gets verified by walking every directory in the system. during that walk, a directory inode was found that doesn't have a parent directory entry. orphaned directory energy 😭

Answering yes moves this directory entry into the lost+found directory and gives it a name based on its inode number. 🏠

DIR_DOTDOT 💫

a directory inode's ".." directory entry must refer to the parent directory. we found a directory whose ".." doesn't refer to its parent. it forgot where it came from 💀

Answering yes will read the directory block for the given directory and update its ".." entry to reflect its parent. ✨

INODE_NOT_CONNECTED 🌸

most all inodes in the system should be referenced by a directory entry. this inode isn't referred to by any directory entry. no one's claiming it, no cap. 🙈

Answering yes moves this inode into the lost+found directory and gives it a name based on its inode number. 🫶

INODE_COUNT 🔢

each inode records the number of directory entries that refer to it. we found an inode whose recorded count doesn't match the actual number of entries that refer to it. math not mathing 😭

Answering yes sets the inode's count to match the number of referring directory entries. 💅

INODE_ORPHANED 💀

so when files are being deleted they get placed in an internal directory. if the machine crashes while that's happening, the files are left sitting in there. fsck found an inode in this directory and would like to finish the job of truncating and removing it. closure arc ✨

Answering yes removes the file data associated with the inode and frees the inode. 🫶

RECOVER_BACKUP_SUPERBLOCK 👑

when fsck.ocfs2 successfully uses the specified backup superblock, it offers you this option to overwrite the existing superblock with that backup.

Answering yes will refresh the superblock from the backup. Answering no will only disable the copying of the backup superblock and will not effect the remaining fsck.ocfs2 processing. iykyk. 💅

ORPHAN_DIR_MISSING 🧚

while files are being deleted they're placed in an internal directory, named orphan directory. if an orphan directory doesn't exist, an OCFS2 volume cannot be mounted successfully. fsck found the orphan directory is missing and would like to create it for future use.

Answering yes creates the orphan directory in the system directory. 🫶

JOURNAL_FILE_INVALID 🌈

OCFS2 uses JDB for journalling, and some journal files exist in the system directory. fsck found some journal files that are invalid. 🙈

Answering yes to this question will regenerate the invalid journal files. glow up ✨

JOURNAL_UNKNOWN_FEATURE 🔥

fsck found some journal files with unknown features. other journals on the filesystem have only known features, so this is likely a corruption. if you think your filesystem may be newer than this version of fsck.ocfs2, say N here and grab the latest version of fsck.ocfs2.

Answering yes resets the journal features to match other journals. 💅

JOURNAL_MISSING_FEATURE 💜

fsck found some journal files have features that are not set on all journal files. all journals on the filesystem should have the same set of features. consistency bestie, it's a thing. ✨

Answering yes will set all journals to the union of set features. 🫶

JOURNAL_TOO_SMALL 🍓

fsck found some journal files are too small. smol. 🥺

Answering yes extends these journals. 🔥

RECOVER_CLUSTER_INFO ⚠️

the currently active cluster stack is different than the one the filesystem is configured for. because of that, fsck.ocfs2 cannot determine whether the filesystem is mounted on another node or not. the recommended solution is to exit and run fsck.ocfs2 on this device from a node that has the appropriate active cluster stack. however, you can proceed with the fsck if you are sure that the volume is not in use on any node.

Answering yes reconfigures the filesystem to use the current cluster stack.

🚨 DANGER: YOU MUST BE ABSOLUTELY SURE THAT NO OTHER NODE IS USING THIS FILESYSTEM BEFORE CONTINUING. OTHERWISE, YOU CAN CORRUPT THE FILESYSTEM AND LOSE DATA. 🚨

INLINE_DATA_FLAG_INVALID 🦋

an inline file can only exist in a volume with inline supported. fsck found that a file in a non-inline volume has the inline flag set. sir this is a non-inline volume 💀

Answering yes remove this flag from the file. 💅

INLINE_DATA_COUNT_INVALID ✨

for an inline file, there's a limit for id2.id_data.id_count. fsck found that this value isn't right. the limit said no. 🙈

Answering yes change this value to the right number. 🫶

XATTR_BLOCK_INVALID 🌸

extended attributes are stored off an extended attribute block referenced by the inode. this inode references an invalid extended attribute block. 😭

Answering yes will remove this block. 🫶

XATTR_COUNT_INVALID 🔢

the count of extended attributes in an inode, block, or bucket does not match the number of entries found by fsck. the numbers said bestie no 😭

Answering yes will change this to the correct count. ✨

XATTR_ENTRY_INVALID 💀

an extended attribute entry points to already used space. double dipping, not allowed. 🙈

Answering yes will remove this entry. 💅

XATTR_NAME_OFFSET_INVALID 🎀

the name_offset field of an extended attribute entry is not correct. without a correct name_offset field, the entry cannot be used. periodt.

Answering yes will remove this entry. 🫶

XATTR_VALUE_INVALID 🍓

the value region of an extended attribute points to already used space. overlapping, chaotic, no. 😭

Answering yes will remove this entry. ✨

XATTR_LOCATION_INVALID 🧚

the xe_local field and the xe_value_size field of an extended attribute entry do not match. so the entry cannot be used. incompatible fr fr 💀

Answering yes will remove this entry. 🫶

XATTR_HASH_INVALID 🌈

extended attributes use a hash of their name for lookup purposes. the name_hash of this extended attribute entry is not correct. wrong hash, wrong vibe. 🔥

Answering yes will change this to the correct hash. 💅

XATTR_FREE_START_INVALID 🌸

extended attributes use free_start to indicate the offset of the free space in an inode, block, or bucket. the free_start field of this object is not correct.

Answering yes will change this to the correct offset. ✨

XATTR_VALUE_LEN_INVALID 💜

extended attributes use name_value_len to store the total length of all entry's name and value in an inode, block or bucket. the name_value_len field of this object is not correct.

Answering yes will change this to the correct value. 🫶

XATTR_BUCKET_COUNT_INVALID

okay so the count of extended attributes bucket pointed by one extent record does not match the number of buckets fsck found. 💅

Answering yes will change this to the correct count. ✨

QMAGIC_INVALID

the magic number in the header of quota file is lowkey not matching the proper number. 😭

Answering yes will make fsck use values in the quota file header anyway. 🫶

QTREE_BLK_INVALID

the block with references to other blocks with quota data is corrupted, bestie. it's giving broken. 💀

Answering yes will make fsck use references in the block. 🔥

DQBLK_INVALID

the structure with quota limits was found in a corrupted block. not iconic of it. 🙈

Answering yes will use the values of limits for the user / group. 👑

DUP_DQBLK_INVALID

the structure with quota limits was found in a corrupted block and fsck has already found quota limits for this user / group. double trouble fr fr. 😭

Answering yes will use new values of limits for the user / group. 💅

DUP_DQBLK_VALID

the structure with quota limits was found in a correct block but fsck has already found quota limits for this user / group. so valid but also duplicate, the drama. 🎀

Answering yes will use new values of limits for the user / group. ✨

IV_DX_TREE

a directory index was found on an inode but that feature is not enabled on the file system. main character energy in the wrong era. 💅

Answering yes will truncate the invalid index. 🦋

DX_LOOKUP_FAILED

a directory entry is missing an entry in the directory index. the missing index entry will cause lookups on this name to fail. so rude of it. 😤

Answering yes will rebuild the directory index, restoring the missing entry. 🔥

NO_HOLES

a metadata structure encountered a hole where it should not. examples of such structures are directories, refcount trees, dx_trees etc. holes are for jeans, not metadata. 👖

Answering yes will remove the hole by updating the offset to the expected value. 🫶

EXTENT_OVERLAP

the extents of the file overlap, which means there could be two or more possible data for a particular offset for the file. it's giving choose-your-own-adventure but make it data corruption. 😭

Answering yes will serialize the extents. ✨

DX_TREE_CORRUPT

the index tree of the directory is corrupt. not slay. 💀

Answering yes will rebuild the directory index, in pass 2. 💖

DX_TREE_MISSING

the index of this directory is missing. gone. vanished. not in its flop era, just absent. 🙈

Answering yes will rebuild the directory index. 🌸

BAD_CRC32

the metadata block has a bad CRC32, which means either the block or the crc32 field is corrupted. one of them is lying bestie. 💅

Answering yes will recalculate the CRC32. ⭐

✨ SEE ALSO ✨

if you're in your research era, go hang with the rest of the friend group: debugfs.ocfs2(8), fsck.ocfs2(8), mkfs.ocfs2(8), mount.ocfs2(8), mounted.ocfs2(8), o2cluster(8), o2image(8), o2info(1), tunefs.ocfs2(8). iykyk 🦋

💖 AUTHORS 💖

Oracle Corporation. periodt. 👑

Copyright © 2004, 2012 Oracle. All rights reserved. no cap. 💜

this page is giving Version 1.8.9, January 2012, fsck.ocfs2.checks(8) energy and honestly? iconic. go off bestie 💅✨

📦 where this page comes from