Saya berdebat kecil dengan seseorang kemarin mengenai logika dan/atau kebenaran jawaban saya di sini, yaitu, bahwa mencatat dan memelihara meta-data fs pada kartu SD berukuran (GB+) yang layak tidak akan pernah cukup signifikan untuk memakai kartu keluar dalam jumlah waktu yang wajar (tahun dan tahun). Inti dari argumen balasan tampaknya adalah bahwa saya pasti salah karena ada begitu banyak cerita online tentang orang-orang yang memakai kartu SD.
Karena saya memiliki perangkat dengan kartu SD di dalamnya yang berisi sistem file root rw yang dibiarkan 24/7, saya telah menguji premis sebelumnya untuk kepuasan saya sendiri. Saya telah sedikit mengubah tes ini, mengulanginya (menggunakan kartu yang sama, sebenarnya) dan menyajikannya di sini. Dua pertanyaan utama yang saya miliki adalah:
- Apakah metode yang saya gunakan untuk mencoba merusak kartu dapat dilakukan, dengan mengingat bahwa ini dimaksudkan untuk mereproduksi efek penulisan ulang terus menerus kecil jumlah data?
- Apakah metode yang saya gunakan untuk memverifikasi kartu masih baik-baik saja?
Saya mengajukan pertanyaan di sini daripada S.O. atau SuperUser karena keberatan pada bagian pertama mungkin harus menegaskan bahwa pengujian saya tidak benar-benar menulis ke kartu seperti yang saya yakini, dan menyatakan bahwa akan memerlukan beberapa pengetahuan khusus tentang linux.
[Mungkin juga kartu SD menggunakan semacam buffering atau cache pintar, sehingga penulisan berulang ke tempat yang sama akan di-buffer/cache di tempat yang tidak mudah dipakai. Saya belum menemukan indikasi ini di mana pun, tetapi saya menanyakannya di S.U.]
Ide di balik tes ini adalah menulis ke blok kecil yang sama pada kartu jutaan kali. Ini jauh melampaui klaim berapa banyak siklus tulis yang dapat dipertahankan perangkat tersebut, tetapi menganggap level keausan efektif, jika kartu berukuran layak, jutaan penulisan semacam itu masih tidak terlalu menjadi masalah, karena "blok yang sama" akan tidak secara harfiah menjadi blok fisik yang sama. Untuk melakukan ini, saya perlu memastikan setiap penulisan benar-benar di-flush ke perangkat keras, dan tampak yang sama. tempat.
Untuk pembilasan ke perangkat keras, saya mengandalkan panggilan perpustakaan POSIX fdatasync() :
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
// Compile std=gnu99
#define BLOCK 1 << 16
int main (void) {
int in = open ("/dev/urandom", O_RDONLY);
if (in < 0) {
fprintf(stderr,"open in %s", strerror(errno));
exit(0);
}
int out = open("/dev/sdb1", O_WRONLY);
if (out < 0) {
fprintf(stderr,"open out %s", strerror(errno));
exit(0);
}
fprintf(stderr,"BEGINn");
char buffer[BLOCK];
unsigned int count = 0;
int thousands = 0;
for (unsigned int i = 1; i !=0; i++) {
ssize_t r = read(in, buffer, BLOCK);
ssize_t w = write(out, buffer, BLOCK);
if (r != w) {
fprintf(stderr, "r %d w %dn", r, w);
if (errno) {
fprintf(stderr,"%sn", strerror(errno));
break;
}
}
if (fdatasync(out) != 0) {
fprintf(stderr,"Sync failed: %sn", strerror(errno));
break;
}
count++;
if (!(count % 1000)) {
thousands++;
fprintf(stderr,"%d000...n", thousands);
}
lseek(out, 0, SEEK_SET);
}
fprintf(stderr,"TOTAL %lun", count);
close(in);
close(out);
return 0;
}
Saya menjalankan ini selama ~8 jam, hingga saya mengumpulkan 2 juta+ penulisan ke awal /dev/sdb1 partisi. Saya bisa saja dengan mudah menggunakan /dev/sdb (perangkat mentah dan bukan partisi) tetapi saya tidak dapat melihat perbedaan apa yang akan dibuat.
Saya kemudian memeriksa kartu dengan mencoba membuat dan memasang sistem file di /dev/sdb1 . Ini berhasil, menunjukkan bahwa blok khusus yang telah saya tulis sepanjang malam itu layak. Namun, itu tidak berarti bahwa beberapa bagian kartu tidak aus dan tergeser oleh levelling keausan, tetapi dibiarkan dapat diakses.
Untuk mengujinya, saya menggunakan badblocks -v -w pada partisi. Ini adalah merusak tes baca-tulis, tetapi keausan atau tidak, itu harus menjadi indikasi yang kuat dari kelayakan kartu karena masih harus menyediakan ruang untuk setiap rolling write. Dengan kata lain, ini secara literal setara dengan mengisi kartu sepenuhnya, lalu memeriksa apakah semuanya baik-baik saja. Beberapa kali, karena saya membiarkan badblock bekerja melalui beberapa pola.
[Berlawanan dengan komentar Jason C di bawah, tidak ada yang salah atau salah tentang penggunaan badblock dengan cara ini. Meskipun tidak akan berguna untuk benar-benar mengidentifikasi blok buruk karena sifat kartu SD, tidak apa-apa untuk melakukan tes baca-tulis destruktif dengan ukuran arbitrer menggunakan -b dan -c switch, di situlah tes yang direvisi berjalan (lihat jawaban saya sendiri). Tidak ada keajaiban atau caching oleh pengontrol kartu yang dapat menipu tes di mana beberapa megabyte data dapat ditulis ke perangkat keras dan dibaca kembali dengan benar. Komentar Jason yang lain tampaknya didasarkan pada kesalahan membaca — IMO disengaja satu, itulah sebabnya saya tidak repot-repot berdebat. Dengan keputusan itu, saya menyerahkan kepada pembaca untuk memutuskan apa yang masuk akal dan apa yang tidak .]
Kartu itu adalah kartu Sandisk 4 GB lama (tidak memiliki nomor "kelas" di dalamnya) yang jarang saya gunakan. Sekali lagi, perlu diingat bahwa ini bukan 2 juta tulisan ke tempat fisik yang sama; karena perataan keausan, "blok pertama" akan dipindahkan secara konstan oleh pengontrol selama pengujian untuk, seperti istilah yang dinyatakan, meratakan keausan.
Jawaban yang Diterima:
Saya pikir stress testing kartu SD secara umum bermasalah mengingat 2 hal:
-
memakai leveling
Tidak ada jaminan bahwa satu penulisan ke penulisan berikutnya benar-benar menggunakan lokasi fisik yang sama di SD. Ingatlah bahwa sebagian besar sistem SD yang ada secara aktif mengambil blok seperti yang kita ketahui dan memindahkan lokasi fisik yang mendukungnya berdasarkan persepsi "keausan" yang dialami setiap lokasi. -
perbedaan teknologi (MLC vs. SLC)
Masalah lain yang saya lihat adalah perbedaan teknologi. Jenis SSD SLC yang saya harapkan memiliki masa pakai yang jauh lebih lama dibandingkan dengan jenis MLC. Juga ada toleransi yang jauh lebih ketat pada MLC yang tidak harus Anda tangani di SLC, atau setidaknya mereka jauh lebih toleran terhadap kegagalan dengan cara ini.- MLC – Sel Multi Level
- SLC – Sel Tingkat Tunggal
Masalah dengan MLC adalah bahwa sel tertentu dapat menyimpan beberapa nilai, bit pada dasarnya ditumpuk menggunakan tegangan, bukan hanya menjadi +5V atau 0V fisik, misalnya, jadi ini dapat menyebabkan potensi tingkat kegagalan yang jauh lebih tinggi daripada SLC mereka. setara.
Harapan hidup
Saya menemukan tautan ini yang membahas sedikit tentang berapa lama perangkat keras dapat bertahan. Judulnya:Kenali SSD Anda – SLC vs. MLC.
SLC
SSD SLC dapat dihitung, untuk sebagian besar, untuk hidup di mana saja antara 49 tahun dan 149 tahun, rata-rata, dengan perkiraan terbaik. Pengujian Memoright dapat memvalidasi SSD 128 Gb yang memiliki umur ketahanan tulis lebih dari 200 tahun dengan rata-rata tulis 100 Gb per hari.
MLC
Di sinilah desain mlc gagal. Belum ada yang dirilis. Tidak ada yang benar-benar meneliti seperti apa harapan hidup yang dijamin dengan mlc kecuali bahwa, itu akan jauh lebih rendah. Saya telah menerima beberapa keyakinan berbeda yang rata-rata mencapai 10 hingga 1 umur yang mendukung desain slc. Dugaan konservatif adalah bahwa sebagian besar perkiraan umur akan datang antara 7 dan 10 tahun, tergantung pada kemajuan 'algoritma perataan keausan' dalam pengontrol masing-masing pabrikan.
Perbandingan
Untuk menarik perbandingan dengan cara menulis siklus, slc akan memiliki masa hidup 100.000 siklus tulis lengkap dibandingkan dengan mlc yang memiliki masa hidup 10.000 siklus tulis. Ini dapat meningkat secara signifikan tergantung pada desain 'perataan keausan' yang digunakan.