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