Pengenalan

Pengenalan

31 Julai 2009
Oleh Pierre Vignéras


Abstrak:

Seperti yang anda mungkin tahu, Linux menyokong pelbagai sistem fail seperti ext2, ext3, ext4, xfs, reiserfs, JFS antara lain. Beberapa pengguna benar -benar menganggap bahagian sistem ini, memilih pilihan lalai pemasang pengedaran mereka. Dalam artikel ini, saya akan memberikan beberapa sebab untuk pertimbangan yang lebih baik mengenai sistem fail dan susun aturnya. Saya akan mencadangkan proses teratas untuk reka bentuk susun atur "pintar" yang kekal stabil dari masa ke masa untuk penggunaan komputer yang diberikan.

Pengenalan

Soalan pertama yang anda boleh tanya adalah mengapa terdapat banyak sistem fail, dan apakah perbezaan mereka jika ada? Untuk menjadikannya pendek (lihat Wikipedia untuk maklumat lanjut):

  • Ext2: Ia adalah Linux FS, maksud saya, yang direka khusus untuk Linux (dipengaruhi oleh EXT dan Berkeley FFS). Pro: Cepat; Kekurangan: Tidak Jurnal (Long FSCK).
  • ext3: lanjutan ext2 semulajadi. Pro: Serasi dengan Ext2, Journalized; Kekurangan: lebih perlahan daripada ext2, seperti banyak pesaing, usang hari ini.
  • ext4: lanjutan terakhir keluarga ext. Pro: Keserasian naik dengan ext3, saiz besar; prestasi bacaan yang baik; Kekurangan: Sedikit terlalu baru untuk mengetahui?
  • JFS: IBM AIX FS dipindahkan ke Linux. Pro: Matang, cepat, ringan dan boleh dipercayai, saiz besar; Kekurangan: Masih berkembang?
  • XFS: SGI IRIX FS dipindahkan ke Linux. Pro: Prestasi purata yang sangat matang dan boleh dipercayai, saiz besar, banyak alat (seperti defragmenter); Kekurangan: Tidak sejauh yang saya tahu.
  • Reiserfs: alternatif kepada sistem fail ext2/3 di linux. Pro: Cepat untuk fail kecil; Kekurangan: Masih berkembang?

Terdapat sistem fail lain, khususnya yang baru seperti BTRFS, ZFS dan NILFS2 yang mungkin juga sangat menarik. Kami akan berurusan dengan mereka kemudian dalam artikel ini.

Jadi sekarang persoalannya ialah: sistem fail mana yang paling sesuai untuk situasi tertentu anda? Jawapannya tidak mudah. Tetapi jika anda tidak benar -benar tahu, jika anda mempunyai keraguan, saya akan mengesyorkan XFS atas pelbagai sebab:

  1. Ia berfungsi dengan baik secara umum dan terutamanya pada bacaan/tulis serentak (lihat penanda aras);
  2. Ia sangat matang dan oleh itu telah diuji dan ditala secara meluas;
  3. Paling penting, ia dilengkapi dengan ciri -ciri hebat seperti xfs_fsr, mudah digunakan defragmenter (hanya lakukan ln -sf $ (yang xfs_fsr) /etc /cron.setiap hari/defrag dan lupakannya).

Satu -satunya masalah yang saya lihat dengan XFS, ialah anda tidak dapat mengurangkan XFS FS. Anda boleh mengembangkan partition XFS walaupun dipasang dan digunakan aktif (tumbuh panas), tetapi anda tidak dapat mengurangkan saiznya. Oleh itu, jika anda mempunyai beberapa sistem sistem yang diperlukan untuk memilih sistem fail lain seperti ext2/3/4 atau reiserfs (sejauh yang saya tahu, anda tidak boleh mengurangkan panas atau sistem fail reiserfs juga). Pilihan lain adalah untuk menjaga XFS dan sentiasa bermula dengan saiz partition kecil (kerana anda sentiasa boleh tumbuh panas selepas itu).

Sekiranya anda mempunyai komputer profil rendah (atau pelayan fail) dan jika anda benar -benar memerlukan CPU anda untuk sesuatu yang lain daripada berurusan dengan operasi input/output, maka saya akan mencadangkan JFS.

Sekiranya anda mempunyai banyak direktori atau/dan fail kecil, reiserfs mungkin menjadi pilihan.

Sekiranya anda memerlukan prestasi di semua kos, saya akan mencadangkan ext2.

Jujur, saya tidak melihat alasan untuk memilih ext3/4 (prestasi? Betul?).

Itu untuk pilihan sistem fail. Tetapi, soalan lain adalah susun atur yang harus saya gunakan? Dua partition? Tiga? Berdedikasi /rumah /? Baca sahaja /? Berasingan /tmp?

Jelas, tidak ada jawapan untuk soalan ini. Banyak faktor harus dipertimbangkan untuk membuat pilihan yang baik. Saya akan mula -mula menentukan faktor -faktor tersebut:

Kerumitan: Betapa kompleks susun aturnya di seluruh dunia;
Fleksibiliti: Betapa mudahnya menukar susun atur;
Prestasi: berapa cepat susun atur membolehkan sistem dijalankan.

Mencari susun atur yang sempurna adalah perdagangan antara faktor tersebut.

Susun atur lalai

Selalunya, pengguna akhir desktop dengan sedikit pengetahuan Linux akan mengikuti tetapan lalai pengedarannya di mana (biasanya) hanya dua atau tiga partition dibuat untuk Linux, dengan sistem fail akar ' /', /boot dan swap. Kelebihan konfigurasi sedemikian adalah kesederhanaan. Masalah utama ialah susun atur ini tidak fleksibel atau pelaku.

Kekurangan fleksibiliti

Kekurangan fleksibiliti jelas kerana banyak sebab. Pertama, jika pengguna akhir mahukan susun atur lain (contohnya dia mahu mengubah saiz sistem fail root, atau dia mahu menggunakan sistem fail berasingan /TMP), dia perlu reboot sistem dan menggunakan perisian pembahagian (dari LiveCD sebagai contoh). Dia harus menjaga datanya sejak penyisihan semula adalah operasi kekerasan yang tidak diketahui oleh sistem operasi.

Juga, jika pengguna akhir ingin menambah storan (contohnya cakera keras baru), dia akan mengubah suai susun atur sistem (/etc/fstab) dan selepas beberapa ketika, sistemnya hanya bergantung pada susun atur penyimpanan yang mendasari (Nombor, dan lokasi pemacu keras, partisi, dan sebagainya).

Dengan cara ini, mempunyai partition yang berasingan untuk data anda (/rumah tetapi juga semua audio, video, pangkalan data, ...) membuat lebih mudah perubahan sistem (contohnya dari satu pengedaran Linux ke yang lain). Ia juga menjadikan perkongsian data antara sistem operasi (BSD, OpenSolaris, Linux dan juga Windows) lebih mudah dan lebih selamat. Tetapi ini adalah cerita lain.

Pilihan yang baik ialah menggunakan Pengurusan Volume Logik (LVM). LVM menyelesaikan masalah fleksibiliti dengan cara yang sangat baik, seperti yang akan kita lihat. Berita baiknya ialah pengagihan yang paling moden menyokong LVM dan ada yang menggunakannya secara lalai. LVM menambah lapisan abstraksi di atas perkakasan yang mengeluarkan ketergantungan keras antara OS (/etc/fstab) dan peranti penyimpanan yang mendasari (/dev/hda,/dev/sda, dan lain -lain). Ini bermaksud bahawa anda boleh menukar susun atur penyimpanan - menambah dan mengeluarkan cakera keras - tanpa mengganggu sistem anda. Masalah utama LVM, sejauh yang saya tahu, adalah bahawa anda mungkin menghadapi masalah membaca jumlah LVM dari sistem pengendalian lain.

Kekurangan prestasi.

Apa-apa sistem fail yang digunakan (Ext2/3/4, XFS, Reiserfs, JFS), ia tidak sesuai untuk semua jenis data dan corak penggunaan (AKA Workload). Sebagai contoh, XFS diketahui baik dalam mengendalikan fail besar seperti fail video. Di sisi lain, reiserfs diketahui cekap dalam pengendalian fail kecil (seperti fail konfigurasi di direktori rumah anda atau di /dll). Oleh itu, mempunyai satu sistem fail untuk semua jenis data dan penggunaan pasti tidak optimum. Satu-satunya titik yang baik dengan susun atur ini adalah bahawa kernel tidak perlu menyokong banyak sistem fail yang berbeza, oleh itu, ia mengurangkan jumlah memori yang digunakan oleh kernel untuk minimum yang terdedah (ini juga benar dengan modul). Tetapi melainkan jika kita memberi tumpuan kepada sistem tertanam, saya menganggap hujah ini tidak relevan dengan komputer hari ini.

Memilih Perkara Yang Betul: Pendekatan Top-Bottom

Selalunya, apabila sistem direka, ia biasanya dilakukan di bawah ke pendekatan atas: perkakasan dibeli mengikut kriteria yang tidak berkaitan dengan penggunaannya. Selepas itu, susun atur sistem fail ditakrifkan mengikut perkakasan itu: "Saya mempunyai satu cakera, saya boleh memisahkannya dengan cara ini, partition ini akan muncul di sana, yang lain di sana, dan sebagainya".

Saya mencadangkan pendekatan terbalik. Kami menentukan apa yang kami mahukan pada tahap yang tinggi. Kemudian kami mengembara lapisan atas ke bawah, ke perkakasan sebenar - peranti penyimpanan dalam kes kami - seperti yang ditunjukkan pada Rajah 1. Ilustrasi ini hanyalah contoh apa yang dapat dilakukan. Terdapat banyak pilihan seperti yang akan kita lihat. Bahagian seterusnya akan menerangkan bagaimana kita boleh sampai ke susun atur global.

Rajah 1: Contoh susun atur sistem fail. Perhatikan bahawa dua partition kekal percuma (SDB3 dan SDC3). Mereka boleh digunakan untuk /boot, untuk pertukaran atau kedua -duanya. Jangan "salin/tampal" susun atur ini. Ia tidak dioptimumkan untuk beban kerja anda. Ia hanya satu contoh.

Membeli perkakasan yang betul

Sebelum memasang sistem baru, penggunaan sasaran harus dipertimbangkan. Pertama dari sudut pandangan perkakasan. Adakah sistem tertanam, desktop, pelayan, komputer pelbagai pengguna (dengan TV/Audio/Video/OpenOffice/Web/Chat/P2P, ...)?

Sebagai contoh, saya selalu mengesyorkan pengguna akhir dengan keperluan desktop mudah (web, mel, sembang, beberapa menonton media) untuk membeli pemproses kos rendah (yang paling murah), banyak ram (maksimum) dan sekurang-kurangnya dua pemacu keras.

Pada masa kini, walaupun pemproses termurah cukup jauh untuk melayari web dan menonton filem. Banyak RAM memberikan cache yang baik (Linux menggunakan memori percuma untuk caching - mengurangkan jumlah input/output yang mahal ke peranti penyimpanan). Dengan cara ini, membeli jumlah maksimum RAM, papan induk anda boleh menyokong adalah pelaburan untuk dua sebab:

  1. Aplikasi cenderung memerlukan lebih banyak memori; Oleh itu, mempunyai jumlah maksimum memori yang telah menghalang anda daripada menambah memori kemudian untuk seketika;
  2. Teknologi berubah dengan cepat sehingga sistem anda mungkin tidak menyokong memori yang ada dalam 5 tahun. Pada masa itu, membeli memori lama mungkin agak mahal.

Mempunyai dua cakera keras membolehkan mereka digunakan di cermin. Oleh itu, jika seseorang gagal, sistem akan terus berfungsi dengan normal dan anda akan mempunyai masa untuk mendapatkan cakera keras baru. Dengan cara ini, sistem anda akan tetap tersedia dan data anda, cukup selamat (ini tidak mencukupi, sandarkan data anda juga).

Menentukan corak penggunaan

Semasa memilih perkakasan, dan khususnya susun atur sistem fail, anda harus mempertimbangkan aplikasi yang akan menggunakannya. Aplikasi yang berbeza mempunyai beban kerja input/output yang berbeza. Pertimbangkan aplikasi berikut: pembalak (syslog), pembaca mel (Thunderbird, kmail), enjin carian (beagle), pangkalan data (mysql, postgresql), p2p (emule, gnutella, vuze), shells (bash) ... bolehkah anda melihat input mereka /corak output dan berapa banyak mereka berbeza?

Oleh itu, saya menentukan lokasi penyimpanan abstrak berikut yang dikenali sebagai Volum Logik - LV - dalam terminologi LVM:

TMP.LV:
untuk data sementara seperti yang terdapat di/tmp,/var/tmp dan juga di direktori rumah setiap pengguna $ home/tmp (perhatikan bahawa direktori sampah seperti $ home/sampah, $ home/.Sampah juga boleh dipetakan di sini. Sila lihat spesifikasi sampah Freedesktop untuk implikasi). Calon lain ialah /var /cache. Idea untuk jumlah logik ini adalah bahawa kita boleh menyempurnakannya untuk prestasi dan kita mungkin menerima sedikit kehilangan data kerana data ini tidak penting untuk sistem (lihat standard hierarki sistem fail Linux (FHS) untuk butiran di lokasi tersebut).
Baca.LV:
Untuk data yang kebanyakannya dibaca untuk kebanyakan fail binari dalam /bin, /usr /bin, /lib, /usr /lib, fail konfigurasi dalam /etc dan kebanyakan fail konfigurasi dalam setiap direktori pengguna $ rumah /.Bashrc, dan sebagainya. Lokasi penyimpanan ini boleh ditala untuk prestasi baca. Kami mungkin menerima prestasi menulis yang lemah kerana ia berlaku pada masa -masa yang jarang berlaku (e.G: Semasa menaik taraf sistem). Kehilangan data di sini jelas tidak boleh diterima.
tulis.LV:
untuk data yang kebanyakannya ditulis secara rawak seperti data yang ditulis oleh aplikasi P2P, atau pangkalan data. Kita boleh menyesuaikannya untuk prestasi menulis. Perhatikan bahawa prestasi baca tidak boleh terlalu rendah: kedua -dua aplikasi P2P dan pangkalan data dibaca secara rawak dan sering kali data yang mereka tulis. Kami boleh mempertimbangkan lokasi ini sebagai lokasi "semua tujuan": jika anda tidak benar-benar mengetahui corak penggunaan aplikasi yang diberikan, konfigurasinya sehingga menggunakan kelantangan logik ini. Kehilangan data di sini juga tidak boleh diterima.
tambah.LV:
untuk data yang kebanyakannya ditulis secara berurutan seperti kebanyakan fail dalam/var/log dan juga $ rumah/.XSESSION-ERRORS antara lain. Kita boleh menyesuaikannya untuk prestasi tambahan yang mungkin agak berbeza daripada prestasi menulis secara rawak. Di sana, baca prestasi biasanya tidak begitu penting (melainkan jika anda mempunyai keperluan khusus). Kehilangan data di sini tidak boleh diterima untuk kegunaan biasa (log memberikan maklumat mengenai masalah. Sekiranya anda kehilangan kayu balak anda, bagaimana anda boleh tahu apa masalahnya?).
mm.LV:
untuk fail multimedia; kes mereka agak istimewa kerana mereka biasanya besar (video) dan dibaca secara berurutan. Penalaan untuk bacaan berurutan boleh dilakukan di sini. Fail multimedia ditulis sekali (contohnya dari menulis.LV di mana aplikasi p2p menulis ke mm.lv), dan membaca banyak kali secara berurutan.

Anda boleh menambah/mencadangkan kategori lain di sini dengan corak yang berbeza seperti berurutan.Baca.LV, contohnya.

Menentukan titik gunung

Katakan bahawa kita sudah mempunyai semua lokasi abstrak penyimpanan dalam bentuk/dev/tbd/lv di mana:

  • TBD adalah kumpulan kelantangan yang akan ditakrifkan kemudian (lihat 3.5);
  • LV adalah salah satu daripada jumlah logik yang baru saja kami tentukan dalam bahagian sebelumnya (baca.LV, TMP.LV, ...).

Oleh itu, kita rasa kita sudah mempunyai/dev/tbd/tmp.lv,/dev/tbd/baca.lv,/dev/tbd/tulis.lv, dan sebagainya.

Dengan cara ini, kami menganggap bahawa setiap kumpulan volume dioptimumkan untuk corak penggunaannya (perdagangan telah ditemui antara prestasi dan fleksibiliti).

Data sementara: TMP.lv

Kami ingin mempunyai/tmp,/var/tmp, dan mana -mana $ rumah/tmp semua dipetakan ke/dev/tbd/tmp.lv.

Apa yang saya cadangkan ialah berikut:

  1. gunung/dev/tbd/tmp.lv ke a /.direktori tersembunyi TMP di peringkat akar; In /etc /fstab, anda akan mempunyai sesuatu seperti itu (sudah tentu, kerana kumpulan kelantangan tidak diketahui, ini tidak akan berfungsi; maksudnya adalah untuk menerangkan proses di sini.):
    # Ganti auto dengan sistem fail sebenar jika anda mahu # menggantikan lalai 0 2 dengan keperluan anda sendiri (lelaki fstab)/dev/tbd/tmp.lv /.TMP Auto Defaults 0 2
  2. mengikat lokasi lain ke direktori dalam /.TMP. Sebagai contoh, katakan anda tidak peduli mempunyai direktori berasingan untuk /tmp dan /var /tmp (lihat FHS untuk implikasi), anda hanya boleh membuat direktori All_tmp di dalam /dev /tbd /tmp.lv dan mengikatnya ke kedua -dua /tmp dan /var /tmp. Dalam /etc /fstab, tambahkan garis tersebut:
    /.tmp /all_tmp /tmp tiada mengikat 0 0 /.tmp/all_tmp/var/tmp tiada mengikat 0 0

    Sudah tentu jika anda lebih suka mematuhi FHS, tidak ada masalah. Buat dua direktori berbeza FHS_TMP dan FHS_VAR_TMP ke TMP.Jilid LV, dan tambahkan garis tersebut:

    /.tmp /fhs_tmp /tmp tiada mengikat 0 0 /.tmp/fhs_var_tmp/var/tmp tiada mengikat 0 0
  3. Buat Symlink untuk Direktori TMP Pengguna ke /TMP /Pengguna. Sebagai contoh, $ home/tmp adalah pautan simbolik ke/tmp/$ user_name/tmp (saya menggunakan persekitaran KDE, oleh itu, saya $ rumah/tmp adalah pautan simbolik ke/tmp/kde- $ pengguna jadi semua aplikasi kde Gunakan lv yang sama). Anda boleh mengautomasikan proses ini menggunakan beberapa baris ke dalam .bash_profile (atau bahkan di/etc/skel/.Bash_profile jadi pengguna baru akan memilikinya). Sebagai contoh:
    Jika ujian ! -e $ home/tmp -a ! -e /tmp /kde- $ user; kemudian mkdir /tmp /kde- $ user; ln -s/tmp/kde- $ user $ home/tmp; fi 

    (Skrip ini agak mudah dan hanya berfungsi dalam kes di mana kedua-dua $ home/tmp dan/tmp/kde- $ pengguna belum wujud. Anda mungkin menyesuaikannya dengan keperluan anda sendiri.)

Kebanyakannya dibaca data: Baca.lv

Oleh kerana sistem fail root mengandungi /etc, /bin, /usr /bin dan sebagainya, mereka sesuai untuk dibaca.lv. Oleh itu, dalam /etc /fstab saya akan meletakkan perkara berikut:

/dev/tbd/baca.LV / Auto Defaults 0 1 

Untuk fail konfigurasi di direktori rumah pengguna perkara tidak begitu mudah seperti yang anda boleh meneka. Seseorang boleh cuba menggunakan pembolehubah persekitaran xdg_config_home (lihat Freedesktop)

Tetapi saya tidak akan mengesyorkan penyelesaian ini kerana dua sebab. Pertama, beberapa aplikasi sebenarnya sesuai dengannya pada masa kini (lokasi lalai adalah $ rumah/.konfigurasi bila tidak ditetapkan secara eksplisit). Kedua, jika anda menetapkan xdg_config_home ke bacaan.LV sub-direktori, pengguna akhir akan menghadapi masalah dalam mencari fail konfigurasi mereka. Oleh itu, untuk kes itu, saya tidak mempunyai penyelesaian yang baik dan saya akan membuat direktori rumah dan semua fail konfigurasi yang disimpan untuk menulis umum.lokasi lv.

Kebanyakan data bertulis: tulis.lv

Untuk itu, saya akan menghasilkan semula corak yang digunakan untuk TMP.lv. Saya akan mengikat direktori yang berbeza untuk aplikasi yang berbeza. Sebagai contoh, saya akan mempunyai fstab sesuatu yang serupa dengan ini:

/dev/tbd/tulis.lv /.Tulis lalai automatik 0 2 /.tulis /db /db tiada mengikat 0 0 /.tulis /p2p /p2p tiada mengikat 0 0 /.tulis /rumah /rumah tiada mengikat 0 0 

Sudah tentu, ini menganggap bahawa direktori DB dan P2P telah dibuat dalam Write.lv.

Perhatikan bahawa anda mungkin perlu mengetahui akses hak. Satu pilihan adalah untuk memberikan hak yang sama daripada untuk /TMP di mana sesiapa sahaja boleh menulis /membaca data mereka sendiri. Ini dicapai dengan arahan Linux berikut sebagai contoh: CHMOD 1777 /P2P.

Kebanyakannya menambah data: tambah.lv

Kelantangan itu telah disesuaikan untuk aplikasi gaya pembalak seperti syslog (dan variannya syslog_ng misalnya), dan mana -mana pembalak lain (misalnya pembalak Java). The /etc /fstab sepatutnya sama dengan ini:

/dev/tbd/append.lv /.tambah lalai automatik 0 2 /.tambah /syslog /var /log tiada mengikat 0 0 /.tambah/ulog/var/ulog tiada mengikat 0 0 

Sekali lagi, Syslog dan Ulog adalah direktori yang sebelum ini dibuat ke Append.lv.

Data multimedia: mm.lv

Untuk fail multimedia, saya hanya menambah baris berikut:

 /dev/tbd/mm.LV /MM Auto Defaults 0 2

Di dalam /mm, saya membuat gambar, audio dan direktori video. Sebagai pengguna desktop, saya biasanya berkongsi fail multimedia saya dengan ahli keluarga yang lain. Oleh itu, hak akses harus direka dengan betul.

Anda mungkin lebih suka mempunyai jumlah yang berbeza untuk fail foto, audio dan video. Jangan ragu untuk mencipta jumlah logik yang sewajarnya: Foto.LV, Audios.LV dan video.lv.

Yang lain

Anda boleh menambah jumlah logik anda sendiri mengikut keperluan anda. Jilid logik cukup bebas untuk ditangani. Mereka tidak menambah overhead yang besar dan mereka memberikan banyak kelonggaran yang membantu anda mengambil sebahagian besar sistem anda terutamanya apabila memilih sistem fail yang sesuai untuk beban kerja anda.

Menentukan sistem fail untuk jumlah logik

Sekarang titik gunung kami dan jumlah logik kami telah ditakrifkan mengikut corak penggunaan aplikasi kami, kami boleh memilih sistem fail untuk setiap jilid logik. Dan di sini kita mempunyai banyak pilihan seperti yang telah kita lihat. Pertama sekali, anda mempunyai sistem fail itu sendiri (e.G: ext2, ext3, ext4, reiserfs, xfs, jfs dan sebagainya). Bagi setiap daripada mereka, anda juga mempunyai parameter penalaan mereka (seperti saiz blok penalaan, bilangan inod, pilihan log (XFS), dan sebagainya). Akhirnya, apabila pemasangan anda juga boleh menentukan pilihan yang berbeza mengikut beberapa corak penggunaan (noatime, data = writeback (ext3), halangan (xfs), dan sebagainya). Dokumentasi sistem fail harus dibaca dan difahami supaya anda dapat memetakan pilihan ke corak penggunaan yang betul. Sekiranya anda tidak mempunyai idea yang mana FS digunakan untuk tujuan itu, inilah cadangan saya:

TMP.LV:
Jumlah ini akan mengandungi pelbagai jenis data, ditulis/dibaca oleh aplikasi dan pengguna, kecil dan besar. Tanpa sebarang corak penggunaan yang ditetapkan (kebanyakannya dibaca, kebanyakannya menulis), saya akan menggunakan sistem fail generik seperti XFS atau ext4.
Baca.LV:
Jumlah ini mengandungi sistem fail root dengan banyak binari (/bin,/usr/bin), perpustakaan (/lib,/usr/lib), banyak fail konfigurasi (/etc) ... kerana kebanyakan datanya dibaca, fail tersebut -System mungkin yang mempunyai prestasi bacaan terbaik walaupun prestasi menulisnya miskin. XFS atau EXT4 adalah pilihan di sini.
tulis.LV:
ini agak sukar kerana lokasi ini adalah "Sesuai semua"Lokasi, ia harus mengendalikan membaca dan menulis dengan betul. Sekali lagi, xfs atau ext4 juga pilihan.
tambah.LV:
Di sana, kita boleh memilih sistem fail berstruktur log tulen seperti NILFS2 baru yang disokong oleh Linux sejak 2.6.30 yang sepatutnya memberikan prestasi menulis yang sangat baik (tetapi berhati -hati dengan batasannya (terutamanya, tidak ada sokongan untuk atime, atribut lanjutan dan ACL).
mm.LV:
Mengandungi fail audio/video yang boleh menjadi besar. Ini adalah pilihan yang tepat untuk xfs. Perhatikan bahawa pada IRIX, XFS menyokong seksyen masa nyata untuk aplikasi multimedia. Ini belum disokong (belum?) di bawah linux sejauh yang saya tahu.
Anda boleh bermain dengan parameter penalaan XFS (lihat Man XFS), tetapi ia memerlukan pengetahuan yang baik mengenai corak penggunaan anda dan di internal XFS.

Pada tahap yang tinggi, anda juga boleh memutuskan sama ada anda memerlukan sokongan penyulitan atau mampatan. Ini boleh membantu dalam memilih sistem fail. Contohnya, untuk mm.LV, pemampatan tidak berguna (kerana data multimedia sudah dimampatkan) sedangkan ia mungkin berguna untuk /rumah. Pertimbangkan juga jika anda memerlukan penyulitan.

Pada langkah itu kami telah memilih sistem fail untuk semua jilid logik kami. Masa sekarang akan turun ke lapisan seterusnya dan untuk menentukan kumpulan kelantangan kami.

Menentukan Kumpulan Volume (VG)

Langkah seterusnya adalah untuk menentukan kumpulan kelantangan. Pada tahap itu, kita akan menentukan keperluan kita dari segi penalaan prestasi dan toleransi kesalahan. Saya mencadangkan menentukan VGS mengikut skema berikut: [r | s].[R | w].[n] di mana:

'r' - bermaksud rawak;
's' - bermaksud berurutan;
'R' - bermaksud dibaca;
'W' - bermaksud menulis;
'n' - adalah integer positif, sifar inklusif.

Huruf menentukan jenis pengoptimuman jumlah yang dinamakan telah ditala. Nombor ini memberikan perwakilan abstrak tahap toleransi kesalahan. Sebagai contoh:

  • r.R.0 bermaksud dioptimumkan untuk dibaca secara rawak dengan tahap toleransi kesalahan 0: Kerugian data berlaku sebaik sahaja satu peranti penyimpanan gagal (sebaliknya, sistem itu bertolak ansur dengan 0 kegagalan peranti penyimpanan).
  • s.W.2 bermaksud dioptimumkan untuk tulis berurutan dengan tahap toleransi kesalahan 2: kehilangan data berlaku sebaik sahaja tiga peranti penyimpanan gagal (sebaliknya, sistem itu bertolak ansur dengan 2 kegagalan peranti penyimpanan).

Kami kemudian perlu memetakan setiap kelantangan logik ke kumpulan kelantangan yang diberikan. Saya cadangkan perkara berikut:

TMP.LV:
boleh dipetakan ke Rs.Rw.0 kumpulan kelantangan atau Rs.Rw.1 Bergantung pada keperluan anda mengenai toleransi kesalahan. Jelas sekali, jika keinginan anda adalah bahawa sistem anda kekal dalam talian pada dasar 24/24 jam, 365 hari/tahun, pilihan kedua pastinya harus dipertimbangkan. Malangnya, toleransi kesalahan mempunyai kos dari segi ruang penyimpanan dan prestasi. Oleh itu, anda tidak boleh mengharapkan tahap prestasi yang sama dari Rs.Rw.0 vg dan Rs.Rw.1 vg dengan bilangan peranti penyimpanan yang sama. Tetapi jika anda mampu membeli harga, terdapat penyelesaian untuk Rs yang cukup prestasi.Rw.1 dan juga Rs.Rw.2, 3 dan lebih! Lebih banyak lagi pada tahap ke bawah.
Baca.LV:
mungkin dipetakan ke r.R.1 vg (meningkatkan nombor toleran kesalahan jika anda memerlukan);
tulis.LV:
mungkin dipetakan ke r.W.1 VG (perkara yang sama);
tambah.LV:
mungkin dipetakan ke s.W.1 vg;
mm.LV:
mungkin dipetakan ke s.R.1 vg.

Sudah tentu, kami mempunyai pernyataan 'Mei' dan bukan 'mesti' kerana ia bergantung kepada bilangan peranti penyimpanan yang boleh anda masukkan ke dalam persamaan. Menentukan VG sebenarnya agak sukar kerana anda tidak boleh selalu abstrak sepenuhnya perkakasan yang mendasari. Tetapi saya percaya bahawa menentukan keperluan anda terlebih dahulu boleh membantu dalam menentukan susun atur sistem storan anda secara global.

Kami akan melihat di peringkat seterusnya, bagaimana untuk melaksanakan kumpulan kelantangan tersebut.

Menentukan Jilid Fizikal (PV)

Tahap itu adalah di mana anda sebenarnya melaksanakan keperluan kumpulan kelantangan yang diberikan (ditakrifkan menggunakan notasi Rs.Rw.n diterangkan di atas). Mudah -mudahan, tidak ada - sejauh yang saya tahu - banyak cara dalam melaksanakan keperluan VG. Anda boleh menggunakan beberapa ciri LVM (mencerminkan, pelucutan), RAID SOFTY (dengan Linux MD), atau RAID HARDWARE. Pilihan bergantung pada keperluan anda dan perkakasan anda. Walau bagaimanapun, saya tidak akan mengesyorkan RAID HARDWARE (pada masa kini) untuk komputer desktop atau pelayan fail kecil, kerana dua sebab:

  • Sering kali (kebanyakan masa sebenarnya), apa yang dipanggil RAID HARDWARE, sebenarnya adalah RAID perisian: anda mempunyai chipset di papan induk anda yang membentangkan pengawal serbuan kos rendah yang memerlukan beberapa perisian (pemandu) untuk melakukan kerja sebenar. Pasti, Linux Raid (MD) jauh lebih baik dari segi prestasi (saya fikir), dan dari segi fleksibiliti (pasti).
  • Kecuali anda mempunyai CPU yang sangat lama (kelas Pentium II), RAID lembut tidak begitu mahal (ini tidak begitu benar untuk RAID5 sebenarnya, tetapi untuk RAID0, RAID1, dan RAID10, itu benar).

Oleh itu, jika anda tidak mempunyai idea bagaimana untuk melaksanakan spesifikasi yang diberikan menggunakan RAID, sila lihat dokumentasi RAID.

Beberapa petunjuk namun:

  • apa sahaja dengan a .0 boleh dipetakan ke RAID0 yang merupakan gabungan RAID yang paling berprestasi (tetapi jika satu peranti penyimpanan gagal, anda kehilangan semuanya).
  • s.R.1, r.R.1 dan sr.R.1 boleh dipetakan mengikut pilihan ke RAID10 (minimum 4 peranti penyimpanan (SD) yang diperlukan), RAID5 (3 SD diperlukan), RAID1 (2 SD).
  • s.W.1, boleh dipetakan mengikut pilihan ke RAID10, RAID1 dan RAID5.
  • r.W.1, boleh dipetakan mengikut pilihan ke RAID10 dan RAID1 (RAID5 mempunyai prestasi yang sangat miskin dalam menulis secara rawak).
  • sr.R.2 boleh dipetakan ke RAID10 (beberapa cara) dan ke RAID6.

Apabila anda memetakan ruang penyimpanan ke jumlah fizikal yang diberikan, jangan lampirkan dua ruang penyimpanan dari peranti penyimpanan yang sama (i.e. partition). Anda akan kehilangan kedua -dua kelebihan prestasi dan toleransi kesalahan! Contohnya, membuat /dev /sda1 dan /dev /sda2 sebahagian daripada jumlah fizikal RAID1 yang sama tidak berguna.

Akhirnya, jika anda tidak pasti apa yang boleh dipilih antara LVM dan MDADM, saya akan mencadangkan MDADM mempunyai sedikit lebih fleksibel (ia menyokong RAID0, 1, 5 dan 10, sedangkan LVM hanya menyokong jalur (sama dengan RAID0), dan mencerminkan (serupa dengan RAID1)).

Walaupun tidak diperlukan, jika anda menggunakan MDADM, anda mungkin akan berakhir dengan pemetaan satu sama lain antara VG dan PVS. Berkata sebaliknya, anda boleh memetakan banyak PV ke satu VG. Tetapi ini agak tidak berguna dalam pendapat saya yang rendah hati. MDADM menyediakan semua fleksibiliti yang diperlukan dalam pemetaan peranti partisi/penyimpanan ke dalam pelaksanaan VG.

Menentukan partition

Akhirnya, anda mungkin ingin membuat beberapa partisi daripada peranti storan anda yang berbeza untuk memenuhi keperluan PV anda (contohnya, RAID5 memerlukan sekurang -kurangnya 3 ruang penyimpanan yang berbeza). Perhatikan bahawa dalam majoriti kes, partisi anda mesti mempunyai saiz yang sama.

Sekiranya anda boleh, saya cadangkan untuk menggunakan peranti penyimpanan secara langsung (atau hanya membuat satu partisi tunggal dari cakera). Tetapi mungkin sukar jika anda kekurangan peranti penyimpanan. Selain itu, jika anda mempunyai peranti penyimpanan saiz yang berbeza, anda perlu memisahkan salah satu daripada mereka.

Anda mungkin perlu mencari beberapa perdagangan antara keperluan PV dan peranti storan anda yang tersedia. Sebagai contoh, jika anda hanya mempunyai dua pemacu keras, pastinya anda tidak dapat melaksanakan RAID5 PV. Anda hanya perlu bergantung pada pelaksanaan RAID1.

Ambil perhatian bahawa jika anda benar-benar mengikuti proses atas bawah yang diterangkan dalam dokumen ini (dan jika anda mampu harga keperluan anda tentu saja), tidak ada perdagangan sebenar untuk menangani! 😉

/boot

Kami tidak menyebut dalam kajian kami /sistem fail boot di mana boot-loader disimpan. Ada yang lebih suka hanya mempunyai satu / di mana / boot hanya sub-direktori. Yang lain lebih suka memisahkan / dan / boot. Dalam kes kami, di mana kami menggunakan LVM dan MDADM, saya akan mencadangkan idea berikut:

  1. /Boot adalah sistem fail yang berasingan kerana sesetengah pemuat boot mungkin menghadapi masalah dengan jumlah LVM;
  2. /Boot adalah sistem fail ext2 atau ext3 kerana format tersebut disokong dengan baik oleh mana-mana pemuat boot;
  3. /saiz boot akan menjadi saiz 100 mb kerana initramfs boleh agak berat dan anda mungkin mempunyai beberapa biji dengan initramfs mereka sendiri;
  4. /Boot bukan jumlah LVM;
  5. /Boot adalah jumlah RAID1 (dibuat menggunakan mdadm). Ini memastikan bahawa sekurang -kurangnya dua peranti penyimpanan mempunyai kandungan yang sama yang terdiri daripada kernel, initramfs, sistem.peta dan barangan lain yang diperlukan untuk boot;
  6. Kelantangan /boot RAID1 diperbuat daripada dua partisi utama yang merupakan partisi pertama pada cakera masing -masing. Ini menghalang beberapa bios lama yang tidak menemui pemuat boot kerana batasan 1GB lama.
  7. Loader Boot telah dipasang pada kedua -dua partition (cakera) sehingga sistem dapat boot dari kedua -dua cakera.
  8. BIOS telah dikonfigurasi dengan betul untuk boot dari sebarang cakera.

Bertukar

Swap juga merupakan perkara yang tidak kita bincangkan sekarang. Anda mempunyai banyak pilihan di sini:

prestasi:
Sekiranya anda memerlukan prestasi di semua kos, pastinya, buat satu partition pada setiap peranti storan anda, dan gunakannya sebagai partition swap. Kernel akan mengimbangi input/output kepada setiap partition mengikut keperluannya sendiri yang membawa kepada prestasi terbaik. Perhatikan bahawa anda boleh bermain dengan keutamaan untuk memberikan beberapa keutamaan untuk diberi cakera keras (contohnya, pemacu pantas dapat diberikan keutamaan yang lebih tinggi).
toleransi kesalahan:
Jika anda memerlukan toleransi kesalahan, pastinya, pertimbangkan penciptaan jumlah swap LVM dari r r dari r.Rw.Kumpulan Volume 1 (dilaksanakan oleh RAID1 atau RAID10 PV sebagai contoh).
Fleksibiliti:
Sekiranya anda perlu mengubah saiz pertukaran anda untuk beberapa sebab, saya cadangkan untuk menggunakan satu atau banyak jumlah pertukaran LVM.

Sistem fail masa depan dan/atau eksotik

Menggunakan LVM, agak mudah untuk menubuhkan jumlah logik baru yang dibuat dari beberapa kumpulan kelantangan (bergantung kepada apa yang anda ingin uji dan perkakasan anda) dan memformatnya ke beberapa sistem fail. LVM sangat fleksibel dalam hal ini. Jangan ragu untuk membuat dan mengalih keluar sistem fail mengikut kehendak.

Tetapi dalam beberapa cara, sistem fail masa depan seperti ZFS, BTRFS dan NILFS2 tidak sesuai dengan LVM. Sebabnya ialah LVM membawa kepada pemisahan yang jelas antara keperluan aplikasi/pengguna dan pelaksanaan keperluan ini, seperti yang kita lihat. Di sisi lain, ZFS dan BTRFS mengintegrasikan kedua -dua keperluan dan pelaksanaan menjadi satu perkara. Contohnya kedua -dua ZFS dan BTRFS menyokong tahap RAID secara langsung. Perkara yang baik ialah memudahkan pembuatan susun atur sistem fail. Perkara yang buruk ialah melanggar beberapa cara pemisahan strategi kebimbangan.

Oleh itu, anda mungkin berakhir dengan kedua -dua XFS/LV/VG/MD1/SD A, B 1 dan BTRFS/SD A, B 2 di dalam sistem yang sama. Saya tidak akan mengesyorkan susun atur seperti itu dan mencadangkan untuk menggunakan ZFS atau BTRFS untuk segala -galanya atau tidak sama sekali.

Sistem fail lain yang mungkin menarik ialah NILFS2. Sistem fail berstruktur log ini akan mempunyai prestasi menulis yang sangat baik (tetapi mungkin prestasi membaca yang lemah). Oleh itu, sistem fail sedemikian mungkin merupakan calon yang sangat baik untuk jumlah logik tambahan atau pada jumlah logik yang dibuat dari Rs.W.N VOLUME GROUP.

Pemacu USB

Sekiranya anda ingin menggunakan satu atau beberapa pemacu USB dalam susun atur anda, pertimbangkan yang berikut:

  1. Jalur lebar bas USB v2 adalah 480 mbits/s (60 mbytes/s) yang cukup untuk kebanyakan aplikasi desktop (kecuali mungkin video HD);
  2. Sejauh yang saya tahu anda tidak akan menemui sebarang peranti USB yang dapat memenuhi jalur lebar usb v2.

Oleh itu, mungkin menarik untuk menggunakan beberapa pemacu USB (atau bahkan melekat) untuk menjadikannya sebahagian daripada sistem RAID, terutama sistem RAID1. Dengan susun atur seperti itu, anda boleh mengeluarkan satu pemacu USB dari array RAID1, dan menggunakannya (dalam mod baca sahaja) di tempat lain. Kemudian, anda menariknya semula dalam array RAID1 asal anda, dan dengan perintah MAGI MDADM seperti:

mdadm /dev /md0 -add /dev /sda1

Arahan akan membina semula secara automatik dan kembali ke keadaan asalnya. Saya tidak akan mengesyorkan membuat sebarang serbuan lain dari pemacu USB. Untuk RAID0, jelas: Jika anda mengeluarkan satu pemacu USB, anda kehilangan semua data anda! Untuk RAID5, mempunyai pemacu USB, dan dengan itu, keupayaan plag panas tidak menawarkan kelebihan: pemacu USB yang telah anda tarik keluar tidak berguna dalam mod RAID5! (Kenyataan yang sama untuk RAID10).

Pemacu keadaan pepejal

Akhirnya, pemacu SSD baru boleh dipertimbangkan semasa menentukan jumlah fizikal. Sifat mereka harus diambil kira:

  • Mereka mempunyai latensi yang sangat rendah (kedua -dua membaca dan menulis);
  • Mereka mempunyai prestasi dan pemecahan membaca secara rawak yang sangat baik tidak memberi kesan kepada prestasi mereka (prestasi deterministik);
  • Bilangan tulisan adalah terhad.

Oleh itu pemacu SSD sesuai untuk melaksanakan kumpulan volum RSR#n. Sebagai contoh, mm.lv dan baca.Jilid LV boleh disimpan di SSD kerana data biasanya ditulis sekali dan dibaca berkali -kali. Corak penggunaan ini sesuai untuk SSD.

Kesimpulan

Dalam proses merancang susun atur sistem fail, pendekatan atas bawah bermula dengan keperluan tahap tinggi. Kaedah ini mempunyai kelebihan yang anda boleh bergantung pada keperluan yang dibuat sebelumnya untuk sistem yang serupa. Hanya pelaksanaan yang akan berubah. Sebagai contoh, jika anda merancang sistem desktop: anda mungkin berakhir dengan susun atur yang diberikan (seperti yang ada dalam Rajah 1). Sekiranya anda memasang sistem desktop lain dengan peranti storan yang berbeza, anda boleh bergantung pada keperluan pertama anda. Anda hanya perlu menyesuaikan lapisan bawah: PV dan partition. Oleh itu, kerja besar, corak penggunaan atau beban kerja, analisis boleh dilakukan hanya satu kali setiap sistem, secara semula jadi.

Di bahagian seterusnya dan terakhir, saya akan memberikan beberapa contoh susun atur, secara kasar ditala untuk beberapa penggunaan komputer yang terkenal.

Contoh susun atur

Sebarang penggunaan, 1 cakera.

Ini (lihat susun atur atas Rajah 2) adalah keadaan yang agak pelik pada pendapat saya. Seperti yang telah dikatakan, saya menganggap bahawa mana -mana komputer harus bersaiz mengikut corak penggunaan. Dan hanya mempunyai satu cakera yang dilampirkan pada sistem anda bermakna anda menerima kegagalan lengkapnya. Tetapi saya tahu bahawa sebahagian besar komputer hari ini - terutamanya komputer riba dan netbook - dijual (dan direka) dengan hanya satu cakera. Oleh itu, saya mencadangkan susun atur berikut yang memberi tumpuan kepada fleksibiliti dan prestasi (sebanyak mungkin):

Fleksibiliti:
Oleh kerana susun atur membolehkan anda mengubah saiz volum pada kehendak;
prestasi:
Seperti yang anda boleh memilih sistem fail (ext2/3, xfs, dan sebagainya) mengikut corak akses data.
Rajah 2: Susun atur dengan satu cakera (atas) dan satu untuk penggunaan desktop dengan dua cakera (bawah).

Penggunaan desktop, ketersediaan tinggi, 2 cakera.

Di sini (lihat susun atur bawah Rajah 2), kebimbangan kami adalah ketersediaan yang tinggi. Oleh kerana kita hanya mempunyai dua cakera, hanya RAID1 yang boleh digunakan. Konfigurasi ini menyediakan:

Fleksibiliti:
Oleh kerana susun atur membolehkan anda mengubah saiz volum pada kehendak;
prestasi:
Memandangkan anda boleh memilih sistem fail (ext2/3, xfs, dan sebagainya) mengikut corak akses data dan sejak r r.R.1 VG boleh disediakan oleh PV RAID1 untuk prestasi bacaan rawak yang baik (secara purata). Perhatikan bagaimanapun, bahawa kedua -dua s.R.N dan Rs.W.n tidak dapat diberikan hanya 2 cakera untuk sebarang nilai n.
Ketersediaan Tinggi:
Sekiranya satu cakera gagal, sistem akan terus berfungsi dalam mod yang terdegradasi.

Catatan: Rantau pertukaran harus di PV RAID1 untuk memastikan ketersediaan yang tinggi.

Penggunaan desktop, prestasi tinggi, 2 cakera

Di sini (lihat susun atur teratas Rajah 3), kebimbangan kami adalah prestasi tinggi. Perhatikan bagaimanapun bahawa saya masih menganggap tidak boleh diterima kehilangan beberapa data. Susun atur ini memberikan perkara berikut:

Fleksibiliti:
Oleh kerana susun atur membolehkan anda mengubah saiz volum pada kehendak;
prestasi:
Memandangkan anda boleh memilih sistem fail (ext2/3, XFS, dan sebagainya) mengikut corak akses data, dan kerana kedua-dua r.R.1 dan Rs.Rw.0 boleh disediakan dengan 2 cakera terima kasih kepada RAID1 dan RAID0.
Ketersediaan Sederhana:
Sekiranya satu cakera gagal, data penting akan dapat diakses tetapi sistem tidak dapat berfungsi dengan betul kecuali beberapa tindakan diambil untuk memetakan /.TMP dan bertukar ke LV lain yang dipetakan ke VG selamat.
Catatan: Kawasan pertukaran dibuat dari Rs.Rw.0 VG dilaksanakan oleh RAID0 PV untuk memastikan fleksibiliti (saiz semula kawasan swap tidak menyakitkan). Pilihan lain ialah menggunakan partition keempat dari kedua -dua cakera.

Rajah 3: Atas: Susun atur untuk penggunaan desktop prestasi tinggi dengan dua cakera. Bawah: Susun atur untuk pelayan fail dengan empat cakera.


Pelayan fail, 4 cakera.

Di sini (lihat susun atur bawah Rajah 3), kebimbangan kami adalah prestasi tinggi dan ketersediaan tinggi. Susun atur ini memberikan perkara berikut:

Fleksibiliti:
Oleh kerana susun atur membolehkan anda mengubah saiz volum pada kehendak;
prestasi:
Memandangkan anda boleh memilih sistem fail (ext2/3, XFS, dan sebagainya) mengikut corak akses data, dan kerana kedua-dua Rs.R.1 dan Rs.Rw.1 boleh disediakan dengan 4 cakera terima kasih kepada RAID5 dan RAID10.
Ketersediaan Tinggi:
Sekiranya satu cakera gagal, sebarang data akan dapat diakses dan sistem akan dapat berfungsi dengan betul.

Nota 1:

Kami mungkin telah menggunakan RAID10 untuk keseluruhan sistem kerana ia memberikan pelaksanaan Rs yang sangat baik.Rw.1 vg (dan someway juga Rs.Rw.2). Malangnya, ini datang dengan kos: 4 peranti penyimpanan diperlukan (di sini partition), masing -masing kapasiti yang sama (katakan s = 500 gigabait). Tetapi jumlah fizikal RAID10 tidak memberikan kapasiti 4*s (2 terabytes) seperti yang anda harapkan. Ia hanya menyediakan separuh daripadanya, 2*s (1 terabytes). 2*s (1 terabytes) yang lain digunakan untuk ketersediaan tinggi (cermin). Lihat dokumentasi RAID untuk maklumat lanjut. Oleh itu, saya memilih untuk menggunakan RAID5 untuk melaksanakan Rs.R.1. RAID5 akan memberikan kapasiti 3*s (1.5 gigabait), baki s (500 gigabait) digunakan untuk ketersediaan tinggi. Mm.LV biasanya memerlukan banyak ruang penyimpanan kerana ia memegang fail multimedia.

Nota 2:

Sekiranya anda mengeksport melalui direktori NFS atau SMB 'rumah', anda boleh mempertimbangkan lokasi mereka dengan teliti. Sekiranya pengguna anda memerlukan banyak ruang, membuat rumah di menulis.LV (lokasi 'fit-all') mungkin mahal kerana ia disokong oleh RAID10 PV di mana separuh ruang penyimpanan digunakan untuk mencerminkan (dan prestasi). Anda mempunyai dua pilihan di sini:

  1. Sama ada, anda mempunyai penyimpanan yang cukup atau/dan pengguna anda mempunyai keperluan akses tulis rawak/berurutan yang tinggi, RAID10 PV adalah pilihan yang baik;
  2. Atau, anda tidak mempunyai simpanan yang mencukupi atau/dan pengguna anda tidak mempunyai keperluan akses tulis secara rawak/berurutan yang tinggi, RAID5 PV adalah pilihan yang baik.

Soalan, Komen & Cadangan

Sekiranya anda mempunyai sebarang pertanyaan, komen, dan/atau cadangan mengenai dokumen ini, sila hubungi saya di alamat berikut: [email protected].

Hak cipta

Dokumen ini dilesenkan di bawah a Creative Commons Atribusi-Share sama 2.0 Lesen Perancis.

Penafian

Maklumat yang terkandung dalam dokumen ini adalah untuk tujuan maklumat umum sahaja. Maklumat ini disediakan oleh Pierre Vignéras dan semasa saya berusaha untuk menyimpan maklumat terkini dan membetulkan, saya tidak membuat sebarang representasi atau jaminan apa -apa jenis, nyata atau tersirat, mengenai kesempurnaan, ketepatan, kebolehpercayaan, kesesuaian atau ketersediaan berkenaan dengan dokumen atau maklumat, produk, perkhidmatan, atau grafik yang berkaitan yang terkandung dalam dokumen untuk tujuan apa pun.

Apa -apa pergantungan yang anda letakkan pada maklumat tersebut adalah dengan ketat atas risiko anda sendiri. Sekiranya tidak, kita akan bertanggungjawab atas sebarang kerugian atau kerosakan termasuk tanpa batasan, kerugian tidak langsung atau akibat atau kerosakan, atau apa -apa kerugian atau kerosakan apa pun yang timbul daripada kehilangan data atau keuntungan yang timbul daripada, atau berkaitan dengan penggunaan ini dokumen.

Melalui dokumen ini, anda dapat menghubungkan ke dokumen lain yang tidak berada di bawah kawalan Pierre Vignéras. Saya tidak mempunyai kawalan ke atas sifat, kandungan dan ketersediaan laman web tersebut. Kemasukan sebarang pautan tidak semestinya menyiratkan cadangan atau menyokong pandangan yang dinyatakan di dalamnya.

Tutorial Linux Berkaitan:

  • Perkara yang hendak dipasang di Ubuntu 20.04
  • Perkara yang perlu dilakukan setelah memasang ubuntu 20.04 Focal Fossa Linux
  • Fail Konfigurasi Linux: 30 teratas yang paling penting
  • Perkara yang perlu dilakukan setelah memasang Ubuntu 22.04 Jur -ubur Jammy ..
  • Cara memeriksa kesihatan cakera keras dari baris arahan ..
  • Mint 20: Lebih baik daripada Ubuntu dan Microsoft Windows?
  • Muat turun linux
  • Ubuntu 20.04 Panduan
  • Manjaro Linux Windows 10 Dual Boot
  • Pengenalan kepada Automasi, Alat dan Teknik Linux