12.04 설치는 계속 실패했으며 해결책은 설치 프로그램이 이전에 / home에 사용했던 btrfs 파티션을 무시하도록하는 것입니다.
이제 설치되었으므로 70GB 파일에 액세스 할 수 있도록 btrfs 파티션을 마운트하려고했습니다. 마운트되지 않으며 다음 세 줄로 btrfsck 오류가 발생합니다.
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
누군가이 파티션을 작동시키는 방법을 알려주십시오. btrfs-restore를 사용하여 데이터를 복구 할 수 있다고 온라인에서 읽었지만 어디서나 해당 프로그램을 찾을 수 없습니다.
답변:
가장 쉬운 방법
btrfs-zero-log /dev/sda5
트랜잭션 (쓰기 또는 삭제)이 저널 로그에 붙어 디스크가 일치하지 않기 때문에 문제가 발생합니다.
작동 방식 :
따라서 데이터가 저널에 기록 된 다음 디스크에 기록 될 때 (또는 동시에 저널은 곧 쓰기에 대한 메타 데이터를 저장합니다-확실하지 않습니다 ... 그 부분에 대한 더 많은 연구가 필요합니다) ...
어쨌든이 쓰기 / 삭제 도중에 시스템을 끄거나 시스템을 hickup (btrfs 마운트 포인트를 보유한 USB 분리)하면 시스템이 마운트되지 않으면 실패합니다 ( dmesg 및 btrfsck 는 오류를 더 자세히 표시하십시오) ...
dmesg를 보면 동일한 전송 메시지가 표시됩니다.
다음과 같은 것을 보게 될 것입니다 :
parent transid verify failed on 109973766144 wanted 1823 found 1821
그것은 btrfs가 transif 1826 (저널에 있었음)을 원했지만 디스크에서 1821을 보았 음을 의미합니다. 따라서 디스크는 저널과 동기화되지 않은 2 개의 트랜잭션이었습니다. 나는 단지 2 건의 거래 때문에 개인적으로 brtfs-zero-log를 위험에 빠뜨릴 것입니다. 그러나 이것이 유일한 데이터 인 경우 100 % 안전합니다 (중요한 데이터가있는 경우 절대로 사본이 하나도없고 항상 안전한 다른 위치에 사본 / 백업을 두어야 함). btrfs는 백업 솔루션이 아니며 파일 시스템입니다. 파일 시스템이 아닌 다른 백업 사본은 없습니다. 패리티 또는 미러 드라이브조차도, 진정한 백업은 없습니다. 활성 사본이 텍사스의 사무실에있는 동안 알프스의 지하 어딘가에 앉아있는 경우)
parent transid verify failed on 31302336512 wanted 62455 found 62456
여기서 저널은 62455를 원하지만 디스크는 62456에 앞서 있습니다. 따라서 귀하의 경우 저널을 지울 것입니다. 이번에는 저널이 업데이트되지 않았습니다. 다시 말하지만 당신의 유일한 데이터와 큰 비판 (부끄러운 일)이라면 안전하다고 생각합니다. 아래의 작업을 먼저 수행하여 안전합니다.
btrfsck / dev / sda5를 실행하면 (읽기 전용 검사를 수행하므로 완전히 안전하고 걱정해야 할 유일한 btrfsck 옵션) 메시지를 표시합니다.
그러나 그 데이터가 중요하다면 먼저 할 것입니다 (다른 신사들이 말했듯이)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
그런 다음 모든 파일을 안전한 위치로 cp 또는 rsync하고 btrfs-zero-log를 안전하게 수행하면 성공적으로 작동하면 시스템을 백업하는 데 많은 시간을 낭비했습니다 (성공하지 않으면 방금 저장했습니다). 나귀)
그런 다음 마운트가 실패하면 btrfs 복원을 수행하십시오 (다시 시작 가능한 작업을 이해함에 따라 시스템 덤프가 발생하지만 매번 Y 또는 y를 계속 요구하므로 출력을 감시하십시오)
btrfs restore /dev/sda5 /USB
그런 다음 안전 할 때 (btrfs 복원이 완료되면) btrfs-zero-log를 수행하십시오. 작업이 성공적으로 완료되면 시스템 백업 시간이 많이 낭비됩니다 (성공하지 않으면 arse를 저장했습니다).
먼저 화면을 실행할 수 있습니다
screen /bin/bash
btrfs restore /dev/sda5 /USB
화면 측면 참고
분리하려면 (명령이 계속 실행 됨) : CONTROL-a 따옴표없이 ": detach"를 입력 한 다음 Enter 키를 누릅니다
분리하는 또 다른 방법 : 퍼티 또는 터미널을 닫으면 분리됩니다 (명령 / 복원은 계속 실행 됨).
확인하려면 다시 화면을 확인하십시오.
screen -x
화면 -x는 분리되어 있어도 세션에 연결되며 -h와 달리 이미 연결되어 있어도 연결됩니다)
여러 개의 화면이있는 경우 screen -x는 세션에 연결하기 위해 더 구체적이어야한다고 알려줍니다.
screen -ls
기억하기 쉬운 모든 세션을 나열하십시오.
PID를 보려면 다음을 수행하십시오.
ps aux | grep screen
PID를 찾으면 다음과 같이 화면을 실행하십시오.
screen -x PID
특정 세션에 연결됩니다. 동일한 화면에 여러 세션 / 퍼티를 첨부 할 수 있습니다 (동일한 텍스트를 출력하고 하나의 명령을 입력하면 다른 퍼티에 미러링됩니다)
루트 fs 마운트 옵션을 사용하여 부팅시 마운트 :
rootflags=recovery,nospace_cache
또는
rootflags=recovery,nospace_cache,clear_cache
btrfs 마운트 옵션의 전체 목록은 여기 https://btrfs.wiki.kernel.org/index.php/Mount_options 이어야하며 noatime, nodatacow와 같은 다른 것들도 유용 할 수 있습니다 (나에게 커널 버그가 수정되었습니다. 내 파일을 복사 할 수 있습니다).
grub.cfg / menu.lst에 추가하거나 부팅 할 때 입력하십시오.
nospace_cache 기능은 작업 속도를 크게 저하시킵니다. 부팅, 대기 (길게), 종료 및 정상적으로 부팅하기 만하면됩니다.
나는 며칠 전에 같은 것을 가지고 있었고 위의 문제가 해결되었습니다. 그러나 그 후에도 공간 문제가 발생했습니다 ...보고 된 공간은 100 %가 아니지만 여전히 공간이 부족하다고 말할 수 있습니다.
==
예를 들어 fstab에 동일한 옵션을 추가 할 수도 있다고 생각합니다.
UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0
2
당신은 / 홈 디렉토리를 복구하려고 한 경우와 파티션을 통해 장착 UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.
Peter의 대답은 우분투가 아니더라도 문제를 해결했습니다. 나는했다 /home물론 손상의 가지고 그 btrfs'd 파티션을. 시스템이 켜져있어 부팅되지 않았습니다 fstab. 유지 보수 모드로 들어가서 해당 파티션으로 라인을 해시하고 정상적으로 부팅했습니다 (예비로 사용할 수있는 여분의 ext4 파티션이 있습니다 /home).
다음 명령으로 파티션을 수동으로 마운트했습니다.
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3실제로 내 데이터를 저장할 수있었습니다. 마운트하는 데 시간이 오래 걸리지는 않았지만. 피터 감사합니다.
nospace_cache?