내 디스크는 지금 약간 엉망이지만 제대로 작동하는 것 같은 느낌이 듭니다. 블록 크기가 어떻게 잘못되었는지에 대한 원래 질문은 다음과 같습니다. https://superuser.com/questions/1597651/recovering-a-logic-volume-whos-disk-has-been-removed-and-plugged-back-in?noredirect=1#comment2434932_1597651
나는 losstup으로 이 문제를 해결했고 유효한 논리 볼륨을 표시하는 새로운 루프 장치를 얻었습니다(lvdisplay는 볼륨 그룹을 다시 표시합니다). 그리고 dumpe2fs는 내가 알 수 있는 한 아무런 문제도 표시하지 않습니다.
Filesystem volume name: <none>
Last mounted on: /mnt/newDisk
Filesystem UUID: 7a0d44bf-87cd-42ae-9999-44c69d66fa16
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery 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: 183144448
Block count: 1465129984
Reserved block count: 73256499
Free blocks: 1453293951
Free inodes: 183144437
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Tue Oct 20 13:39:23 2020
Last mount time: Tue Oct 20 13:40:23 2020
Last write time: Tue Oct 20 13:40:23 2020
Mount count: 1
Maximum mount count: -1
Last checked: Tue Oct 20 13:39:23 2020
Check interval: 0 (<none>)
Lifetime writes: 1039 MB
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: c8d38b88-946f-475e-89cc-41e4b87c765c
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x22c5114b
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Journal size: 1024M
Journal length: 262144
Journal sequence: 0x00006538
Journal start: 209904
Journal checksum type: crc32c
Journal checksum: 0x56fe4f79
오프셋 슈퍼블록을 마운트하려고 했지만 mount -o sb=32768 /dev/tmpVG/temporary /mnt
여전히 "잘못된 옵션, 잘못된 fs 유형" 오류가 발생했습니다.
여기서 뭔가 빠졌나요? 뭔가 잘못 설치한 것 같은 느낌이 들지만 무엇을 설치해야 할지 모르겠습니다. 추측과 비교하여 슈퍼블록이 정말 좋은지 확인하는 방법은 무엇입니까?
편집: file -s는 흥미로운 내용을 보여줍니다.
/dev/dm-2: Linux rev 1.0 ext4 filesystem data, UUID=7a0d44bf-87cd-
42ae-9999-44c69d66fa16 (needs journal recovery) (extents) (64bit)
(large files) (huge files)
fsck는 버전 정보, 잘못된 실행 파일을 인쇄한 다음 종료되는 것 같습니다. 자세한 내용을 추가해도 도움이 되지 않습니다.
fsck from util-linux 2.31.1
[/sbin/fsck.ext2 (1) -- /dev/mapper/tmpVG-temporary] fsck.ext2 /dev/mapper/tmpVG-temporary
"로그 복구가 필요합니다"가 단서인 것 같아요. 그건 다음에 알아보겠습니다.
답변1
file -s /dev/tmpVG/temporary
다음을 사용하여 ext4 파일 시스템을 보고 있는지 확인할 수 있습니다. 옵션누구실제 ext2, ext3 또는 ext4 파일 시스템을 마운트하는 경우에만 유효합니다.
또는 매개변수를 사용하여 fsck를 사용해 볼 수도 있습니다.-N도착하다실행하지 말고, 수행할 작업을 보여주세요. fsck -N /dev/tmpVG/temporary