Masalahnya
Partisi disk tidak dipasang setelah sistem boot, apakah reboot direncanakan atau tidak direncanakan. Sebelum reboot, partisi disk sudah terpasang dan berfungsi dengan baik. Disk telah terpasang dengan benar setelah sistem lain di-boot ulang, tetapi tidak lagi berfungsi.
Perilaku ini dapat terjadi terlepas dari jenis sistem berkas pada partisi dan tidak terkait dengan jenis sistem berkas. Kegagalan disk dengan sistem file EXT4 atau OCFS2 telah dilaporkan, tetapi dapat terjadi pada semua jenis sistem file.
Entri tipikal dalam file /etc/fstab mungkin mirip dengan:
/dev/sda1 /mydir ext4 defaults 0 0 /dev/mapper/mpath2 /otherdir ocfs2 _netdev 0 0
atau berbagai kombinasinya.
Solusinya
Disk drive dan partisi dialamatkan secara geografis di Linux, sesuai dengan posisi bus dan urutan penemuannya. Perangkat SAN sangat rentan terhadap perubahan dalam urutan penemuan karena waktu reboot yang bervariasi untuk SAN atau klien.
Nama file di Linux, biasanya di direktori /dev/, ditetapkan secara dinamis setiap boot sistem. Saat kernel melakukan boot, setiap perangkat yang tersedia terdeteksi dan pemberitahuan dikirim ke subsistem UDEV (manajemen perangkat ruang pengguna). Dengan membandingkan informasi dalam identifikasi perangkat kernel dengan aturan UDEV di direktori /etc/udev/rules.d, UDEV memberikan nama ke perangkat dan membuat simpul perangkat seperti /dev/sda atau /dev/mapper/mpath1 jadi bahwa aplikasi dapat mengakses perangkat. Jika perangkat yang terdeteksi adalah perangkat berstruktur blok, seringkali perangkat tersebut memiliki partisi yang berisi sistem file yang dapat dipasang sesuai dengan spesifikasi dalam file /etc/fstab.
Meskipun Linux melakukan segala upaya untuk mempertahankan nama perangkat yang sama di seluruh reboot sistem, perubahan di lingkungan eksternal dapat memengaruhi pilihan nama yang sebenarnya. Sebagai contoh:partisi SAN yang sama bisa menjadi /dev/sda pada satu klien, tetapi /dev/sdf pada node cluster lain, tergantung pada urutan di mana setiap host menemukan perangkat, atau link multipath mana yang pertama kali online. Sebuah node biasanya menemukan perangkatnya dalam urutan yang sama setiap boot, tetapi ini tidak dijamin. Diperlukan metode untuk menjamin identifikasi perangkat yang persisten dan dapat diprediksi.
Meskipun Linux mencoba untuk menetapkan kembali nama perangkat yang sama setiap reboot, tidak ada koordinasi seperti itu di seluruh node cluster. Partisi yang dapat diandalkan muncul sebagai /dev/sda1 pada satu node cluster dapat dengan mudah, dan secara sah, secara konsisten muncul sebagai /dev/sdj pada node cluster lain. Ini dapat membuat administrasi sistem di seluruh cluster lebih sulit dari yang seharusnya. Solusi yang diberikan di bawah ini juga berlaku pada kluster yang tidak mengalami masalah boot ulang.
Teknik alternatif tersedia untuk memiliki nama perangkat yang persisten dan dapat diprediksi. Mereka disajikan di bawah ini, dalam urutan kesulitan.
Memasang Berdasarkan Label
Banyak jenis sistem file mendukung pengaitan string arbitrer, atau label, dengan setiap sistem file. Sistem file EXT3 adalah contohnya:
# /sbin/e2label /dev/sda5 /home
Adalah umum untuk melihat entri /etc/fstab yang mirip dengan ini:
LABEL=/HOME /home auto defaults 0 0
untuk menemukan partisi disk berlabel /HOME, terlepas dari perangkat mana yang memunculkannya.
Sistem file OCFS2 juga menyediakan label yang dapat dikenali yang dapat digunakan dengan cara yang sama. Lihat contoh OCFS2 di bawah untuk mengetahui cara menentukan label OCFS2.
Pemasangan Dengan UUID
Banyak jenis sistem file menetapkan Pengenal Unik Universal, atau UUID, untuk setiap partisi disk yang diformat. Sistem file EXT3 dan OCFS2 adalah contohnya. UUID biasanya ditetapkan secara otomatis dan administrator sistem biasanya tidak disarankan untuk mengubah nilainya secara manual.
Pada sistem file tipe EXT3 dan lainnya, gunakan utilitas blkid yang disediakan sebagai bagian dari paket RPM e2fsprogs. Untuk contoh kita, outputnya terlihat seperti ini:
# /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/home" UUID="0c960108-7649-4d8c-a28c-2f75e2f906d3" SEC_TYPE="ext2" TYPE="ext3"
Perhatikan bahwa UUID, sebenarnya, hanya digit heksadesimal. Karakter “-” hanyalah tanda baca yang harus diabaikan.
Pada sistem file OCFS2, UUID selalu dilaporkan oleh utilitas fsck.ocfs2. Utilitas ini dapat digunakan dengan aman pada partisi disk yang terpasang jika sakelar “-n” digunakan untuk memastikan pengujian hanya-baca:
# /sbin/fsck.ocfs2 -n /dev/hda1 Checking OCFS2 filesystem in /dev/hda1: label: OCFS2 uuid: bc d0 de d0 58 ea 43 11 bd a9 e0 66 e6 cb 37 b4 number of blocks: 209632 bytes per block: 1024 number of clusters: 52408 bytes per cluster: 4096 max slots: 4 /dev/hda1 is clean. It will be checked after 20 additional mounts.
Sekali lagi, perhatikan bahwa UUID yang tepat adalah string angka heksadesimal. Di sini mereka diselingi oleh spasi, tetapi UUID yang sebenarnya hanyalah angka. Untuk mendapatkan UUID saja, cukup dengan program awk(1) singkat:
# /sbin/fsck.ocfs2 -n /dev/hda1 | /bin/awk '/uuid/ { $1 = ""; gsub( / /, "" ); print }'
bcd0ded058ea4311bda9e066e6cb37b4 Sekarang setelah kita memiliki UUID, entri /etc/fstab seperti ini akan me-mount partisi EXT3 atau OCFS2:
UUID=bcd0ded058ea4311bda9e066e6cb37b4 /ocfs2 ocfs2 _netdev 0 2 UUID=0c96010876494d8ca28c2f75e2f906d3 /home ext3 defaults 0 2
Karena UUID disimpan di partisi disk itu sendiri, tidak masalah jika nama perangkat yang sebenarnya berubah, kami memiliki metode yang dapat diprediksi dan persisten yang dijamin untuk mengaksesnya.
Menggunakan Aturan UDEV
Metode lain untuk memiliki nama perangkat yang persisten dan dapat diprediksi adalah dengan memanfaatkan layanan UDEV yang sama yang digunakan kernel untuk menetapkan nama perangkat. Ini melibatkan pembuatan aturan pencocokan UDEV yang menggunakan atribut perangkat untuk mengidentifikasi perangkat dan kemudian membuat node perangkat untuknya. Seringkali aturan hanya membuat tautan simbolis ke node perangkat tingkat rendah yang sebenarnya ditetapkan oleh kernel.
Ini adalah teknik yang digunakan untuk mengimplementasikan perangkat multipath device mapper. Kernel membuat perangkat /dev/dm-X; kemudian aturan UDEV dan daemon multipathing membuat tautan /dev/mpath/
Jenis nama file /dev/mapper/ mana yang dibuat dikendalikan oleh pengaturan file /etc/multipath.conf user_friendly_names. Pengaturan default adalah:
default {
user_friendly_names yes
}
yang, anehnya, menciptakan nama /dev/mapper/mpathN yang sama sekali tidak berarti. Dengan mengomentari ini, nama formulir /dev/mapper/
Di bawah ini adalah contoh aturan pencocokan UDEV. Baris dimulai dengan serangkaian predikat, atau ekspresi yang cocok; ini ditandai oleh operator "==". Jika semua predikat cocok dengan perangkat yang ditemukan, maka tindakan yang dilambangkan dengan klausa “=” akan diambil.
SYSFS{vendor}=="iriver" SYSFS{model}=="T10" OWNER="user" MODE="0600" SYMLINK+="iriver%n" Contoh ini membuat tautan simbolis /dev/iriver0 saat pemutar IRiver T10 pertama dicolokkan ke port USB. Perangkat akan dimiliki oleh pengguna dengan izin akses file 0600. Subsistem USB memberitahukan bahwa perangkat telah dicolokkan dan memberi tahu kernel; atribut yang ditemukan tentang perangkat juga diteruskan ke kernel. Informasi ini akhirnya sampai ke subsistem UDEV yang mulai membaca set aturan di /etc/udev/rules.d dan mencocokkan atribut perangkat dengan predikat untuk setiap aturan. Jika semua predikat cocok untuk suatu aturan, tindakan apa pun yang ditentukan oleh aturan itu akan dieksekusi.
Dokumentasi tentang sistem UDEV, termasuk sintaks untuk menulis aturan UDEV, tersedia secara online melalui halaman manual udev.
Bagian yang menantang dalam menulis aturan UDEV adalah mengetahui atribut apa yang tersedia sehingga perangkat dapat diidentifikasi dengan benar oleh aturan tersebut. Utilitas udevinfo akan menampilkan nama perangkat dan atribut yang tersedia untuk aturan. Untuk contoh kami, memeriksa /var/log/messages menunjukkan perangkat IRiver terdeteksi sebagai perangkat blok dan nama /dev/sdb ditetapkan. Sekarang, kita dapat memperoleh semua informasi dan atribut perangkat dengan melihat di bawah /block/sdb sistem informasi:
# /usr/bin/udevinfo -q all -p /block/sdb P: /block/sdb N: sdb S: disk/by-id/usb-iriver_T10 S: disk/by-path/pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0 E: ID_VENDOR=iriver E: ID_MODEL=T10 E: ID_REVISION=1.00 E: ID_SERIAL=iriver_T10 E: ID_TYPE=disk E: ID_BUS=usb E: ID_PATH=pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0Catatan bahwa path tersebut relatif terhadap direktori /sys/, bukan root tradisional. Nama file lengkapnya adalah /sys/block/sdb tetapi udevinfo mengasumsikan bagian /sys.
Memilih set atribut minimal bisa jadi rumit, tetapi hindari godaan untuk menentukan secara berlebihan. Pilihan kami di sini adalah menggunakan nama vendor dan nama model, tetapi set atribut apa pun yang mengidentifikasi perangkat objek dapat digunakan. Setelah predikat dan tindakan dipilih, letakkan aturan Anda di file mereka sendiri di direktori /etc/udev/rules.d. Jangan memodifikasi seperangkat aturan dari distribusi atau perubahan Anda dapat hilang saat paket diperbarui. Dalam contoh kami, kami menggunakan /etc/udev/rules.d/49-iriver.rules untuk nama file.
Dengan aturan UDEV Anda, gunakan utilitas udevtest untuk mensimulasikan proses UDEV dan untuk menunjukkan apa yang akan dilakukan.