Bagaimana Anda memasang kembali ext3 fs readwrite setelah di-mount hanya dari kesalahan disk?


18

Ini adalah masalah yang relatif umum ketika ada kesalahan dalam SAN untuk ext3 untuk mendeteksi kesalahan penulisan disk dan remount sistem file read-only. Itu semua baik dan bagus, hanya ketika SAN diperbaiki saya tidak tahu bagaimana cara me-mount kembali filesystem read-write tanpa me-reboot.

Melihat:

[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][active]
\_ 1:0:0:1 sdb 8:16  [active][ready]
\_ 2:0:0:1 sdc 8:32  [active][ready]
[root@localhost ~]# mount /dev/mapper/mpath0 /mnt/foo
[root@localhost ~]# touch /mnt/foo/blah

Semua baik, sekarang saya mencabut LUN keluar dari bawahnya.

[root@localhost ~]# touch /mnt/foo/blah
[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system
[root@localhost ~]# tail /var/log/messages
Mar 18 13:17:33 localhost multipathd: sdb: tur checker reports path is down
Mar 18 13:17:34 localhost multipathd: sdc: tur checker reports path is down
Mar 18 13:17:35 localhost kernel: Aborting journal on device dm-2.
Mar 18 13:17:35 localhost kernel: Buffer I/O error on device dm-2, logical block 1545
Mar 18 13:17:35 localhost kernel: lost page write due to I/O error on dm-2
Mar 18 13:17:36 localhost kernel: ext3_abort called.
Mar 18 13:17:36 localhost kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb:   Detected aborted journal                      
Mar 18 13:17:36 localhost kernel: Remounting filesystem read-only

Ia hanya berpikir itu hanya baca, pada kenyataannya itu tidak ada di sana.

[root@localhost ~]# multipath -ll
sdb: checker msg is "tur checker reports path is down"
sdc: checker msg is "tur checker reports path is down"
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=0][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:1 sdb 8:16  [failed][faulty]
 \_ 2:0:0:1 sdc 8:32  [failed][faulty]
[root@localhost ~]# ll /mnt/foo/
ls: reading directory /mnt/foo/: Input/output error
total 20
-rw-r--r-- 1 root root     0 Mar 18 13:11 bar

Bagaimana ia masih ingat file 'bar' itu ada di sana ... misteri, tetapi tidak penting sekarang. Sekarang saya menyajikan ulang LUN:

[root@localhost ~]# tail /var/log/messages
Mar 18 13:23:58 localhost multipathd: sdb: tur checker reports path is up
Mar 18 13:23:58 localhost multipathd: 8:16: reinstated
Mar 18 13:23:58 localhost multipathd: mpath0: queue_if_no_path enabled
Mar 18 13:23:58 localhost multipathd: mpath0: Recovered to normal mode
Mar 18 13:23:58 localhost multipathd: mpath0: remaining active paths: 1
Mar 18 13:23:58 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:58 localhost multipathd: dm-2: devmap already registered
Mar 18 13:23:59 localhost multipathd: sdc: tur checker reports path is up
Mar 18 13:23:59 localhost multipathd: 8:32: reinstated
Mar 18 13:23:59 localhost multipathd: mpath0: remaining active paths: 2
Mar 18 13:23:59 localhost multipathd: dm-2: add map (uevent)
Mar 18 13:23:59 localhost multipathd: dm-2: devmap already registered
[root@localhost ~]# multipath -ll
mpath0 (36001f93000a310000299000200000000) dm-2 XIOTECH,ISE1400
[size=1.1T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=2][enabled]
 \_ 1:0:0:1 sdb 8:16  [active][ready]
 \_ 2:0:0:1 sdc 8:32  [active][ready]

Bagus bukan? Dikatakan [rw] di sana. Tidak terlalu cepat:

[root@localhost ~]# touch /mnt/foo/blah
touch: cannot touch `/mnt/foo/blah': Read-only file system

OK, tidak melakukannya secara otomatis, saya hanya akan memberikan sedikit dorongan:

[root@localhost ~]# mount -o remount /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Anda adalah:

[root@localhost ~]# mount -o remount,rw /mnt/foo
mount: block device /dev/mapper/mpath0 is write-protected, mounting read-only

Tidaaaaaaaak

Saya telah mencoba segala macam perintah mount / tune2fs / dmsetup yang berbeda dan saya tidak dapat menemukan cara untuk menghapus centang pada perangkat blok sebagai dilindungi dari penulisan. Reboot akan memperbaikinya, tapi saya lebih suka melakukannya secara online Satu jam pencarian Google juga membuat saya tidak punya tempat. Simpan saya ServerFault.


3
hmm, beberapa pertanyaan 'Ini masalah yang relatif umum ketika ada yang salah dalam SAN' mengapa SAN Anda tidak bisa diandalkan, saya akan memeriksanya terlebih dahulu? Sudahkah Anda mencoba meng-unmount dengan umount, dan kemudian memasangnya kembali? Apakah ada alasan bagus mengapa Anda perlu melakukan remount ?. Saya biasanya hanya perlu memount ulang sistem file root saya setelah perawatan.
The Unix Janitor

umount memantul pada pegangan file terbuka, yang sering kali dari proses Anda lebih suka keluar secara masuk akal.
cagenut

Saya memiliki masalah serupa di mana setelah masalah SAN disk VM hanya dapat dibaca dan mencoba untuk melakukan remount menyebabkan kesalahan yang sama di OP. VM ada di esxi 4.1 dengan penyimpanan saluran serat. Reboot VM memperbaiki masalah. Saya pribadi tidak berpikir bahwa ini ada hubungannya dengan multipath. Tentunya harus ada cara untuk memperbaiki tanpa me-reboot, terutama karena beberapa layanan (apache) cenderung terus berjalan pada hanya baca FS.
Will

Saya datang ke sini mencari solusi untuk masalah saya sendiri (yang berbeda, disk yang rusak). Aku malah tersenyum. +1 untuk "The hell you are"
user1207217

Saya memiliki masalah yang sama persis seperti ini, tetapi saya menggunakan LVM. Lvdisplay yang sama akan memberi saya "baca gagal setelah 0 dari 4096 di 449197309952: Kesalahan input / output" sampai saya melakukan "multipath -r", kemudian LVM mulai menampilkan semuanya dengan benar tanpa kesalahan. Saya masih tidak bisa membuat partisi untuk di-remount. Tidak dapat meng-unmount, kata perangkat sedang sibuk. Jika saya mematikan semua proses menggunakan perangkat, saya dapat melepas dan kemudian berhasil kembali, tetapi saya lebih suka hanya dapat me-remount perangkat baca-tulis, karena saya harus dapat ...
mpontes

Jawaban:


6

Saya baru-baru ini mengalami masalah ini dan menyelesaikannya dengan me-reboot tetapi setelah penyelidikan lebih lanjut tampaknya mengeluarkan perintah berikut mungkin memperbaikinya.

echo running > /sys/block/device-name/device/state

Saya pikir Anda mungkin ingin melihat pada bagian 25.14.4: Mengubah Status Baca / Tulis dari Unit Logika Online dalam dokumen ini , namun, saya sarankan untuk me-reboot.


Kevin terima kasih. (Un) untungnya masalahnya sudah lama hilang jadi saya tidak bisa mengujinya tapi ini sepertinya pilihan yang paling menjanjikan.
cagenut

3
Dalam masalah yang sama, saya pernah mengalami / sys / block / device-name / device / state sudah diatur ke 'running' dan perintah di atas tidak menyelesaikan masalah.
Will

3

Coba gunakan:

mount -o remount,rw /mnt/fo

Saya tahu FreeBSD, bukan Linux. Tapi untuk fBSD itu mount -rw /mnt/foo, jadi yang ini terlihat paling tepat untukku.
Chris S

1
Saya tidak pernah memiliki pekerjaan ini dalam skenario yang dijabarkan dalam pertanyaan. Setelah disk ditandai hanya-baca karena kesalahan, selalu diperlukan reboot untuk saya.
Alex

1
Saya akan mengedit ini ke dalam OP, tetapi Alex ada di sini, masalahnya muncul di bawah filesystem: [root @ localhost ~] # mount -o remount, rw / mnt / foo mount: block device / dev / mapper / mpath0 dilindungi dari penulisan, hanya-baca
cagenut

1
Sudahkah Anda mencoba melepas partisi dan memasang kembali partisi? Saya memiliki kesalahan data sebelumnya dengan drive, unmount (atau remount, rw) telah memperbaikinya untuk saya. Ini dengan drive SATA (dan lebih lama EIDE / SCSI) Namun, dalam situasi Anda, saya bertanya-tanya apakah masalahnya adalah bahwa saluran drive perlu diatur ulang. Saya ingin tahu apakah HDIO_DRIVE_RESET entah bagaimana mengirim melalui ioctl. blockdev dapat digunakan untuk memaksa membaca ulang tabel partisi yang mungkin melakukannya. IDE mengekspos ini dengan hdparm -w, mungkin dengan drive FC Anda, Anda punya cara untuk mengirim ioctl ke saluran.

2

Saya penggemar mencegah masalah ini sejak awal. Sebagian besar kotak UNIX perusahaan akan mencoba kembali operasi sistem file seperti selamanya. Anda sebagai administrator perlu melakukan beberapa pekerjaan rumah sebelum mengatur konfigurasi MPIO Anda. Jika aplikasi Anda harus menunggu hingga perangkat kembali ke kondisi yang dapat digunakan, maka inilah solusinya. Di /etc/multipath.conf Anda pastikan bahwa tipe perangkat yang Anda pedulikan memiliki pengaturan untuk "no_path_retry" disetel ke "antrian". Pengaturan ini akan menyebabkan I / O gagal untuk mengantri sampai ada jalur yang valid. Kami telah melakukan ini untuk kotak EMC Symmtrix / DMX kami untuk mengatasi masalah dalam kondisi tertentu drive / controller / srdf kegagalan jalur / pemulihan.

Pendekatan ini telah menghemat bacon kami berkali-kali dan merupakan standar kami untuk ratusan kotak pada SAN multicabinet / multivendor dengan replikasi untuk pemulihan bencana.

Kupikir aku mungkin berbagi dengan kalian semua. Hati hati.


2

Saya memiliki beberapa masalah, yang saya atasi menggunakan hdparm dengan -ropsi pada subdrives logis, perangkat multipath.

-R Dapatkan / atur flag hanya-baca untuk perangkat. Ketika diatur, Linux melarang operasi tulis pada perangkat.


1

Apakah menurut Anda ini terkait dengan bagian dalam dokumen ini berjudul Mengapa sistem file ext3 di Storage Area Network (SAN) saya berulang kali menjadi hanya-baca ?

Ini adalah artikel yang cukup lama, dan berbicara tentang saluran serat, tetapi mungkin terkait dengan masalah Anda.


Yap, ini bukan bug spesifik yang tepat karena saya menjalankan versi yang jauh lebih baru daripada yang mereka rujuk, tetapi segala macam situasi serupa dapat menyebabkannya. Dunia fiber-channel, driver hbas / hba-firmware / hba, firmware array, switch firmware, desain fabric, device-mapper / config multipathd, lvm, dan ext3 adalah sekadar bagian-bagian yang bergerak. Kerjakan pada lingkungan yang cukup dan Anda akan melihat skenario ini disebabkan oleh tas jepit yang memiliki masalah serupa tetapi tidak sama. Pertanyaan yang dihadapi adalah, bagaimana memulihkan / memasang kembali tanpa me-reboot.
cagenut

0

Sistem file rusak? Mencoba:

dumpe2fs /dev/c/c | grep Filesystem\

Jika bersih dengan kesalahan, maka Anda perlu memindai dan membersihkan.


-4

Linux tidak cukup baik dalam mengatasi SAN skala menengah-besar. Anda HARUS memberikannya perhatian dan menyempurnakan timeout IO dan penanganan multipath timeout, semuanya cukup banyak pada standar desktop-ready.

(Ingat "menolak IO ke perangkat mati"?)


1
Anda benar-benar perlu membuat cadangan pernyataan seperti "Linux tidak mengatasi SAN" dan "desktop ready defaults" dengan referensi dan fakta-fakta sulit.
Chris S

1
Batas waktu IO disk default 30 detik? Utas di atas? Catatan dari RedHat (sudah ketinggalan zaman) yang menyatakan bahwa mereka tidak dapat menangani "pemberitahuan perubahan status" dengan anggun, seperti yang dimaksudkan. Redhat itu secara default menempatkan binding multipath di lokasi (/ var / lib) yang tidak dapat diakses pada waktu buka driver multipath? Bahwa Anda tidak dapat menonaktifkan hot hotplug hba PCI secara rekursif dan secara temporer otomatis mengambil semua LUN yang bergantung secara offline hingga telah diganti. Itu tidak memiliki init multitreaded HW dan membutuhkan "beberapa saat" untuk menghasilkan> 1k lun. Udev, menjadi skrip shell ...
darkfader
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.