Kesulitan memahami konsep pemasangan


13

Setelah membaca keduanya Apa yang dimaksud dengan memasang perangkat di Linux? dan memahami "mount" sebagai konsep di OS , saya punya masalah di mana dinyatakan itu

Semua penyimpanan yang dapat diakses harus memiliki lokasi terkait di pohon direktori tunggal ini. Ini tidak seperti Windows di mana (dalam sintaksis yang paling umum untuk jalur file) ada satu pohon direktori per komponen penyimpanan (drive). Mounting adalah tindakan mengaitkan perangkat penyimpanan ke lokasi tertentu di pohon direktori.

Tetapi sudah ada lokasi yang dapat diakses untuk mengatakan drive cdrom di bawah / dev / cdrom yang jelas datang dalam hierarki direktori. Jadi mengapa perlunya membuat "mount point" terpisah di bawah / media / cdrom? Mengapa mengakses langsung dari / dev / cdrom tidak dimungkinkan? Saya mendengar bahwa file node perangkat sama seperti file biasa. Dan membaca dan menulis kepada mereka seperti file biasa. Jadi apakah ini berarti bahwa sistem file dalam cdrom tidak tersedia jika kita mengaksesnya dari / dev / cdrom. Dan hierarki sistem file (di dalam cdrom) "menjadi hidup" ketika kita "me-mount" itu?

Jawaban:


11

Anda dapat membaca atau menulis / dev / cdrom (misalnya, menggunakan ddatau cat) tetapi ketika Anda melakukannya Anda hanya membaca atau menulis byte mentah perangkat. Itu bisa berguna dalam berbagai keadaan (seperti mengkloning partisi), tetapi umumnya kita ingin melihat direktori dan file yang tersimpan di perangkat.

Ketika Anda memasang perangkat, Anda pada dasarnya meminta kernel untuk menggunakan lapisan perangkat lunak (driver sistem file) untuk menerjemahkan byte mentah tersebut ke sistem file yang sebenarnya. Dengan demikian pemasangan perangkat menghubungkan sistem file pada perangkat itu ke hierarki direktori.


8

Saya memikirkan hal ini dengan cara berikut: mountadalah alat yang memberitahu sistem untuk menafsirkan isi beberapa file sebagai pohon direktori.

  • Sistem file memiliki direktori dan file, dan setiap file adalah label untuk beberapa byte.
  • /dev/cdrom adalah file, ini merepresentasikan string byte yang disimpan dalam CD.
  • Anda dapat membaca string yang sangat panjang ini secara langsung, tetapi ini tidak terlalu praktis kecuali untuk tujuan khusus (misalnya membuat gambar disk penuh).
  • String panjang ini memiliki struktur internal tambahan: ini berisi sistem file, yang memiliki informasi tentang direktori dan file apa yang disimpan dan di mana dalam string yang sangat panjang ini.
  • Dengan menggunakan mount -t iso9660 /dev/cdrom /media/cdrom, Anda memberi tahu sistem: "ambil rangkaian byte yang sangat panjang yang Anda miliki ini /dev/cdrom, tafsirkan sebagai pohon direktori dalam format iso9660, dan izinkan saya untuk mengaksesnya di bawah lokasi /media/cdrom".
  • Bahkan, ini berfungsi juga untuk file biasa. Anda dapat membuat file biasa yang berisi gambar disk, dan kemudian gunakan mountuntuk mengaksesnya. Coba ini:
dd jika = / dev / nol = fs-image bs = 1M hitung = 50
mke2fs fs-image
sudo mount fs-image / some / mount / point

(dua perintah pertama hanya diperlukan saat pertama kali, saat menyiapkan file gambar.)


Mengapa Anda perlu mke2fs?
ADTC

Untuk membuat sistem file ext2 kosong di dalam file gambar. Sistem file kosong tidak semuanya nol - ia memiliki beberapa metadata dan struktur tetap, seperti dokumen Word atau LibreOffice kosong memiliki beberapa ukuran bukan nol dan berisi informasi tentang misalnya font default dan ukuran halaman.
Krzysztof Kosiński

Oh OK, itu tindakan yang berpotensi merusak. Sarankan Anda menyebutkan bahwa perintah ini hanya untuk inisialisasi pertama kali. :)
ADTC

5

/dev/cdrommerujuk ke file perangkat . Ini bukan isi disk apa pun yang mungkin ingin Anda masukkan ke dalam drive optis Anda, tetapi ini adalah referensi untuk sedikit perangkat keras (dan mungkin driver perangkat lunak) yang mungkin Anda panggil untuk menunjukkannya kepada Anda. Ketika Anda mount /dev/cdromke beberapa jalur di pohon Anda, Anda melampirkan kontennya ke sistem file Anda .

Masalahnya adalah - Saya tidak bisa memikirkan cara lain untuk melakukannya. Bahkan di Windows - meskipun tidak begitu jelas - masih ada abstraksi filesystem untuk \\?\volumename\. Butuh satu menit untuk mengingat seperti apa itu, dan saya menemukan ini di Google :

... nama volume hanyalah tautan simbolis yang menunjuk kembali ke perangkat volume nyata, biasanya dalam bentuk \Device\HarddiskVolume23. Ada contoh lain dari perangkat MS-DOS yang merupakan huruf drive. Jika volume Anda memiliki huruf C: drive, Anda kemudian akan memiliki tautan simbolik yang disebut \\?\C: yang menunjuk ke volume nyata dalam \Device\HarddiskVolumeXXformat.

Dan jadi mungkin itu tidak jauh berbeda - meskipun saya berpendapat tidak terlalu rumit - itu hanya lebih jelas , saya pikir. Mereka bukan satu dan sistem yang sama, tetapi mereka juga tidak berbeda secara fundamental.

Mungkin perbedaan yang paling penting antara /dev/devicedan /path/to/its/mountadalah bahwa pada jalur terakhir sistem file - beberapa perangkat lunak yang dimaksudkan untuk menangani data secara terorganisir - menafsirkan konten yang sebelumnya. Anda tidak bisa hanya membaca disk - seseorang harus membacakannya untuk Anda. Sistem file mengartikan isi perangkat.


Ini agak menyesatkan. Jika Anda membuka /dev/cdromdalam hex editor, itu sebenarnya mengandung konten mentah dari CD-ROM. Dengan menggunakan mountAnda hanya memberi tahu OS untuk menafsirkan konten tersebut sebagai pohon direktori.
Krzysztof Kosiński

0

Selain item yang disebutkan di atas, driver atau program lain dapat menyimpan data dari perangkat. Pada perangkat baca-tulis, seperti hard disk atau thumb drive, data yang ditulis ke perangkat mungkin belum ditulis. Sistem file jurnal juga dapat mengharuskan pembilasan jurnal sebelum tidak melihat perangkat lagi. Kemudian Anda punya filesystem yang overlay filesystem lain, seperti cryptfs, yang perlu tahu kapan filesystem yang mendasarinya tidak lagi tersedia.

Memang, untuk perangkat read-only ini kurang masuk akal, tetapi masih berlaku.

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.