Интересные истории с устройством QNAP продолжаются.
Немного лирики. На вопрос "почему же я продолжаю пользоваться этим устройством, если оно вобщем-то проблемное?" я отвечу довольно просто: оно тихое и оно компактное. Да, да - звучит банально :) Да, я знаю, что в природе есть различные аналогичные устройства, напр. hp microserver, которые лучше, быстрее и мощнее, но есть и другой фактор - все они стОят денег, а с тех пор как я женился, у меня особо денег не прибавилось :( да и жена имеет повышенные требования к тишине и как ни странно к габаритам аппарата, особливо, к высоте.
Итак, к делу. Один раз я уже нарывался на проблемы с фс похожего характера: "задвоение" файлов. Решается это на конкретном устройстве (Qnap) отключением опции фс dir_index. Благо, на момент повреждения индекса ничего особо важного свежезаписано не было, а то что задвоилось было благополучно скопировано.
Отключается опция довольно просто.
<Процедура отключения>
Конечно, после этого пиоск в каталогах с десятком-другим тысяч файлов будет не таким быстрым, но это не столько принципиально...
Время идёт и вот внезапно фс отказывается сохранять временные файлы. Да, торрент-качалка в этот момент была включена и это создавало определённую нагрузку на vfs, ext4fs, raid5... Оказывается, ядро 2ю6ю33ю3 в этом девайсе не такое идеальное, как хотелось бы и как результат в dmesg я увидел:
[2930403.320000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363986999
[2930403.530000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363986998
[2930403.550000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363987000
[2930403.580000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363986982
[2930403.580000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363986952
[2930403.580000] EXT4-fs error (device md0): ext4_free_inode: bit already cleared for inode 363986951Ну, что же - придётся засучить рукава.
Историческая справка и немного лирики: ext4 стабилизировалась в версии ядра 2.6.28, как подсказывает википедия, насколько я помню, проблемы разного рода преследавали эту фс чуть ли не до 2.6.36 -й версии ядра и это на x86, что касается архитектуры arm, то даже на сегодняшний день, когда arm и armv8 (aarm32 и aarm64) являются основными архитектурами, на которые рассчитано ядро linux (это помимо x86 и x86_64) то даже сегодня, на кануне выхода ядра 3.18 мы имеем ряд ощутимых проблем и набор заметных недоработок на этих самых архитектурах ARM (много вендоров, сегментированность рынка, склонность к проприетарности вендоров/защита от патентных троллей майкрософта) Конечно, на сегодняшний день углы более сгажены, чем на момент выхода qnap-овского хранилища, но тем не менее...
Поддерживает всё это напосредственно компания Marvell, на платформе которой и изготовлено устройство. Надо заметить, что если с ними плотно сотрудничать, то они довольно отзывчивые ребята... сразу после пробивания бюрократических рубежей обороны, конечно же. Собственно, Marvell для этой платформы уже выпустил линейку ядер версии 3.x (плотно я с Marvell не работаю уже более 10 месяцев, однако на момент последнего контакта это было ядро 3.2 с кучей патчей "домашнего" производства, кстати NDA required, что странно).
Компания Qnap выпустила для своих устройств обновление фирмвари 4-го поколения, а там внутри ядро 3.4.6 (если не ошибаюсь) с кучей патчей, на сентябрь 2014-го эта прошивка от нагрузки на samba-сервер могла самопроизвольно уйти в ребут. Какбэ после этого возникают вопросы к QA-команде компании Qnap... Такая же история была и с прошивками 3-й версии, соответственно 3.8.3 - это последняя более-менее стабильная из 3-го поколения.
Итак, в виду того, что ядро древнее, ext4 для него новая фс, возникла мысль конвертировать фс в "традиционную" ext3. Официально эта операция какбы невозможна, однако, если присмотреться, то единственная фича, которая нас от этого удерживает - это extents. Всё что нам интересно - extents имеют непосредственное отношение к расположению данных в разделе на диске, к формату данных. Если от них избавиться (напр. копированием данных на фс, смонтированную без поддержки записи с использованием extents), то файлуху можно будет смонтировать (предварительно убрав остальные присущие ext4 артефакты) как ext3, с использованием модуля ядра ext3.
Пока в интернетах я нашёл вот такую статью:
http://keepout.cn/ru/%D0%98%D0%A2/Linux/ext2-ext3-ext4
План таков - сделать из имеющейся файловой системы ext3 без журнала, создать журнал, заставить систему смонтировать фс как ext3.