Dün biriyle burada cevabımın mantığı ve / veya doğruluğu hakkında küçük bir tartışmaya girdim , vis., Fs meta verilerini iyi bir (GB +) boyutlu SD kartta günlüğe kaydetmenin ve tutmanın kartı takacak kadar önemli olamayacağı makul bir sürede (yıl ve yıl). Karşı argümanın jist'i, SD kartlar takan insanların çevrimiçi olarak birçok hikayesi olduğu için yanlış olmalıyım gibi görünüyordu.
İçinde 7/24 kalan rw kök dosya sistemleri içeren SD kartlı cihazlara sahip olduğum için, önceliği kendi memnuniyetime göre test etmiştim. Bu testi biraz değiştirdim, tekrarladım (aslında aynı kartı kullanarak) ve burada sunuyorum. İki temel sorum var:
- Kartı enkaz haline getirmek için kullandığım yöntem, küçük miktarlarda verilerin sürekli olarak yeniden yazılmasının etkilerini yeniden oluşturmayı amaçladığını düşünerek mi?
- Kartın hala uygun olduğunu doğrulamak için kullandığım yöntem geçerli mi?
Soruyu SO veya SuperUser yerine buraya koyuyorum, çünkü ilk bölüme itiraz muhtemelen testimin karta gerçekten yaptığım şekilde yazmadığını iddia etmek zorunda kalacak ve bazılarını gerektireceğini iddia edecekti linux özel bilgisi.
[Ayrıca SD kartların bir tür akıllı tamponlama veya önbellek kullanması da olabilir, böylece aynı yere tekrarlanan yazma işlemleri aşınmaya daha az eğilimli bir yerde arabelleğe alınır / önbelleğe alınır. Bunun hiçbir yerinde bulamadım ama SU hakkında soruyorum ]
Testin arkasındaki fikir karttaki aynı küçük bloğa milyonlarca kez yazmaktır. Bu, bu tür cihazların kaç yazma döngüsünün devam edebileceğine dair herhangi bir iddianın ötesindedir, ancak aşınma seviyesinin etkili olduğunu varsayarsak , kart iyi bir boyuta sahipse, bu tür milyonlarca yazının yine de "aynı blok" gibi çok fazla önemi yoktur. kelimenin tam anlamıyla aynı fiziksel blok değildir. Bunu yapmak için, her yazının donanıma ve aynı görünür yere gerçekten akıtıldığından emin olmalıydım .
Donanımı yıkamak için POSIX kütüphane çağrısına güvendim 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;
}
Ben birikmiş dek ben, ~ 8 saat boyunca bu koştum 2000000 + yazıyor başlangıcına /dev/sdb1bölüm. 1 Kolayca kullanabildim /dev/sdb(ham cihazı ve bölümü değil) ama bunun ne gibi bir fark yaratacağını göremiyorum.
Daha sonra bir dosya sistemi oluşturmaya ve takmaya çalışarak kartı kontrol ettim /dev/sdb1. Bu, bütün gece yazdığım belirli bloğun mümkün olduğunu gösteren işe yaradı. Bununla birlikte, bu, kartın bazı bölgelerinin aşınma seviyesiyle yıpranmadığı ve yer değiştirmediği, ancak erişilebilir olduğu anlamına gelmez.
Bunu test etmek badblocks -v -wiçin bölüm üzerinde kullandım . Bu yıkıcı bir okuma-yazma testidir, ancak aşınma seviyelendirmesi olsun ya da olmasın, kartın fizibilitesinin güçlü bir göstergesi olmalıdır, çünkü her yuvarlanma yazımı için hala alan sağlamalıdır. Başka bir deyişle, kartı tamamen doldurmanın, ardından tüm bunların iyi olup olmadığını kontrol etmenin gerçek karşılığıdır. Birkaç kez, badblock'ların birkaç desenle çalışmasına izin verdim.
[Jason C'nin aşağıdaki yorumlarının aksine, badblock'ları bu şekilde kullanma konusunda yanlış veya yanlış bir şey yok. SD kartların doğası nedeniyle gerçekten kötü blokları tanımlamak için yararlı olmasa da , revize edilmiş testin gittiği yer olan -bve -canahtarları kullanarak keyfi boyutta yıkıcı okuma-yazma testleri yapmak iyidir (kendi cevabımı görün) ). Kartın denetleyicisi tarafından hiçbir sihir veya önbellek, donanıma birkaç megabayt verinin yazılabileceği ve doğru şekilde tekrar okunabileceği bir testi kandıramaz. Jason'ın diğer yorumları yanlış anlaşılmaya dayalı görünüyor - IMO kasıtlı bir yorum, bu yüzden tartışmak için rahatsız etmedim. Bu kafa kalmış, ben ne mantıklı ve ne karar vermek okuyucuya bırakıyorum yapar değil .]
1 Kart, zar zor kullandığım eski bir 4 GB Sandisk kartıydı (üzerinde "sınıf" numarası yok). Bir kez daha, bunun 2 milyon değil, aynı fiziksel yere yazıldığını unutmayın; aşınma seviyelendirmesi nedeniyle, "ilk blok" test sırasında kontrolör tarafından terimin belirttiği gibi aşınmayı düzleştirmek için sürekli olarak hareket ettirilecektir .
/dev/sdb1vs /dev/sdbsizin program için hiç fark etmez, ama ne yok (aşağıda açıklandığı gibi) bir fark yaratmak cihazınızda kullanılmayan blokların devlet sizin testinde bilinmeyen ve hesaba katılmamış olduğunu ve size tüm cihazı doldurmadan (örn /dev/sdb) önce verilerle birlikte, alan aşınması seviyesinin çalışması gereken önemli bir değişkendir. Bu nedenle, cihaz ve bölüm, testinizle alakasız olsa da, cihazı hatalı bir şekilde veriyle doldurduktan sonra, bölüm başına kullanılabilir bir seçenek olmaz (daha sonra biçimlendirilmedikçe).
badblocks, bir flash sürücüdeki sayfa hatalarını göstermek için (ve bunun çok yanıltıcı olduğunu iddia etmek için) kullanamazsınız . Bunlar denetleyici tarafından işlenir ve algılandığında yer ayırmak için eşlenir. Sürücüdeki verilerin fiziksel düzeni, G / Ç yaparken gördüğünüz fiziksel düzen ile aynı değildir, aşınma seviyelendirmesi şeffaflığını bu şekilde korur. I / O sırasında bunların hiçbiri sizin tarafınızdan görülemez. Sürücü en fazla SMART'ı destekliyorsa, kontrolörden arızalar ve kalan ayrılmış alan hakkında biraz bilgi alabilirsiniz.