Чи пошкоджена файлова система після раптової втрати живлення на розділі SS3 накопичувача SS3 "очікуваною поведінкою"?

Моя компанія виготовляє вбудований пристрій Debian Linux, який завантажується із розділу ext3 на внутрішньому диску SSD. Оскільки пристрій є вбудованою "чорною скринькою", його зазвичай вимикають грубим шляхом, просто відрізавши живлення пристрою за допомогою зовнішнього вимикача.

Звичайно це нормально, оскільки підручні роботи ext3 підтримують порядок, тому, крім випадкової втрати частини файлу журналу, речі продовжують чіплятися.

Однак ми нещодавно бачили ряд підрозділів, де після декількох циклів жорсткої потужності розділ ext3 починає розробляти структурні проблеми - зокрема, ми запускаємо e2fsck на розділі ext3, і він виявляє ряд питань, таких як показано у списку вихідних даних у нижній частині цього питання. Запуск e2fsck, поки він не зупинить повідомлення про помилки (або переформатувати розділ), усуне проблеми.

Моє запитання ... яке значення має бачити подібні проблеми в системі ext3 / SSD, яка зазнала безлічі раптових / несподіваних відключень?

Я відчуваю, що це може бути ознакою проблеми з програмним чи апаратним забезпеченням в нашій системі, оскільки я розумію, що (заборона помилки або проблема з апаратним забезпеченням) функція перекладу ext3 повинна запобігати подібним помилкам цілісності файлової системи. (Примітка. Я розумію, що користувацькі дані не реєструються, і так можуть бути змінені / відсутні / врізані користувацькі файли; я спеціально говорю тут про помилки метаданих файлової системи, як показано нижче)

Мій колега, з іншого боку, каже, що це відома / очікувана поведінка, оскільки контролери SSD іноді переказують команди для запису, і це може спричинити плутанину журналу ext3. Зокрема, він вважає, що навіть за умови нормально функціонуючого програмного забезпечення та програмного забезпечення, що не потребує помилок, журнал ext3 лише робить пошкодження файлової системи менш ймовірним, а не неможливим, тому ми не повинні дивуватися, коли час від часу виникають подібні проблеми.

Хто з нас прав?

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

Ви обоє помиляєтесь (можливо?) ... ext3 справляється найкраще, що може бути так різко видалено основний сховище.

На вашому SSD, ймовірно, є якийсь тип вбудованого кешу. Ви не згадуєте про марку / модель SSD у використанні, але це звучить як споживчий SSD на рівні підприємства або модель промислового рівня .

У будь-якому випадку кеш використовується, щоб допомогти зблизити записи та продовжити термін служби диска. Якщо є записи без перекладу, раптова втрата влади, безумовно, є джерелом вашої корупції. У справжніх корпоративних та промислових SSD є суперконденсатори, які підтримують потужність достатньо довго, щоб переміщувати дані з кешу до енергонезалежного сховища, так само, як працюють кеш-пам'ять RAID-контролера, що підтримується батареєю .

Якщо на вашому накопичувачі немає суперкап, трансакційні операції втрачаються, отже, пошкоджена файлова система. ext3, напевно, кажуть, що все на стабільному сховищі, але це лише функція кешу.

Ви маєте рацію, а ваш колега помиляється. Журнал забороняє щось не так, гарантує, що у вас ніколи не будуть суперечливі метадані fs. Ви можете перевірити, hdparmчи ввімкнено кеш запису диска. Якщо це так, і ви не включили бар'єри вводу-виводу (вимкнено за замовчуванням у ext3, за замовчуванням у ext4), то це буде причиною проблеми.

Бар'єри необхідні, щоб змусити кеш запису накопичувача змитись у потрібний час, щоб зберегти послідовність, але деякі диски погано поводяться, або повідомляють про те, що кеш запису вимкнено, коли його немає, або мовчки ігнорують команди флеш. Це заважає журналі робити свою справу.