SSD sürücüsünün ext3 bölümünün ani güç kaybı sonrası dosya sistemi bozulması “beklenen davranış” mı?

Şirketim, dahili bir SSD sürücüdeki ext3 bölümünden önyükleme yapan yerleşik bir Debian Linux aygıtı yapıyor. Cihaz gömülü bir "kara kutu" olduğu için, cihaza harici bir anahtar aracılığıyla gücü keserek genellikle kaba bir şekilde kapatılır.

Bu normalde uygundur, çünkü ext3'ün günlüğe kaydetme işleri düzenli tutar, bu nedenle bir günlük dosyasının bir kısmının zaman zaman kaybedilmesi dışında, işler iyi bir şekilde bozulmaya devam eder.

Bununla birlikte, son zamanlarda bir dizi sert güç döngüsünden sonra ext3 bölümünün yapısal sorunlar geliştirmeye başladığı bir dizi birim gördük - özellikle, ext3 bölümünde e2fsck çalıştırıyoruz ve bunun gibi bir takım sorunlar buluyoruz bu Sorunun altındaki çıktı listesinde gösterilir. Hataları bildirmeyi durdurana kadar (veya bölümü yeniden biçimlendirme) e2fsck'i çalıştırmak sorunları temizler.

Benim sorum ... ani / beklenmedik kapanmalara maruz kalmış bir ext3 / SSD sisteminde böyle problemleri görmenin etkileri nelerdir?

Benim düşüncem, bunun sistemimizdeki bir yazılım veya donanım sorununun işareti olabileceğidir, çünkü benim anlayışım (bir hata veya donanım sorununu engelleme) ext3'ün günlük oluşturma özelliğinin bu tür dosya sistemi bütünlüğü hatalarını önleyeceği varsayılmaktadır. (Not: Kullanıcı verilerinin günlüğe kaydedilmediğini ve bu nedenle munged / eksik / kesilmiş kullanıcı dosyalarının olabileceğini anlıyorum; Burada özellikle aşağıda gösterilenler gibi dosya sistemi-meta veri hataları hakkında konuşuyorum)

Öte yandan iş arkadaşım bunun bilinen / beklenen davranış olduğunu söylüyor çünkü SSD denetleyicileri bazen yazma komutlarını yeniden sıralıyor ve bu ext3 günlüğünün karışmasına neden olabilir. Özellikle, normal olarak çalışan donanım ve hatasız yazılımlar bile verildiğinde, ext3 dergisinin dosya sistemi bozulmasını imkansız değil, sadece daha az olası hale getirdiğine inanmaktadır, bu nedenle zaman zaman bu tür problemleri görmekten şaşırmamalıyız.

Hangimiz haklı?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

İkiniz de yanılıyorsunuz (belki?) ... ext3, temeldeki depolama biriminin aniden kaldırılmasıyla elinden gelenin en iyisini yapıyor.

SSD'nizde muhtemelen bir tür yerleşik önbellek vardır. Kullanımda olan SSD'nin markasından / modelinden bahsetmiyorsunuz, ancak bu, kurumsal veya endüstriyel düzeyde bir modele karşı tüketici düzeyinde bir SSD'ye benziyor .

Her iki durumda da, önbellek yazma işlemlerini birleştirmeye ve sürücünün ömrünü uzatmaya yardımcı olmak için kullanılır. Transit geçişte yazarlar varsa, ani güç kaybı kesinlikle yolsuzluğunuzun kaynağıdır. Gerçek kurumsal ve endüstriyel SSD'lerde , verileri önbellekten kalıcı depolamaya taşıyacak kadar uzun süre güç sağlayan süper kapasitörler vardır, aynı şekilde pil destekli ve flash destekli RAID denetleyici önbellekleri de çalışır .

Sürücünüzde bir üst kapak yoksa, uçuştaki işlemler kaybolur, bu nedenle dosya sistemi bozulması olur. ext3'e muhtemelen her şeyin kararlı bir depolama alanında olduğu söyleniyor, ancak bu sadece önbelleğin bir işlevi.

Haklısın ve iş arkadaşın yanlış. Yanlış giden bir şeyi engellemek, dergi tutarsız fs meta verilerine sahip olmamanızı sağlar. hdparmSürücünün yazma önbelleğinin etkin olup olmadığını kontrol edebilirsiniz . Öyleyse ve IO bariyerlerini etkinleştirmediyseniz (ext3'te varsayılan olarak kapalı, ext4'te varsayılan olarak açıksa), sorunun nedeni budur.

Tutarlılığı korumak için sürücü yazma önbelleğini doğru zamanda çalkalamaya zorlamak için bariyerler gerekir, ancak bazı sürücüler kötü davranır ve yazma önbelleklerinin devre dışı bırakılmadığında devre dışı bırakıldığını bildirir veya temizleme komutlarını sessizce göz ardı eder. Bu derginin işini yapmasını engeller.