Làm cách nào để khôi phục phân vùng BTRFS không gắn kết?


13

Việc cài đặt cho 12.04 không thành công và giải pháp là để trình cài đặt bỏ qua phân vùng btrfs mà trước đây tôi đã sử dụng cho / home.

Bây giờ nó đã được cài đặt, tôi đã cố gắng để nó gắn kết phân vùng btrfs để tôi có thể truy cập 70GB tệp của mình. Nó sẽ không gắn kết và lỗi btrfsck với ba dòng sau:

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

Ai đó có thể vui lòng cho tôi biết làm thế nào để phân vùng này hoạt động? Tôi đã đọc trực tuyến rằng tôi có thể có thể khôi phục dữ liệu bằng cách sử dụng btrfs-restore, nhưng tôi không thể tìm thấy chương trình đó ở bất cứ đâu.

Câu trả lời:


10

Cách dễ nhất

btrfs-zero-log /dev/sda5

Bạn gặp phải vấn đề đó vì một giao dịch (ghi hoặc xóa) bị kẹt trong nhật ký nhật ký và đĩa không khớp với nó.

Làm thế nào nó hoạt động:

Vì vậy, khi dữ liệu được ghi đầu tiên, nó được ghi vào nhật ký sau đó vào đĩa (hoặc cùng một lúc, nhưng tạp chí chỉ lưu siêu dữ liệu về lần ghi sắp tới - không chắc chắn ... cần nghiên cứu thêm về phần đó) ...

Dù sao đi nữa, nếu bạn tắt hệ thống ở giữa ghi / xóa này hoặc làm điều gì đó làm hỏng hệ thống (tháo USB giữ điểm gắn btrfs của bạn), thì khi nó trả về việc gắn kết đó sẽ không hoạt động ( dmesgbtrfsck sẽ thất bại cho bạn thấy các lỗi chi tiết hơn) ...

Nhìn vào dmesg bạn sẽ thấy những thông điệp tương tự.

Bạn sẽ thấy một cái gì đó như thế này:

parent transid verify failed on 109973766144 wanted 1823 found 1821

Điều đó có nghĩa là btrfs muốn transif 1826 (Đó là trên tạp chí) nhưng trên đĩa thì thấy 1821. Vì vậy, đĩa đã cách 2 giao dịch không đồng bộ với tạp chí. Cá nhân tôi sẽ mạo hiểm một brtfs-zero-log ở đây chỉ vì 2 giao dịch của nó. Nhưng để an toàn 100% nếu đây là dữ liệu duy nhất của bạn (nhân tiện nếu bạn có dữ liệu quan trọng, bạn KHÔNG BAO GIỜ chỉ có 1 bản sao của nó, luôn có một bản sao / sao lưu ở một vị trí an toàn khác - đổ lỗi cho người tạo btrfs sẽ không biện minh chống lại sự thiếu trách nhiệm của những người không có bản sao lưu - btrfs không phải là giải pháp sao lưu, đó là một hệ thống tập tin - không có gì là một giải pháp sao lưu thực sự ngoài việc có một bản sao của nó trong đó - thậm chí không phải là ổ đĩa nhân đôi hoặc sao chép, một bản sao lưu thực sự là ngồi ở đâu đó dưới lòng đất trong dãy Alps trong khi bản sao hoạt động của nó ở trong văn phòng của bạn ở Texas)

parent transid verify failed on 31302336512 wanted 62455 found 62456

Ở đây tạp chí đang muốn 62455 nhưng đĩa đi trước ở mức 62456, vì vậy trong trường hợp của bạn tôi sẽ xóa nhật ký. Tạp chí không cập nhật lần này. Một lần nữa tôi đã nói với bạn rằng đó là điều an toàn, nếu đó là dữ liệu duy nhất của bạn và là điều cực kỳ quan trọng (xấu hổ với bạn), và tôi sẽ thực hiện các thao tác dưới đây trước để an toàn.

Chạy btrfsck / dev / sda5 (bằng cách này chỉ cần kiểm tra chỉ đọc để nó hoàn toàn an toàn, các tùy chọn btrfsck duy nhất của bạn mà bạn phải lo lắng) cũng sẽ hiển thị cho bạn những tin nhắn đó.

Nhưng hãy cẩn thận nếu dữ liệu đó là quan trọng, trước tiên tôi sẽ làm (Như các gents khác đã nói)

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

Sau đó, cp hoặc rsync tất cả các tệp của bạn đến vị trí an toàn, sau đó khi an toàn thực hiện btrfs-zero-log, nếu hoạt động thành công, bạn chỉ lãng phí rất nhiều thời gian để sao lưu hệ thống của mình (nhưng nếu nó không thành công, bạn chỉ lưu mông)

Sau đó, nếu các mount không thành công, hãy khôi phục btrfs (kết xuất hệ thống, vì tôi hiểu rằng nó hoạt động có thể khôi phục được, tuy nhiên nó cứ yêu cầu Y hoặc y cứ thỉnh thoảng lại xem đầu ra)

btrfs restore /dev/sda5 /USB

Sau đó, khi an toàn (khi khôi phục btrfs được thực hiện) hãy thực hiện btrfs-zero-log, nếu hoạt động thành công, bạn chỉ lãng phí rất nhiều thời gian để sao lưu hệ thống của mình (nhưng nếu nó không thành công, bạn chỉ cần lưu ass của mình)

Bạn có thể chạy màn hình trước

screen /bin/bash

btrfs restore /dev/sda5 /USB

MÀN HÌNH LƯU Ý

Để tách (lệnh vẫn sẽ chạy): KIỂM SOÁT-a rồi gõ ": tách" mà không có dấu ngoặc kép, sau đó nhấn ENTER

Một cách khác để tách ra: Sau đó đóng putty hoặc thiết bị đầu cuối của bạn và nó sẽ tách ra (lệnh / khôi phục vẫn sẽ chạy).

Để kiểm tra, chỉ cần quay lại màn hình:

screen -x

screen -x sẽ đính kèm vào các phiên, ngay cả khi tách ra và không giống như -h nói, nó sẽ đính kèm ngay cả khi nó cũng được gắn vào)

Nếu bạn có một vài màn hình, màn hình -x sẽ cho bạn biết cần phải cụ thể hơn để đính kèm vào phiên:

screen -ls

ls cho danh sách tất cả các phiên, dễ nhớ đó.

để xem PID bạn cũng có thể làm điều này:

ps aux | grep screen

Khi bạn tìm ra PID của mình, sau đó chạy màn hình như thế này:

screen -x PID

Điều đó sẽ đính kèm vào một phiên cụ thể. Bạn có thể có một vài phiên / putty được gắn vào cùng một màn hình (chúng sẽ xuất ra cùng một văn bản, bạn có thể nhập các lệnh trong một và chúng sẽ được nhân đôi trên putty khác)


7

Mount on boot sử dụng tùy chọn mount root fs:

rootflags=recovery,nospace_cache

hoặc là

rootflags=recovery,nospace_cache,clear_cache

Danh sách đầy đủ các tùy chọn gắn kết btrfs nên có ở đây https://btrfs.wiki.kernel.org/index.php/Mount_options và những thứ khác cũng có thể hữu ích, chẳng hạn như noatime, gậtatacow (đã sửa lỗi kernel cho tôi cơ hội để sao chép các tập tin của tôi).

Thêm nó vào grub.cfg / menu.lst của bạn hoặc nhập nó khi khởi động.

Các công cụ nospace_cache sẽ làm cho mọi thứ chậm khủng khiếp. Chỉ cần khởi động, chờ (lâu), tắt và khởi động bình thường.

Tôi đã có một điều tương tự một vài ngày trước, và ở trên đã sửa nó. Nhưng cũng sau đó, có một số vấn đề về không gian ... không gian được báo cáo không phải là 100% nhưng nó vẫn có thể nói ra ngoài không gian.

==

Tôi nghĩ rằng bạn cũng có thể thêm các tùy chọn tương tự trong fstab của mình, ví dụ:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0  
 2

Nếu bạn đang cố khôi phục thư mục / home được gắn trên một phân vùng với UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.


Tại sao hai nospace_cache?
một CVn

đó là một lỗi đánh máy, được cho là rõ ràng_cache
Peter

:) Bạn chỉ cần lưu bằng cách sao lưu!
derflocki

1

Câu trả lời của Peter đã giải quyết vấn đề cho tôi, mặc dù không phải trên Ubuntu. Tôi đã có một /homephân vùng btrfs'd tất nhiên bị hỏng. Hệ thống sẽ không khởi động được vì nó đã bật fstab. Tôi đã vào chế độ bảo trì, băm ra dòng với phân vùng đó và khởi động bình thường (tôi có một phân vùng ext4 dự phòng tôi có thể sử dụng như /home).

Tôi gắn kết phân vùng bằng tay với lệnh sau:

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3và thực sự có thể lưu dữ liệu của tôi. Mặc dù nó không mất nhiều thời gian để gắn kết nó. Vì vậy, CẢM ƠN Peter.


3
Bạn có thể chỉ muốn đăng bài đó như một nhận xét về câu trả lời của peter, nói rằng 'Điều này đã hoạt động' và sau đó chỉ cần đánh dấu đó là câu trả lời thực sự. mặt khác, Peter sẽ không nhận được bất kỳ khoản tín dụng "thật" nào (điểm rep)
Thomas Ward

1
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

ro = chỉ đọc

Công việc này đối với tôi


1
Bạn đã đọc bình luận của @ The Lord of Time cho bình luận tương tự được thêm vào dưới dạng câu trả lời chưa? Đây là một lần nữa nếu bạn không - "Bạn có thể muốn đăng bài đó như một nhận xét về câu trả lời của peter, nói rằng 'Điều này đã làm việc' và sau đó chỉ đánh dấu đó là câu trả lời đúng. Nếu không, Peter sẽ không nhận được bất kỳ" sự thật "nào. tín dụng (điểm rep) "
geezanansa

1

Tôi đã từng gặp vấn đề tương tự. Sau khi khởi động lại, tôi không còn có thể gắn kết phân vùng btrfs của mình. Tuy nhiên không có giải pháp nào được đề cập ở đây có thể giải quyết nó.

Điều đã khắc phục nó đối với tôi là nâng cấp kernel từ 3.10 lên 3.12. Sau khi khởi động lại, phân vùng btrfs có thể được gắn lại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.