Saya masuk ke sebuah perdebatan kecil dengan seseorang kemarin mengenai logika dan / atau kebenaran jawaban saya di sini , vis., Bahwa logging dan memelihara meta-data fs pada kartu SD berukuran (GB +) yang layak tidak akan pernah cukup signifikan untuk memakai kartu dalam jumlah waktu yang wajar (bertahun-tahun). Inti dari kontra-argumen 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 filesystem rw root yang tersisa pada 24/7, saya telah menguji premis sebelumnya untuk kepuasan saya sendiri. Saya telah mengubah tes ini sedikit, mengulanginya (menggunakan kartu yang sama, sebenarnya) dan saya mempresentasikannya di sini. Dua pertanyaan utama yang saya miliki adalah:

1. Apakah metode yang saya gunakan untuk mencoba merusak kartu layak, mengingat itu dimaksudkan untuk mereproduksi efek terus menulis ulang sejumlah kecil data?
2. Apakah metode yang saya gunakan untuk memverifikasi kartu masih layak?

Saya mengajukan pertanyaan di sini daripada SO atau SuperUser karena keberatan pada bagian pertama mungkin harus menyatakan bahwa tes saya tidak benar-benar menulis ke kartu seperti yang saya yakin, dan menyatakan bahwa akan memerlukan beberapa pengetahuan khusus tentang linux.

[Bisa juga kartu SD menggunakan semacam buffering pintar atau cache, sehingga menulis berulang ke tempat yang sama akan disangga / di-cache di suatu tempat yang kurang rentan untuk dikenakan. Saya belum menemukan indikasi ini di mana pun, tetapi saya bertanya tentang itu di SU]

Gagasan 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 oleh perangkat seperti itu, tetapi menganggap leveling keausan efektif, jika kartu berukuran layak, jutaan penulisan semacam itu masih tidak terlalu penting, seperti "blok yang sama" tidak secara harfiah menjadi blok fisik yang sama. Untuk melakukan hal ini, saya perlu untuk memastikan setiap menulis itu benar-benar memerah ke perangkat keras, dan sama jelas tempat.

Untuk membilas 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,"BEGIN\n");

    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 %d\n", r, w);
            if (errno) {
                fprintf(stderr,"%s\n", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %s\n", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...\n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lu\n", count);
    close(in);
    close(out);

    return 0;
}                                 

Saya menjalankan ini selama ~ 8 jam, sampai saya mengumpulkan 2 juta + penulisan ke awal /dev/sdb1partisi. ¹ Saya bisa saja dengan mudah menggunakan /dev/sdb(perangkat mentah dan bukan partisi) tetapi saya tidak bisa melihat apa bedanya ini.

Saya kemudian memeriksa kartu dengan mencoba membuat dan me-mount sistem file aktif /dev/sdb1. Ini berhasil, menunjukkan blok spesifik yang telah saya tulis sepanjang malam itu layak. Namun, itu tidak berarti bahwa beberapa wilayah kartu tidak aus dan tergeser oleh leveling keausan, tetapi tetap dapat diakses.

Untuk mengujinya, saya gunakan badblocks -v -wpada partisi. Ini adalah tes baca-tulis yang merusak , tetapi leveling aus atau tidak, itu harus menjadi indikasi kuat kelayakan kartu karena masih harus memberikan ruang untuk setiap rolling menulis. Dengan kata lain, itu setara dengan mengisi kartu sepenuhnya, lalu memeriksa bahwa semua itu baik-baik saja. Beberapa kali, sejak saya membiarkan badblock bekerja melalui beberapa pola.

[Komentar Contra Jason C di bawah ini, tidak ada yang salah atau salah tentang menggunakan badblocks dengan cara ini. Meskipun tidak akan berguna untuk mengidentifikasi blok-blok buruk karena sifat kartu SD, tidak apa-apa untuk melakukan tes baca-tulis destruktif dengan ukuran acak menggunakan -bdan -csakelar, yang merupakan tempat uji revisi berjalan (lihat jawaban saya sendiri) ). Tidak ada jumlah sihir atau caching oleh pengontrol kartu yang dapat mengelabui 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 yang disengaja , itulah sebabnya saya tidak repot-repot berdebat. Dengan kepala itu, saya serahkan kepada pembaca untuk memutuskan apa yang masuk akal dan apa yang tidak .]

¹ Kartu itu adalah kartu Sandisk 4 GB lama (tidak ada nomor "kelas" di atasnya) yang jarang saya gunakan. Sekali lagi, perlu diingat bahwa ini bukan 2 juta menulis ke tempat fisik yang sama secara harfiah; karena leveling keausan, "blok pertama" akan dipindahkan secara konstan oleh pengontrol selama pengujian, seperti yang dinyatakan dalam istilah, leveling keausan.

Saya pikir stress testing kartu SD pada umumnya bermasalah diberikan 2 hal:

1. memakai leveling Tidak ada jaminan bahwa satu menulis ke yang berikutnya sebenarnya berolahraga di lokasi fisik yang sama di SD. Ingatlah bahwa sebagian besar sistem SD yang ada aktif mengambil blok seperti yang kita ketahui dan memindahkan lokasi fisik yang membelakanginya berdasarkan "keausan" yang dirasakan bahwa setiap lokasi telah dikenai.

2. perbedaan teknologi (MLC vs SLC) Masalah lain yang saya lihat adalah perbedaan dalam teknologi. Tipe SLC dari SSD yang saya harapkan memiliki umur yang jauh lebih lama vs varietas MLC. Juga ada banyak toleransi yang lebih ketat pada MLC yang Anda tidak harus berurusan dengan SLC, atau setidaknya mereka jauh lebih toleran terhadap kegagalan dengan cara ini.

   • MLC - Sel Multi Level
   • SLC - Sel Level Tunggal

Masalahnya dengan MLC adalah bahwa sel yang diberikan dapat menyimpan banyak nilai, bit pada dasarnya ditumpuk menggunakan tegangan, bukan hanya menjadi fisik + 5V atau 0V, 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: Know Your SSDs - SLC vs. MLC .

SLC

SSD SLC dapat dihitung, sebagian besar, untuk hidup di mana saja antara 49 tahun dan 149 tahun, rata-rata, dengan perkiraan terbaik. Pengujian Memoright dapat memvalidasi SSD 128Gb yang memiliki usia ketahanan tulis lebih dari 200 tahun dengan rata-rata penulisan 100GB per hari.

MLC

Di sinilah desain mlc jatuh pendek. Belum ada yang dirilis. Tidak ada yang benar-benar memeriksa harapan hidup seperti apa 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. Perkiraan konservatif adalah bahwa sebagian besar perkiraan umur akan datang antara 7 dan 10 tahun, tergantung pada kemajuan 'algorythms levelling pakai' dalam pengontrol setiap produsen.

Perbandingan

Untuk menggambar perbandingan melalui siklus tulis, satu slc akan memiliki masa pakai 100.000 siklus tulis lengkap dibandingkan dengan mlc yang memiliki masa pakai 10.000 siklus tulis. Ini bisa meningkat secara signifikan tergantung pada desain 'wear leveling' yang digunakan.

Ada beberapa masalah dengan tes Anda, beberapa tidak jelas, beberapa tidak. Itu juga tergantung pada tujuan Anda. Dua masalah fuzzy yang halus:

• Anda tidak membaca dari area yang sama dengan yang Anda tulis, tes membaca Anda secara efektif, maka, tidak melakukan apa-apa (kecuali controller telah membaca koreksi gangguan, dalam hal ini kadang-kadang dapat memindahkan halaman yang sedang dibaca ke tempat lain, tetapi ini masih tidak tidak memengaruhi tes Anda).
• Anda berasumsi (dan kemungkinan besar, tetapi tidak dijamin) bahwa blok baca / tulis ke blok buruk terdeteksi dan dilaporkan oleh pengontrol - Anda ingin menulis data, membacanya kembali, dan membandingkannya dengan pemeriksaan yang dijamin.

Namun, itu bisa dibilang pedantic. Lebih serius adalah:

• Anda tidak dapat menggunakan badblocksuntuk menampilkan halaman yang gagal pada memori flash; semua deteksi kegagalan dan pemetaan halaman selanjutnya dilakukan oleh pengontrol dan transparan untuk OS. Anda bisa mendapatkan beberapa info dari SMART jika drive mendukungnya (saya tahu tidak ada kartu SD yang mendukungnya, mungkin ada thumb drive yang lebih tinggi yang melakukannya).
• Leveling aus, rumit oleh pengujian Anda yang tidak memperhitungkan perintah TRIM sebelumnya, status drive yang digunakan selama pengujian, dan ruang yang dipesan.

Leveling Wear: Masalah utama adalah leveling wear adalah variabel utama dalam tes Anda. Ini terjadi pada controller (biasanya), dan dalam hal apapun transparan untuk perangkat bahkan langsung mencari + baca / tulis. Dalam contoh Anda, Anda tidak benar-benar mengetahui status level keausan (khususnya, apakah perintah TRIM telah dikeluarkan untuk membebaskan blok baru-baru ini?) ...

Untuk meratakan keausan dinamis (ada di hampir semua perangkat penyimpanan kelas konsumen) pada perangkat Anda, maka, bisa dalam keadaan apa pun: Pada satu ekstrem, tidak ada halaman yang ditandai sebagai bebas, sehingga satu-satunya halaman controller harus bekerja dengan adalah yang ada di ruang yang dipesan (jika ada). Perhatikan bahwa jika ada yang ruang dicadangkan pada perangkat, itu akan harus gagal sepenuhnya sebelum Anda mulai mendapatkan dijamin gagal pada halaman menulis (menganggap tidak ada halaman lain ditandai sebagai bebas yang tersisa). Di sisi lain, setiap halaman ditandai sebagai bebas, dalam hal ini Anda secara teoritis harus membuat setiap halaman pada perangkat gagal sebelum Anda mulai melihat kegagalan penulisan.

Untuk leveling keausan statis (yang cenderung dimiliki SSD, kartu SD cenderung tidak memilikinya, dan thumb drive berbeda-beda): Tidak ada jalan lain, selain menulis berulang-ulang ke setiap halaman di perangkat.

... Dengan kata lain, ada detail perataan keausan yang Anda tidak memiliki cara untuk mengetahui dan tentu saja tidak ada cara untuk mengendalikan - terutama apakah perataan keausan dinamis digunakan atau tidak, apakah perataan keausan statis digunakan atau tidak, dan jumlah ruang yang disediakan pada perangkat untuk meratakan keausan (yang tidak terlihat melewati controller [atau driver dalam beberapa kasus, seperti M-Systems DiskOnChip lama]).

SLC / MLC: Sedangkan untuk SLC vs MLC, ini memiliki dampak yang sangat langsung pada batas yang Anda harapkan untuk dilihat, tetapi prosedur leveling keausan umum dan prosedur pengujian adalah sama untuk keduanya. Banyak vendor tidak mempublikasikan apakah perangkat mereka SLC atau MLC untuk produk konsumen yang lebih murah, meskipun setiap flash drive yang mengklaim batas siklus 100 k + per halaman kemungkinan SLC (tradeoff yang disederhanakan adalah SLC = daya tahan, MLC = kepadatan).

Caching: Adapun caching, agak rapuh. Pada level OS, dalam kasus umum, tentu saja, fsync / fdatasync tidak menjamin bahwa data sebenarnya ditulis. Namun, saya pikir aman untuk menganggap bahwa itu (atau setidaknya controller telah berkomitmen untuk melakukannya yaitu penulisan tidak akan tertelan dalam cache) dalam kasus ini, karena drive yang dapat dilepas umumnya dirancang untuk pola penggunaan umum "eject" (unmount> sync) lalu hapus (power cut). Meskipun kita tidak tahu pasti, dugaan yang berpendidikan mengatakan bahwa aman untuk menganggap bahwa jaminan sinkronisasi bahwa penulisan akan benar-benar terjadi, terutama dalam penulisan -> sinkronisasi -> baca kembali (jika tidak, drive tidak akan dapat diandalkan setelah dikeluarkan). Tidak ada perintah lain selain 'sinkronisasi' yang dapat dikeluarkan saat dikeluarkan.

Pada controller semuanya mungkin, tetapi asumsi di atas juga mencakup asumsi bahwa controller setidaknya tidak melakukan sesuatu yang "rumit" cukup untuk mengambil risiko kehilangan data setelah sinkronisasi. Dapat dibayangkan bahwa pengontrol dapat, katakanlah, buffer dan grup menulis, atau tidak menulis data jika data yang sama sedang ditulis ulang (sampai batas tertentu). Dalam program di bawah ini, kami bergantian antara dua blok data yang berbeda dan melakukan sinkronisasi sebelum membaca kembali secara khusus untuk mengalahkan mekanisme caching pengontrol yang masuk akal. Tetap, tentu saja, tidak ada jaminan dan tidak ada cara untuk mengetahui, tetapi kita dapat membuat asumsi yang masuk akal berdasarkan penggunaan normal perangkat ini dan mekanisme caching yang waras / umum.

Pengujian:

Sayangnya, kenyataannya adalah, kecuali jika Anda tahu bahwa perangkat tidak memiliki ruang yang disediakan dan tidak melakukan perataan statis, tidak ada cara untuk secara pasti menguji batas siklus halaman tertentu. Namun, yang terdekat yang bisa Anda dapatkan adalah sebagai berikut (menganggap tidak ada leveling statis):

Hal pertama yang perlu Anda lakukan adalah mengisi seluruh kartu dengan data. Ini penting, dan merupakan variabel utama yang tersisa dalam tes asli Anda. Ini menandai sebanyak mungkin blok yang digunakan, selain dari ruang yang dipesan (yang Anda tidak memiliki cara mengakses). Perhatikan bahwa kami bekerja dengan seluruh perangkat (yang akan memusnahkan semua data), karena bekerja dengan satu partisi hanya memengaruhi satu area spesifik pada perangkat:

dd if=/dev/urandom bs=512k of=/dev/sdb conv=fsync oflag=sync

Jika Anda adalah tipe bilah kemajuan:

pv -pterb -s <device_size> /dev/urandom | dd bs=512k of=/dev/sdb conv=fsync oflag=sync

Sunting: Untuk kartu dengan blok 4MB hapus, coba ini untuk menulis lebih cepat:

dd if=/dev/urandom bs=4M of=/dev/sdb conv=fsync oflag=direct,sync iflag=fullblock

Selanjutnya, Anda dapat menulis program pengujian siklus sebagai berikut, menggunakan O_DIRECTdan O_SYNC(dan mungkin paranoid, penggunaan berlebihan fsync()) untuk memotong sebanyak mungkin buffering OS dan caching out dari gambar dan, secara teoritis, menulis langsung ke controller dan tunggu sampai melaporkan bahwa operasi telah selesai:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <cstdlib>
#include <cstdio>
#include <cstring>

using namespace std;

static const int BLOCK_SIZE = 512;
static const int ALIGNMENT = 512;
static const int OFFSET = 1024 * ALIGNMENT; // 1024 is arbitrary


int main (int argc, char **argv) {

    if (argc != 2) {
        fprintf(stderr, "usage: %s device\n", argv[0]);
        return 1;
    }

    int d = open(argv[1], O_RDWR | O_DIRECT | O_SYNC);
    if (d == -1) {
        perror(argv[1]);
        return 1;
    }

    char *block[2], *buffer;
    int index = 0, count = -1;

    // buffers must be aligned for O_DIRECT.
    posix_memalign((void **)&(block[0]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&(block[1]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&buffer, ALIGNMENT, BLOCK_SIZE);

    // different contents in each buffer
    memset(block[0], 0x55, BLOCK_SIZE);
    memset(block[1], 0xAA, BLOCK_SIZE);

    while (true) {

        // alternate buffers
        index = 1 - index;

        if (!((++ count) % 100)) {
            printf("%i\n", count);
            fflush(stdout);
        }

        // write -> sync -> read back -> compare
        if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(w)");
        else if (write(d, block[index], BLOCK_SIZE) != BLOCK_SIZE)
            perror("write");
        else if (fsync(d))
            perror("fsync");
        else if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(r)");
        else if (read(d, buffer, BLOCK_SIZE) != BLOCK_SIZE)
            perror("read");
        else if (memcmp(block[index], buffer, BLOCK_SIZE))
            fprintf(stderr, "memcmp: test failed\n");
        else
            continue;

        printf("failed after %i successful cycles.\n", count);
        break;

    }

}

Perhatikan bahwa untuk O_DIRECT, buffer harus disejajarkan. Batas-batas 512 byte umumnya cukup. Anda dapat dikompilasi dengan:

g++ -O0 test.cpp -o test

Tambahkan -D_POSIX_C_SOURCE=200112Ljika perlu.

Kemudian, setelah mengisi perangkat sepenuhnya seperti di atas, biarkan beroperasi semalam:

./test /dev/sdb

512 byte, selaras menulis baik-baik saja, yang akan memberi Anda satu halaman penuh dihapus dan ditulis ulang. Anda dapat mempercepat tes secara signifikan dengan menggunakan ukuran blok yang lebih besar, tetapi kemudian menjadi sulit untuk sampai pada hasil yang nyata.

Saat ini saya sedang menguji pada thumb drive 4GB PNY yang agak usang yang saya temukan di trotoar kemarin (tampaknya yang tersisa dari http://www3.pny.com/4GB-Micro-Sleek-Attach-- -Purple-P2990C418.aspx ).

Program di atas pada dasarnya adalah versi terbatas badblocksdan Anda tidak akan melihat kegagalan sampai semua ruang yang dicadangkan habis. Oleh karena itu, harapan (dengan 1 halaman ditulis per iterasi) adalah bahwa prosedur di atas, rata-rata, harus gagal dalam iterasi reserved_page_count * iterations write_cycle_limit (sekali lagi, leveling keausan adalah variabel utama). Sayang sekali thumb drive dan kartu SD biasanya tidak mendukung SMART, yang memiliki kemampuan untuk melaporkan ukuran ruang yang dipesan.

Omong-omong, fsyncvs fdatasynctidak membuat perbedaan untuk perangkat blok tulis yang Anda lakukan, untuk keperluan tes ini. open()Mode Anda penting.

Jika Anda ingin tahu tentang rincian teknis; di sini adalah segala sesuatu yang Anda mungkin ingin tahu (ditambah lagi) tentang cara kerja kartu SD: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Sunting: Bytes vs Pages: Dalam konteks jenis tes ini, penting untuk memikirkan hal-hal dalam hal halaman, bukan byte. Sangatlah menyesatkan untuk melakukan yang sebaliknya. Misalnya, pada SanDisk 8GB SD, ukuran halaman sesuai dengan pengontrol (dapat diakses melalui /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size) adalah 4MB penuh. Menulis 16MB (selaras dengan batas 4MB), lalu, hapus / tulis 4 halaman. Namun, menulis empat byte tunggal masing-masing pada offset 4MB dari satu sama lain juga menghapus / menulis 4 halaman.

Itu tidak akurat, maka untuk mengatakan "Saya diuji dengan menulis 16MB", karena itu adalah jumlah yang sama seperti memakai "Saya diuji dengan menulis 4 byte". Lebih tepatnya, "Saya diuji dengan 4 halaman menulis".

Hanya menambahkan beberapa poin pada jawaban slm - perhatikan ini lebih sesuai untuk SSD daripada kartu SD "bodoh", karena SSD memainkan banyak trik kotor dengan data Anda (mis. De-duplikasi):

• Anda menulis 64KB ke awal perangkat - ini sendiri memiliki dua masalah:

  1. sel flash biasanya menghapus blok ukuran dari 16KB (lebih mungkin dalam kisaran 128-512KB, meskipun). Yang berarti bahwa itu membutuhkan cache setidaknya ukuran ini. Karenanya menulis 64KB tampaknya tidak cukup bagi saya.

  2. untuk solusi low-end (baca "non-perusahaan") (dan saya berharap ini lebih untuk kartu SD / CF daripada untuk SSD) produsen dapat memilih untuk membuat permulaan perangkat lebih tangguh untuk dipakai daripada yang lain karena struktur penting - tabel partisi dan FAT pada partisi tunggal pada perangkat (sebagian besar kartu memori menggunakan pengaturan ini) - terletak di sana. Jadi pengujian awal kartu mungkin bias.

• fdatasync() tidak benar-benar menjamin bahwa data dapat ditulis ke media fisik (meskipun mungkin melakukan yang terbaik di bawah kendali OS) - lihat halaman manual:

  Panggilan memblokir hingga perangkat melaporkan bahwa transfer telah selesai

  Saya tidak akan terlalu terkejut jika ternyata ada kapasitor kecil, yang mampu memberikan energi untuk menulis data cache ke memori flash jika kehilangan daya eksternal.

  Dalam kasus apa pun, dengan asumsi ada cache pada kartu (lihat jawaban saya untuk pertanyaan Anda pada SU ), menulis 64KB dan menyinkronkan (dengan fdatasync()) tampaknya tidak cukup meyakinkan untuk tujuan ini. Bahkan tanpa "cadangan daya" firmware mungkin masih memainkannya tidak aman dan menyimpan data tidak tertulis untuk sedikit lebih lama dari yang diharapkan (karena dalam kasus penggunaan umum itu seharusnya tidak membuat masalah).

• Anda mungkin ingin membaca data sebelum menulis blok baru dan membandingkannya, hanya untuk memastikan itu benar-benar berfungsi (dan gunakan buffer yang dibersihkan untuk membaca, jika Anda cukup paranoid).

Jawaban Peterph memang membuat saya mempertimbangkan masalah kemungkinan caching lebih lanjut. Setelah menggali sekitar, saya masih tidak bisa mengatakan dengan pasti apakah ada, beberapa, atau semua kartu SD melakukan ini, tetapi saya pikir itu mungkin.

Namun, saya tidak percaya bahwa caching akan melibatkan data yang lebih besar daripada blok hapus. Untuk benar-benar yakin, saya mengulangi tes menggunakan potongan 16 MB bukannya 64 kB. Ini adalah 1/250 volume total kartu 4 GB. Butuh ~ 8 jam untuk melakukan ini 10.000 kali. Jika leveling aus melakukan yang terbaik untuk menyebarkan beban, ini berarti setiap blok fisik akan digunakan 40 kali.

Itu tidak banyak, tetapi poin asli dari tes ini adalah untuk menunjukkan kemanjuran pemakaian level dengan menunjukkan bahwa saya tidak dapat dengan mudah merusak kartu melalui penulisan berulang jumlah data sederhana ke lokasi yang sama (jelas). IMO tes 64 kB sebelumnya mungkin nyata - tetapi yang 16 MB harus. Sistem telah mem-flush data ke perangkat keras dan perangkat keras telah melaporkan penulisan tanpa kesalahan. Jika ini adalah tipuan, kartu tidak akan baik untuk apa pun, dan tidak bisa melakukan caching 16 MB di mana pun kecuali di penyimpanan utama, yang merupakan tujuan tes ini.

Mudah-mudahan, 10.000 menulis masing-masing 16 MB sudah cukup untuk menunjukkan bahwa bahkan pada kartu merek nama ujung bawah (nilai: $ 5 CDN), menjalankan sistem file rw root 24/7 yang menulis jumlah data sederhana setiap hari tidak akan memakai kartu dalam periode waktu yang wajar. 10.000 hari adalah 27 tahun ... dan kartunya masih baik-baik saja ...

Jika saya dibayar untuk mengembangkan sistem yang bekerja lebih berat dari itu, saya ingin melakukan setidaknya beberapa tes untuk menentukan berapa lama kartu dapat bertahan. Perkiraan saya adalah bahwa dengan yang seperti ini, yang memiliki kecepatan tulis rendah, bisa butuh waktu berminggu-minggu, berbulan-bulan, atau bertahun-tahun untuk menulis terus-menerus dengan kecepatan maksimal (faktanya tidak ada banyak sekali tes komparatif online semacam ini yang berbicara kepada fakta bahwa itu akan menjadi urusan yang sangat berkepanjangan).

Berkenaan dengan mengkonfirmasi kartu masih baik-baik saja, saya tidak lagi berpikir menggunakan badblockskonfigurasi default itu sesuai. Sebaliknya, saya melakukannya dengan cara ini:

badblocks -v -w -b 524288 -c 8

Yang berarti menguji menggunakan blok 512 kB yang diulang 8 kali (= 4 MB). Karena ini adalah tes rw destruktif, mungkin akan lebih baik seperti yang saya lakukan di rumah untuk menekankan perangkat jika digunakan dalam loop terus menerus.

Saya juga membuat sistem file di atasnya, disalin dalam file 2 GB, difffile melawan yang asli dan kemudian - karena file tersebut adalah iso - mount itu sebagai gambar dan menelusuri filesystem di dalamnya.

Kartu masih baik-baik saja. Yang mungkin diharapkan, setelah semua ...

;);)