Является ли повреждение файловой системы после внезапного отключения питания в разделе ext3 диска SSD "ожидаемым поведением"?
Моя компания создает встроенное устройство 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
2 ответа
Вы оба не правы (возможно?)... ext3 справляется как можно лучше с резким удалением основного хранилища.
Ваш SSD, вероятно, имеет некоторый тип встроенного кэша. Вы не упоминаете марку / модель используемого SSD, но это звучит как потребительский SSD по сравнению с моделью корпоративного или промышленного уровня.
В любом случае, кеш используется для объединения записей и продления срока службы накопителя. Если есть транзитные записи, внезапная потеря власти, безусловно, является источником вашей коррупции. Настоящие корпоративные и промышленные твердотельные накопители имеют суперконденсаторы, которые поддерживают питание достаточно долго для перемещения данных из кэша в энергонезависимое хранилище, во многом аналогично кэш -памяти RAID-контроллера с резервным питанием от батареи и флэш-памяти.
Если на вашем диске нет суперкап, транзакции в полете теряются, что приводит к повреждению файловой системы. Возможно, ext3 говорят, что все находится в стабильном хранилище, но это только функция кеша.
Вы правы, а ваш коллега неправ. Если что-то пойдет не так, журнал гарантирует, что у вас никогда не будет противоречивых метаданных fs. Вы можете проверить с hdparm чтобы увидеть, включен ли кэш записи диска. Если это так, и вы не включили барьеры ввода / вывода (по умолчанию отключено в ext3, включено по умолчанию в ext4), то это будет причиной проблемы.
Барьеры необходимы для принудительного сброса кэша записи на диске в нужное время для поддержания согласованности, но некоторые диски плохо себя ведут и либо сообщают, что их кэш записи отключен, либо нет, либо молча игнорируют команды очистки. Это мешает журналу выполнять свою работу.