Unable to mount Ext4 LVM (structure needs cleaning) but fsck reports it as clean
0
Following a reboot I have an ext4 LVM that is unable to mount, returning the following message:
mount(2) system call failed: Structure needs cleaning.
Most all advice I found so far to fix this problem is to run fsck, which I did, but it detected no problem and I'm still unable to mount.
/dev/mapper/vg0-lv0: clean, 1537462/1220943872 files, 8455482193/9767526400 blocks
If it helps, here is the output of dumpe2fs:
Filesystem volume name: <none>
Last mounted on: /mnt/8tb_lvm
Filesystem UUID: 0c14f339-3435-4f7c-80fb-c8ffad46a4f1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype meta_bg extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1220943872
Block count: 9767526400
Reserved block count: 410226390
Free blocks: 1312044207
Free inodes: 1219406410
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
First meta block group: 1956
Flex block group size: 16
Filesystem created: Thu Dec 13 12:24:25 2018
Last mount time: Fri Jan 11 13:47:11 2019
Last write time: Tue Jan 29 00:04:50 2019
Mount count: 15
Maximum mount count: -1
Last checked: Thu Dec 13 12:24:25 2018
Check interval: 0 (<none>)
Lifetime writes: 77 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 8e55a66d-33ac-4982-a09d-1f7676814d96
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xb6b6782e
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x00145a5d
Journal start: 0
Journal checksum type: crc32c
Journal checksum: 0x41317cb7
Any ideas on what to try next to resolve this problem would be greatly appreciated
linux ubuntu lvm ext4
asked Jan 29 at 6:28
lechucklechuck
11
add a comment |
0
Following a reboot I have an ext4 LVM that is unable to mount, returning the following message:
mount(2) system call failed: Structure needs cleaning.
Most all advice I found so far to fix this problem is to run fsck, which I did, but it detected no problem and I'm still unable to mount.
/dev/mapper/vg0-lv0: clean, 1537462/1220943872 files, 8455482193/9767526400 blocks
If it helps, here is the output of dumpe2fs:
Filesystem volume name: <none>
Last mounted on: /mnt/8tb_lvm
Filesystem UUID: 0c14f339-3435-4f7c-80fb-c8ffad46a4f1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype meta_bg extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1220943872
Block count: 9767526400
Reserved block count: 410226390
Free blocks: 1312044207
Free inodes: 1219406410
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
First meta block group: 1956
Flex block group size: 16
Filesystem created: Thu Dec 13 12:24:25 2018
Last mount time: Fri Jan 11 13:47:11 2019
Last write time: Tue Jan 29 00:04:50 2019
Mount count: 15
Maximum mount count: -1
Last checked: Thu Dec 13 12:24:25 2018
Check interval: 0 (<none>)
Lifetime writes: 77 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 8e55a66d-33ac-4982-a09d-1f7676814d96
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xb6b6782e
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x00145a5d
Journal start: 0
Journal checksum type: crc32c
Journal checksum: 0x41317cb7
Any ideas on what to try next to resolve this problem would be greatly appreciated
linux ubuntu lvm ext4
asked Jan 29 at 6:28
lechucklechuck
11
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11
add a comment |
0
0
0
1
Following a reboot I have an ext4 LVM that is unable to mount, returning the following message:
mount(2) system call failed: Structure needs cleaning.
Most all advice I found so far to fix this problem is to run fsck, which I did, but it detected no problem and I'm still unable to mount.
/dev/mapper/vg0-lv0: clean, 1537462/1220943872 files, 8455482193/9767526400 blocks
If it helps, here is the output of dumpe2fs:
Filesystem volume name: <none>
Last mounted on: /mnt/8tb_lvm
Filesystem UUID: 0c14f339-3435-4f7c-80fb-c8ffad46a4f1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype meta_bg extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1220943872
Block count: 9767526400
Reserved block count: 410226390
Free blocks: 1312044207
Free inodes: 1219406410
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
First meta block group: 1956
Flex block group size: 16
Filesystem created: Thu Dec 13 12:24:25 2018
Last mount time: Fri Jan 11 13:47:11 2019
Last write time: Tue Jan 29 00:04:50 2019
Mount count: 15
Maximum mount count: -1
Last checked: Thu Dec 13 12:24:25 2018
Check interval: 0 (<none>)
Lifetime writes: 77 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 8e55a66d-33ac-4982-a09d-1f7676814d96
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xb6b6782e
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x00145a5d
Journal start: 0
Journal checksum type: crc32c
Journal checksum: 0x41317cb7
Any ideas on what to try next to resolve this problem would be greatly appreciated
linux ubuntu lvm ext4
asked Jan 29 at 6:28
lechucklechuck
11
Following a reboot I have an ext4 LVM that is unable to mount, returning the following message:
mount(2) system call failed: Structure needs cleaning.
Most all advice I found so far to fix this problem is to run fsck, which I did, but it detected no problem and I'm still unable to mount.
/dev/mapper/vg0-lv0: clean, 1537462/1220943872 files, 8455482193/9767526400 blocks
If it helps, here is the output of dumpe2fs:
Filesystem volume name: <none>
Last mounted on: /mnt/8tb_lvm
Filesystem UUID: 0c14f339-3435-4f7c-80fb-c8ffad46a4f1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype meta_bg extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1220943872
Block count: 9767526400
Reserved block count: 410226390
Free blocks: 1312044207
Free inodes: 1219406410
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
First meta block group: 1956
Flex block group size: 16
Filesystem created: Thu Dec 13 12:24:25 2018
Last mount time: Fri Jan 11 13:47:11 2019
Last write time: Tue Jan 29 00:04:50 2019
Mount count: 15
Maximum mount count: -1
Last checked: Thu Dec 13 12:24:25 2018
Check interval: 0 (<none>)
Lifetime writes: 77 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 8e55a66d-33ac-4982-a09d-1f7676814d96
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xb6b6782e
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x00145a5d
Journal start: 0
Journal checksum type: crc32c
Journal checksum: 0x41317cb7
Any ideas on what to try next to resolve this problem would be greatly appreciated
linux ubuntu lvm ext4
linux ubuntu lvm ext4
asked Jan 29 at 6:28
lechucklechuck
11
asked Jan 29 at 6:28
lechucklechuck
11
edited Jan 29 at 7:18
lechuck
asked Jan 29 at 6:28
lechucklechuck
11
asked Jan 29 at 6:28
lechucklechuck
11
asked Jan 29 at 6:28
lechucklechuck
11
11
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11
add a comment |
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11
add a comment |
0
active
oldest
votes
protected by Community♦ Jan 31 at 10:48
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
protected by Community♦ Jan 31 at 10:48
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
I'm strugling with exactly the same issue, and it happened exactly on the same day. Are you using ubuntu 18.04?
– migas
Jan 31 at 13:51
I ran fsck with a backup superblock and rebooted. working now :)
– migas
Jan 31 at 14:11