Linux, làm thế nào để thay đổi trạng thái ổ cứng từ ReadOnly sau sự cố tạm thời?


17

Tại thời điểm này không có giải pháp cho vấn đề này.

Thông thường sau một số vấn đề với bài đọc hoặc bài viết để chặn thiết bị, kernel quyết định chuyển cờ cho WHOLE DEVICE dưới dạng chỉ đọc. Sau này, bất kỳ bài viết nào tới bất kỳ phân vùng / hệ thống tập tin nào trên thiết bị này đều khiến nó chuyển thành trạng thái chỉ đọc cùng với trạng thái thiết bị, bởi vì bất kỳ bài viết nào đều không thể thực hiện được.

Ví dụ từ dmesg, đây là mô phỏng cho linux linux trên windows8 bằng VirtualBox khi defrag lấy hình ảnh thiết bị của khách:

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

Sau này, kể lại nguyên nhân:

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

bởi vì thiết bị WHOLE sda giữ rootfs sda1 là S READN SÀNG.

Theo kinh nghiệm của tôi, điều này xảy ra trong các tình huống:

  1. HDD thực sự bị hư. Vấn đề viết bị trả lại phụ thuộc vào điều kiện ổ cứng
  2. Máy chủ bị quá tải, sau đó các bản ghi HDD dành cho khách ảo của Linux đã hết thời gian
  3. Cáp FC hoặc thiết bị SAN (đĩa mảng trên Kênh sợi quang) bị quá tải
  4. Mất kết nối tạm thời qua FC hoặc FCoE. Có thể mất / hết thời gian gói FC

Ở tình huống này, thiết bị thực sự là đọc-ghi, nhưng nhân linux đánh dấu thiết bị này bên trong là chỉ đọc và được sử dụng làm chỉ đọc. Đây là chức năng kernel được tạo ra để ngăn ngừa thiệt hại, nhưng nó chỉ có thể sử dụng được ở 1. điểm.

Câu hỏi là. Làm thế nào để tự nói với kernel, thiết bị khối hdd hoạt động bình thường?

Mặc dù vậy, kernel phục vụ thiết bị ở dạng chỉ đọc, như 'CD-ROM' và không có lệnh nào khác có cơ hội hoạt động chính xác, bao gồm mount / remount -o read-write, fsck và các thiết bị khác.

Máy chủ không thể sử dụng, thực sự đủ điều kiện là thư rác từ những người muốn giúp đỡ, nhưng không hiểu về bản chất vấn đề:

  1. Thử đọc lại dưới dạng đọc-ghi (không thể, thiết bị là RO)
  2. fsck này (những gì cho? thiết bị là RO, không thể sửa chữa)
  3. 'Tôi không biết' (đầu tiên có ý nghĩa, nhưng không sử dụng được)
  4. 'Thay thế thiết bị của bạn' * (thường thì sự cố là vấn đề khác)

Có ai có bất kỳ công thức cho câu hỏi trên? Chuyển cờ cho thiết bị khối có thể ghi có thể hoàn nguyên thiết bị từ trạng thái chỉ đọc sang trạng thái đọc-ghi? Lúc này dường như không ai biết làm thế nào.

Đó là một số cách giải quyết, nhưng thường có thể bán được hoặc không sử dụng được:

  1. Hủy bỏ mô-đun hỗ trợ truy cập vào hdd hoặc mảng lưu trữ được chỉ định. Thật không may, thiết bị thường bị hỏng giữ rootfs hoặc trình điều khiển giữ cả thiết bị bị hỏng và thiết bị giữ rootfs
  2. Xóa quyền truy cập FC vào thiết bị và tham gia lại thiết bị này (fctools), không phải mọi cách có thể, không phải mọi cách đều hoạt động.
  3. Khởi động lại máy WHOLE. Thông thường chỉ có điều này là có thể và chúng ta luôn luôn bị ép buộc.

Tại các điểm 1. và 2. chúng tôi nói với kernel rằng chúng tôi hoàn toàn ngắt kết nối thiết bị và kết nối lại với thiết bị. Kernel nhận ra điều này khi tham gia thiết bị hoạt động đúng mới. Chúng ta có thể mô phỏng điều này bằng thiết bị USB và loại bỏ nguồn điện trong giây lát. Điểm 3. là cơ hội cuối cùng và thường hoạt động. Nhưng tại sao chúng ta nên khởi động lại tất cả? Thật không may tại tất cả các điểm chúng tôi đã mất tất cả các cập nhật tạp chí và bộ đệm bẩn.

Lưu ý, trong cùng một tình huống tôi không gặp vấn đề gì với Windows (máy tính để bàn và máy chủ).


Không phải là một câu trả lời, nhưng có thể liên quan trong trường hợp # 2 (tải máy chủ cao, hết thời gian chờ hdd của khách): Tăng thời gian chờ hdd của Linux để ngăn chặn tham nhũng hệ thống tệp do hết thời gian hdd trong hệ thống khách.
bản6

@Znik, những máy ảo khách này có chạy trên Citrix XenServer không? Hay phần cứng vật lý? StorageServer của chúng tôi kết nối từ vùng đất của ethernet đến vùng đất của mini-sas. Khi máy cầu này hoảng loạn, nó phải được khởi động lại mạnh mẽ. Máy khách Windows quay trở lại. Máy khách ảo Linux thể hiện cùng một vấn đề chính xác mà bạn có. Không có gì được đề xuất ở đây mang lại các điểm gắn kết trở lại rw.
rjt

@rjt, điều này xảy ra trong nhiều tình huống. Tình huống chính là khi thiết bị bị chậm quá mức với bất kỳ vấn đề nào, như hư hỏng vật lý, quá tải thiết bị, cáp, FC ngoài Eth và eth bị quá tải, đôi khi chuyển đổi thiết lập lại khi chuyển khối, hết thời gian, mất gói, v.v. nhưng được đánh dấu là chỉ đọc. Khởi động lại không phải là độ phân giải, nó là cách giải quyết như tôi đã mô tả tại phần mô tả câu hỏi / vấn đề chính.
Znik

Câu trả lời:


12

thử với blockdev --setrwhoặchdparm -r 0


cảm ơn, điều này sẽ hữu ích Tôi đang chờ bất kỳ thời gian chờ nào trên bộ điều khiển fc
Znik

Một phần quan trọng cần được thêm vào: Đôi khi cần phải thực hiện fscktrên hệ thống tệp chỉ đọc, trước khi có thể gắn lại.
Evi1M4chine

3
Diddnt làm việc cho tôi. tôi có vấn đề tương tự
jonneymendoza

1
Không làm việc cho tôi ngay cả với fsck. Citrix XenServer Linux khách.
rjt

Không làm việc ! Lệnh này có vẻ hiệu quả, nhưng dongle vẫn là RO. (nó là phần mềm, nhưng từ đâu ???) Nếu bạn muốn dùng thử, hãy lấy bất kỳ bản iso 9.4 nào.
Sandburg

5

Giống như Jose Luis Martin đề nghị sử dụng blockdev, 2cent của tôi là thực hiện một cuộc tái đấu rw và Forcefsck

(giả sử sda là đĩa của bạn)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

1
Nó có ý nghĩa hơn khi chỉ chạy fscktrước mount, vì nó sẽ không gắn kết mà không có fsck. (Ít nhất là trong trường hợp của tôi, nó đã làm.)
Evi1M4chine

`# blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: không thể chạm? / tmp / 20170722-221904?: Hệ thống tệp chỉ đọc # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs lỗi (thiết bị xvda1): ext4_remount: 4824: Hủy bỏ bởi người dùng gắn kết: không thể truy cập lại thiết bị chặn / dev / xvda1 đọc-ghi, được bảo vệ ghi `
rjt

2

Kiểm tra trang wiki này, nó giải thích lỗi do libata ném:

https://ata.wiki.kernel.org/index.php/Libata_error_messages

Từ những gì tôi thấy ở trên, bạn có một vấn đề thời gian chờ và theo tài liệu được đề cập:

Bộ điều khiển không đáp ứng với lệnh ATA đang hoạt động. Đây có thể là bất kỳ số lượng nguyên nhân. Thông thường, điều này là do lỗi hệ thống con bị gián đoạn không liên quan (thử khởi động với 'pci = nomsi' hoặc 'acpi = off' hoặc 'noapic'), đã không cung cấp ngắt khi chúng tôi mong đợi một lỗi từ phần cứng.

Bạn có thể muốn tắt ACPI (kiểm tra cách dựa trên bản phân phối của bạn) hoặc kiểm tra kernel của bạn để biết các lỗi đã biết và có thể cập nhật nó nếu nó không phải là bản mới nhất (hoặc hạ cấp nó).


Vâng, đây thực sự là thời gian chờ. Thông thường điều này xảy ra trên bộ điều khiển FC khi thiết bị mảng bị quá tải. Bạn nói đúng, trên hệ thống con ATA cục bộ, đây thường là bất kỳ lỗi phần cứng hoặc trình điều khiển / trình điều khiển chipset
Znik

Vì vậy, đó là một thời gian chờ? Vâng, những gì sudo hdparm -I /dev/sdX | grep lockednói? Nó phải nói: 'không bị khóa'. Nó cho thấy những khoảng thời gian khó hiểu trong quá khứ ở đây mỗi khi ổ cứng bị khóa bởi mật khẩu ATA (do xóa bảo mật trước đó và sự cố hệ thống sau đó khiến pw bảo mật không bị xóa nữa). Công cụ mật khẩu này thực sự có tác động rất lớn đến thần kinh của bạn. :) Ngay cả các công cụ tiêu chuẩn được cung cấp bởi nhà cung cấp ổ đĩa HD của bạn cũng hoạt động điên cuồng, như thể ổ cứng sắp chết khi mật khẩu hoạt động. Các thủ phạm cho không biết bao nhiêu những túm tóc xé ra qua nhiều năm.
cú pháp

1

Khởi động lại trong windows 10, đi đến các tùy chọn nguồn và tắt máy nhanh. sau đó khởi động lại vào linux ..gbamm tất cả đều ổn.

tắt nhanh trong windows 10 ngủ đông một số tệp và ổ đĩa được sử dụng một phần. Vì vậy, linux thấy là bận rộn.

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.