Malas malas atau Melepas disk yang sibuk di Linux


19

Saya telah membaca bahwa adalah mungkin untuk 'umount' disk yang sibuk dengan menggunakan opsi 'malas'. Halaman manual ini mengatakan tentang hal itu:

umount - unmount sistem file

-L Malas meng-unmount. Lepaskan filesystem dari hirarki filesystem sekarang, dan bersihkan semua referensi ke filesystem segera setelah tidak lagi sibuk. Opsi ini memungkinkan sistem file "sibuk" untuk dilepas. (Membutuhkan kernel 2.4.11 atau yang lebih baru.)

Tapi apa gunanya itu? Saya mempertimbangkan mengapa kami menurunkan partisi sama sekali:

  1. Untuk menghapus perangkat keras
  2. Untuk melakukan operasi pada sistem file yang tidak aman untuk dilakukan saat di-mount

Dalam salah satu dari kasus-kasus ini, semua unmount 'malas' melayani IMHO adalah untuk membuatnya lebih sulit untuk menentukan apakah disk benar-benar diturunkan dan Anda benar-benar dapat melanjutkan dengan tindakan ini. Satu-satunya aplikasi untuk umount -ltampaknya bagi pengguna yang tidak berpengalaman untuk 'merasa' seperti mereka telah mencapai sesuatu yang belum mereka dapatkan.

Mengapa Anda menggunakan unmount malas?

Jawaban:


10

Karena Anda malas - Anda ingin melepasnya setelah operasi disk selesai.

Inilah skenario yang masuk akal:

Anda menggunakan rsyncuntuk melakukan backup dan berjalan pergi. Anda dapat umount -ldrive dan setelah selesai menyalin dan menyinkronkan, itu unmount, sehingga ketika Anda kembali setelah istirahat (yang Anda tahu akan memakan waktu lebih lama dari cadangan) Anda cukup mencabut drive daripada harus bermain-main dengan keyboard lagi .


Jika Anda malas, tentunya Anda ingin menghemat LEBIH BANYAK waktu dengan tidak harus menggunakan argumen, karena begitu Anda kembali, Anda tahu bahwa Anda dapat turun segera setelah cadangan selesai? Atau menjadikan turun dari drive bagian dari operasi pasca-cadangan?
deed02392

Pikirkan seperti ini: disk tidak lagi sibuk - lepaskan dari sekarang. Tidak lagi terpasang sehingga tidak ada lagi yang bisa menulis ke sana. Ini "lakukan ini saat Anda bisa" bukannya kesalahan.
Broam


5

Ini sebenarnya diterapkan untuk mendapatkan lebih banyak waktu untuk melakukan tugas tindak lanjut dalam tugas administratif.

Jika tugas lebih lanjut, terlepas dari yang satu ini sedang menunggu di saluran pipa, maka Anda bisa malas-unmount dan melanjutkan dengan yang lain di batch.

Contoh : Tugas 1 dan Tugas 2 adalah dua tugas administratif yang dijadwalkan kembali ke belakang.

Tugas 1 Pencadangan harian

Yang ini menyalin sejumlah besar file dari partisi proyek ke partisi cadangan, misalnya, / mnt / backupProj, yang akan dipasang dengan cepat dan dilepas di akhir tugas ini .. Menyalin membutuhkan waktu yang cukup lama.

Tugas 2 Perbarui tampilan SQL

Melakukan serangkaian pembaruan tampilan basis data pada server khusus.

Tugas 2 jelas sepenuhnya independen dari Tugas 1, sehingga kita dapat malas-unmount / mnt / backupProj tanpa menunggu tugas cadangan selesai.


1
Bisakah Anda memberikan contoh? Dalam situasi apa ia akan 'memperoleh / menghemat waktu'?
deed02392

4

Saya menggunakan umount malas dalam kasus-kasus di mana itu jelas macet karena berbagai alasan (seperti server nfs down), juga ketika saya perlu melihat konten asli dari direktori yang dipasang oleh mount. Dalam kedua kasus, mount sedang sibuk. Saya pikir ada kasus tepi lain tetapi 2 ini adalah alasan paling umum saya menggunakan opsi ini.


Merekomendasikan --force untuk kasus NFS.
Tom Hale

3

Pertimbangkan bind mount seperti yang mungkin Anda lihat saat bekerja dengan chroot:

mount --rbind /proc /mnt/proc
# do stuff
umount /mnt/proc

Jika Anda memiliki daemon di sistem Anda yang terus menginterogasi /proc(saya melihat Anda ksysguardd), maka Anda tidak akan bisa umount /mnt/proc. Malas akan membiarkan Anda umountdalam hal ini.


Kenapa tidak gunakan di --forcesini saja?
Tom Hale

2

USB-drive terkadang macet karena kegagalan perangkat keras. Bahkan jika Anda menghubungkan kembali drive secara fisik, Anda mendapatkan nama perangkat lain. Nama perangkat lama tidak dapat dilepas secara normal. jumlah -l memaksa entri mati menghilang.


1

Katakanlah Anda benar-benar perlu mengubah volume di mana perangkat lunak menulis log, misalnya server web, tetapi memiliki banyak lalu lintas dan tidak dapat dimatikan untuk operasi atau jalur logging tidak dapat diubah.

Dengan lazy unmount, Anda dapat dengan aman melepas volume saat perangkat lunak masih berjalan, pasang volume lain ke mountpoint yang sama dan perintahkan perangkat lunak untuk membuka kembali file.

Idealnya, karena Anda tidak perlu mematikan perangkat lunak, tidak ada permintaan yang hilang dan pada dasarnya tidak ada entri log yang hilang juga, karena mereka masih ditulis ke mount lama sampai file dibuka kembali (seberapa baik perangkat lunak menangani membuka kembali file terserah perangkat lunak).

Mengutip manpage, itu berarti bahwa jika volume memiliki file yang dibuka ketika malas dilepas, pada kenyataannya itu tetap terpasang tetapi tidak dapat diakses melalui sistem file dan hanya benar-benar dilepas ketika file terbuka terakhir ditutup.


1
Terima kasih ini kedengarannya seperti aplikasi yang berguna. Akan lsofmenampilkan file yang terbuka di mountpoint lama? Saya juga bertanya-tanya bagaimana membedakan file yang terbuka pada volume yang lama dan yang baru?
deed02392

0

Saya menggunakan ENFs untuk mengenkripsi bagian dari data sensitif saya.

Ketika disk sudah terpasang, nautilus membangun pratinjau (saya pikir, saya tidak yakin), dan mengunci file. Ketika saya ingin meng-unmount, itu mengatakan bahwa itu dikunci oleh proses lain.

Dengan malas melepasnya, folder tersebut menghilang dari hierarki saya, dan disembunyikan. Dan ketika proses latar belakang berakhir, berhasil dilepas.

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.