Pilihan sistem file untuk GNU / Linux pada kartu SD


31

Saya telah menanamkan sistem berbasis ARM yang berjalan pada kartu SD. Saat ini Debian GNU / Linux menggunakan ext3 sebagai sistem file. Ketika saya hendak menginstal ulang sistem, saya mulai bertanya-tanya tentang perubahan ke sistem file yang lebih ramah terhadap flash. Saya pernah mendengar tentang JFFS2, YAFFS2 dan LogFS, dan mereka semua tampaknya cocok untuk pekerjaan itu. Mana yang akan Anda rekomendasikan? Juga, saya pernah mendengar ada banyak perbaikan ext4 agar lebih sesuai dengan disk SSD; saya menafsirkan bahwa menjalankan ext4 seharusnya baik-baik saja? Apa yang perlu saya pikirkan terutama dalam kasus itu?

Saya kira penggunaan sistem itu penting. Tetapi untuk kepentingan umum, bayangkan itu akan melakukan hal-hal desktop standar (meskipun ini adalah sistem berbasis ARM kecil).

Terima kasih atas balasannya.

Sunting: Wikipedia memberi tahu saya (dalam pernyataan "rujukan?") Bahwa kartu memori flash yang dapat dilepas dan USB flash drive memiliki pengontrol bawaan untuk melakukan perataan level dan koreksi kesalahan sehingga penggunaan sistem file flash tertentu tidak menambah manfaat apa pun . Jadi, saya condong ke arah menempel dengan sistem file ext.

Jawaban:


18

Artikel bagus tentang sistem file flash .

Pertanyaan penting ketika berbicara tentang sistem file flash adalah sebagai berikut: Apa itu leveling keausan? Artikel Wikipedia . Pada dasarnya, pada flash disk Anda dapat menulis beberapa kali hingga blok menjadi buruk. Setelah itu, filesystem (jika tidak ada manajemen leveling memakai built-in pada perangkat keras, seperti dalam kasus SSD biasanya ada) harus menandai blok yang tidak valid, dan hindari menggunakannya lagi.

Sistem file umum (misalnya ReiserFS, NTFS, ext3, dan sebagainya) dirancang untuk hard disk, yang tidak memiliki batasan seperti itu.

JFFS2

Termasuk kompresi dan perlindungan level aus yang elegan.

YAFFS2

  • Satu hal yang membuat perbedaan: waktu mount yang singkat, setelah umount berhasil.
  • Menerapkan tulis sekali properti: sekali data ditulis ke satu blok, tidak perlu menulis ulang. Ini penting, karena mengurangi keausan.

LogFS

  • Tidak terlalu matang, tetapi sudah termasuk dalam pohon kernel Linux.
  • Mendukung sistem file yang lebih besar daripada JFFS2 / YAFFS2 tanpa masalah.

UBIFS

  • Lebih dewasa daripada LogFS
  • Tulis dukungan caching
  • Tentang skalabilitas: artikel . Pada disk besar, kinerja lebih baik daripada dengan JFFS2

ext4

Jika tidak ada driver atau kartu (misalnya drive SSD yang memiliki perataan keausan internal, setidaknya biasanya) menangani perataan keausan, maka ext4 bukanlah ide terbaik, karena tidak dimaksudkan untuk penggunaan flash mentah.

Yang mana yang terbaik?

Tentu saja, itu tergantung pada penggunaan dan dukungan. Dari apa yang saya baca di Internet, saya akan merekomendasikan UBIFS. Dukungan yang baik untuk sistem file besar, fase pengembangan matang, kinerja yang memadai dan tidak ada kerugian besar.


6
Terima kasih, ini sangat informatif! Namun, "catatan merah besar" dari situs web UBIFS mengatakan: "Satu hal yang harus dipahami orang ketika berhadapan dengan UBIFS adalah bahwa UBIFS sangat berbeda dengan sistem file tradisional - ini tidak bekerja di atas perangkat blok (seperti hard drive) , Kartu MMC / SD, USB flash drive, SSD, dll.) UBIFS dirancang untuk bekerja di atas raw flash, yang tidak ada hubungannya dengan perangkat blok. Inilah sebabnya mengapa UBIFS tidak bekerja pada kartu MMC dan sejenisnya - mereka terlihat seperti memblokir perangkat ke dunia luar karena mereka mengimplementasikan dukungan FTL (Flash Translation Layer) dalam perangkat keras. "
gspr

3
Jawaban yang bagus, ditambah ada F2FS dari Samsung, juga sistem yang sangat menjanjikan, cukup baru.
lzap

16
@ gspr benar: SD memiliki lapisan terjemahan flash, dan JFFS2, YAFFS2, LOGFS dan UBIFS semuanya dirancang untuk flash yang tidak dikelola . Opsi untuk SD adalah sistem file block device tradisional, seperti ext2 / ext3 / ext4.
Robert Calhoun

@ Olli Apakah NILFS2 pilihan yang baik untuk drive SSD?
SebMa

12

Saya menghadapi masalah yang sama dan melakukan riset juga. Akhirnya saya memutuskan untuk menggunakan ext2.

Tampaknya beberapa kartu SDHC menerapkan level-aus mereka sendiri pada lapisan perangkat keras. Jika Anda dapat memperoleh kartu SDHC yang memiliki buit-in level-wear.

Filesystem yang menyediakan level-aus dapat mengganggu level-aus level-Flash sehingga benar-benar buruk bagi flash untuk menggunakannya (artikel IBM yang dikutip di atas berbicara tentang bagaimana JFFS melakukannya, jadi jelas bahwa itu tidak akan berfungsi dengan level flash WL). Saya memutuskan saya tidak perlu membuat jurnal ext3 karena saya tidak menyimpan data penting di dalamnya dan saya biasanya membuat cadangan secara teratur (cron).

Saya juga me-mount / tmp dan / var sebagai tmpfs untuk mempercepat. Jika Anda memiliki cukup RAM, Anda harus melakukannya (tetapi pastikan untuk memutar atau menghapus log Anda secara teratur)

PETUNJUK: Pasang kartu SD ext Anda dengan opsi "noatime"


Saya punya masalah dengan SD-card lama dan ext2 (korupsi data) yang hilang ketika beralih ke XFS.
Alexander

1

Saya tidak tahu apakah ini cocok dengan profil sistem Anda, tetapi bagaimana dengan menggunakan sistem file readonly plus partisi read-write (atau usb stick yang dapat diganti dengan mudah)? Dengan begitu Anda akan memiliki disk cepat untuk OS Anda dan dapat mengganti penyimpanan rw Anda dengan mudah saat aus.

Dan kemudian ada serikat pekerja. Seperti yang saya mengerti itu "menumpuk" sistem file yang berbeda (yaitu ro fs di atas rw fs). Jika ada akses baca, unionfs mencari melalui tumpukan sampai menyentuh FS yang berisi file yang kami cari. Saat menulis unionfs mencari FS yang dapat ditulisi pertama di stack dan menggunakannya.

Saya juga menemukan artikel-artikel ini yang mungkin menarik: http://www.linux-mag.com/id/7357/ http://www.linux-mag.com/id/7345/

Dan dua artikel dengan tips untuk menggunakan SSD: http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a- tweaker-guide-to-solid-state-drive-ssds-and-linux / 9190


1
Perhatikan bahwa saya bukan orang yang menurunkan jawaban ini. Ini berisi informasi yang bermanfaat secara umum, tetapi itu tidak terkait dengan apa yang saya butuhkan. Terima kasih :)
gspr

0

Memilih (dan menentukan ukuran) sistem file yang benar lebih penting daripada hal lainnya, tidak hanya untuk keamanan tetapi untuk banyak alasan lain orang biasanya tidak mengenali. Tanpa sistem file semua pemrosesan akan menjadi nol.

Tanggapan Olli sangat bagus, dan OP jauh ketinggalan zaman, tetapi sistem file adalah kesayangan peliharaan saya, saya tidak bisa menjauh. superuser.com bukan sesuatu yang saya kunjungi sebelumnya, saya bukan admin, tapi saya mendaftar dan saya akan mengunjungi lebih banyak.

Banyak hal berubah sejak 2011, tetapi bahkan saat itu saya memformat FAT kartu USB, dan menggunakan drive USB untuk membawa file 4Gb +. Alasannya tentu saja adalah kompatibilitas bukan keamanan (begitu banyak untuk S di SD, tapi saya menggunakan kata sandi pada 7z saya), dan saya tidak pernah benar-benar membawa sesuatu yang lebih besar dari CD ISO, mereka sebagian besar untuk skrip SQL dan perbedaan setiap hari sudah snapshot database terenkripsi diperas sampai hampir mati oleh 7-Zip.

Hari ini saya memakai SD apa saja lebih cepat daripada siapa pun yang saya kenal. Saya memiliki stik USB di beberapa mesin produksi di perusahaan saya untuk cadangan otomatis per jam, format FAT. Saya mengawasi mereka setiap hari dan - Anda dapat menebaknya - mendukung mereka secara agama dengan tangan (mereka dijamin membangun barang-barang ITAR secara offline). SSD meratakan beberapa bidang permainan tapi saya masih tidak mempercayai mereka sebanyak HD biasa, dan SD lebih buruk daripada optik. Mereka menjadi buruk dalam sekejap dan kerugiannya total.

Setiap sistem file yang mengundang OS host untuk menulis secara acak padanya (NTFS, Recycle Bin) adalah berita buruk bagi SD. Selain itu, melepasnya sangat membantu, tidak ada OS yang akan mencoba mengakses penyimpanan yang tidak di-mount, sehingga sistem file apa pun akan melakukan asalkan SD menyertakan skrip untuk melepaskannya sendiri (salah satu file standar pada setiap SD di tambang).

Membaca SD masih lambat hari ini, jadi saya akan merekomendasikan sesuatu seperti disk dump (dd) untuk mengambil seluruh gambar saat mirroring daripada file-by file. dd juga memberi tahu Anda bila ada sesuatu yang salah, sehingga pengelola file Anda tidak akan kaboom.

Tentu saja, jika tujuan utama Anda adalah untuk memperpanjang umur beberapa sen-saham Anda salah tentang bisnis Anda. Saya melakukan apa yang tidak saya lakukan untuk memperpanjang usia SD tetapi untuk mencegahnya menjadi buruk ketika saya tidak menonton, dan ada perbedaannya.

Saya menghindari ext4 atau FS penjurnalan pada SD karena saya tidak peduli ketika mereka menulis buruk kepada mereka, tetapi pasti menyakitkan ketika sehari atau lebih kemudian saya tidak bisa membacanya!


2
Maaf tapi ini tidak benar-benar menjawab pertanyaan. Ini esai yang menarik tentang penggunaan media yang dapat dilepas tetapi bukan tentang pilihan sistem file.
tersangka

Saya ingin berkomentar tetapi saya tidak bisa. Postingnya agak bertele-tele, yang saya sarankan bukan OP sedang mempertimbangkan, saya malah merekomendasikan FAT. Seharusnya saya menyusun dengan lebih fokus dan jelas.
arch-abit

Kenapa begitu Any file system which invites the host OS to write randomly to it (NTFS, Recycle Bin) is bad news for an SD.? Itu tidak terdiri dari memutar disk, jadi di mana pun Anda membaca / menulis tidak masalah, saya pikir. Dan btw, NTFS menulis secara berdekatan - yang mengarah pada fragmentasi. «Penyimpanan file acak» adalah, misalnya, tentang EXTα.
Hi-Angel

0

Sebagai tanggapan terhadap rekomendasi untuk menggunakan fat (32?): Saya telah melakukan beberapa tes kinerja dan mengetahui bahwa fat32 memiliki waktu yang sangat dapat diprediksi untuk menulis file (2 GB membutuhkan dua kali 1 GB + offset, 3 GB membutuhkan waktu pohon 1GB + offset). Performa ext4 sedikit lebih baik dari ext3. Baik ext3 dan ext4 kadang-kadang cepat tetapi kadang-kadang perlu waktu ekstra untuk menulis file jurnal ke disk (tidak ada perilaku waktu tulis linear). Semua tes dilakukan dengan fsync () untuk memastikan file tersebut benar-benar ditulis ke disk. Saya melakukan beberapa tes dengan sinkronisasi (). Mereka menghasilkan kinerja menulis yang sangat buruk. Jadi saya kembali ke fsync (). Saya melakukan pengecekan apakah fsync () sudah cukup. Karena itu saya memberi daya pada perangkat tanpa mematikan sistem atau melepaskan Kartu SD tanpa melepasnya. Dalam kasus apa pun file tertulis atau struktur direktori rusak.

Salam, Thomas


1
Perbandingannya tidak adil. Anda membandingkan FAT non-jurnal dengan penjurnalan EXT3 / 4. Anda harus membandingkan FAT vs EXT2. Dan hanya FYI, sistem file yang datang diformat oleh pabrikan biasanya memiliki ukuran blok / offset paling optimal. Yaitu setelah Anda memformat ulang sistem file, ada kemungkinan bahwa IO akan memakan waktu lebih lama daripada yang asli.
Hi-Angel

0

jika Anda ingin kehilangan kartu sd gratis saya sarankan menggunakan BTRFSkarena:

BTRFS adalah sistem file baru dibandingkan dengan EXT yang awalnya dibuat oleh Oracle pada 2007.

Ini membawa fitur baru ke sistem file tradisional:

  • Kloning / foto
  • Diffs (kirim / terima)
  • Quotat
  • Persatuan
  • Penyembuhan sendiri (dengan periode komit default ke 30-an)

untuk penjelasan dan perbandingan tambahan, lihat pdf ini

untuk perbandingan baru lihat situs ini

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.