Является ли повреждение файловой системы после внезапного отключения питания в разделе 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

— Джереми Фризнер
источник

Вы все думали о переходе на ext4 или ZFS?

— MDPC

Я думал о переходе на ext4, по крайней мере ... это поможет решить эту проблему? Будет ли ZFS еще лучше?

— Джереми Фризнер

Ни один из вариантов не исправит это. Мы по-прежнему используем устройства с суперконденсаторами в ZFS, а кэш-память с защитой от батареи или флэш-память рекомендуется для ext4 в серверных приложениях.

— 2012 года

Ответы:

Вы оба не правы (возможно?) ... ext3 справляется как можно лучше с резким удалением основного хранилища.

Ваш SSD, вероятно, имеет некоторый тип встроенного кэша. Вы не упоминаете марку / модель используемого SSD, но это звучит как потребительский SSD по сравнению с моделью корпоративного или промышленного уровня .

В любом случае, кэш используется для объединения записей и продления срока службы диска. Если есть транзитные записи, внезапная потеря власти определенно является источником вашей коррупции. Настоящие корпоративные и промышленные твердотельные накопители имеют суперконденсаторы, которые поддерживают питание достаточно долго для перемещения данных из кэша в энергонезависимое хранилище, во многом аналогично кэш -памяти RAID-контроллера с резервным питанием от батареи и флэш-памяти .

Если на вашем диске нет суперкап, транзакции в полете теряются, что приводит к повреждению файловой системы. Возможно, ext3 говорят, что все находится в стабильном хранилище, но это только функция кеша.

— ewwhite
источник

Извините вас и всех, кто проголосовал за это, но вы просто неправы. Обработка потери выполняемых записей - это именно то, для чего предназначен журнал, и до тех пор, пока накопитель правильно сообщает, имеет ли он кэш записи, и подчиняется ли командам его очистки, журнал гарантирует, что метаданные не будут несовместимыми. Вам нужен только суперкап или рейдовый кэш с резервным питанием от батареи, чтобы вы могли включить кэш записи без необходимости использовать барьеры, что снижает производительность для поддержания правильности данных.

— psusi 5.12.12

@psusi Используемый SSD, вероятно, имеет явно включенный кэш или использует внутренний буфер независимо от настройки OS_level. Данные в этом кеше - это то, что защищает SSD с поддержкой суперконденсатора .

— 2012 года

Данные в кеше не нуждаются в защите, если вы включите IO барьеры. Большинство накопителей потребительского типа поставляются с отключенным кэшированием записи по умолчанию, и вы должны включить его, если хотите, именно потому, что это вызывает проблемы с повреждением, если ОС не соблюдает осторожность.

— psusi 5.12.12

@pusi Старый сейчас, но вы упомянули это:

as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.

вот в чем дело: из-за контроллеров хранилища, которые, как правило, предполагают использование старых дисков, твердотельные накопители иногда лгут о том, сбрасываются ли данные. Вам нужен этот суперкап.

— Джоэл Коэль,

Вы правы, а ваш коллега неправ. Если что-то пойдет не так, журнал гарантирует, что у вас никогда не будет противоречивых метаданных fs. Вы можете проверить с помощью, hdparmчтобы увидеть, включен ли кэш записи диска. Если это так, и вы не включили барьеры ввода / вывода (по умолчанию отключено в ext3, включено по умолчанию в ext4), то это будет причиной проблемы.

Барьеры необходимы для принудительного сброса кэша записи диска в нужное время для поддержания согласованности, но некоторые диски плохо себя ведут и либо сообщают, что их кэш записи отключен, либо нет, либо молча игнорируют команды очистки. Это мешает журналу выполнять свою работу.

— psusi
источник

-1 для чтения-понимания ...

— Ewwhite

@ewwhite, может быть, вам стоит попробовать прочитать и написать полезный ответ вместо этого детского оскорбления.

— psusi 5.12.12

+1 этот ответ, вероятно, можно улучшить, как и любой другой ответ в любом QA. Но, по крайней мере, дает немного света и подсказок. @ downvoters: улучшите ответ сами или прокомментируйте возможные потоки, но отрицание этого ответа без надлежащего обоснования просто отвратительно!

— Альберто