Обнаружена ошибка файловой системы synology

Copyright © 2023 Synology Inc. Все права защищены.

Пару недель как начала появляться ошибка:

«В разделе 1 обнаружена ошибка файловой системы»

SMART и состояние жестких дисков — в норме. Но ошибка не уходит, не помогает ни ребут наса, ни проверка. Обратил внимание на надпись (см. скрин) «Исправление ошибок данных файловой системы не поддерживается» файловая система EXT4.

Неужели это ограничения EXT4 и как Как можно исправить?

Диски собраны в RAID10.

На самосборном NAS-е установлена DSM 5.2-5967, загрузка через XPEnoboot_DS3615xs_5.2-5967.1.

В системе 8 дисков по 4 ТБ, RAID6.

Единственное применение этого НАС-а — ежедневные бэкапы с других серверов SYNOLOGY, больше на нем ничего не крутится, совсем.

В какой-то момент один диск отказал (Crashed), и том вошел в статус Degraded.

И тут же посыпались ошибки файловой системы

Появляется окно File System Check, перезагружаю систему, она довольно долго что-то делает, потом опять становится доступной, но почти сразу после загрузки опять появляется это окно.

И так продолжается уже довольно долго.

При этом все бэкапы кроме одного единственного продолжают нормально бэкапиться и добавляться (все бэкапы инкрементные).

И только с одним проблемы — при очередной попытке сделать бэкап выдается ошибка, а на этом сервере бэкапов снова вылезает окно об ошибках файловой системы.

Кто с таким сталкивался? Что делать?

Может быть есть возможность как-то руками запустить полную проверку файловой системы из командной строки, залогинившись под админом?

P.S.

Немаловажное уточнение: этот проблемный бэкап — это бэкап корпоративной почты.

Там есть папка с аттачами, в которой на данный момент находится более 250 тысяч файлов общим объемом 190 гигов.

Может быть дело в этой папке?

Но в то же время на другом аналогичном сервере она работает каждый день, и проблем с ней до сих пор (3*тьфу) не возникало.

P.P.S.

Примерно месяц назад такая же проблема была еще с одним бэкапом на этом же сервере, но тот бэкап был ничем не примечателен.

Дело кончилось тем, что пришлось грохнуть весь куст бэкапов за год (там было около 280 последовательных бэкапов), и начать все заново.

Но это же не выход?

Помогите пожалуйста решить проблему. Что-то непонятное творится

P.P.P.S.

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

Давать им серийник от реально работающего другого нашего настоящего сервера Synology я что-то постеснялся,

поэтому переписку пришлось прервать и сказать что бэкапы грохнули и работаем дальше

Что делать чтобы дисковая хранилка Synology приняла диски как родные и не ругалась (касается хранилок выше домашнего уровня, у домашних моделей нет такой проблемы (пока нет?) ).  

Написал 2 скобки и подумал, что по правилам русского языка 2 скобки не пишут, но в любой программе или скрипте несоответствие открывающих и закрывающих скобок вызывает ошибку. Что поделаешь, вот и профдеформация в деле. 

Как и все технические статьи в моем ЖЖ, писалось чисто для себя, чтобы не забыть. Через несколько лет бывает сложно вспомнить нюансы. Ну и вдруг кому-то поможет, поэтому добавил всякой билетристики. Если неинтересно читать всякие ненужные изыскания, промотайте в самый низ, 3 абзац с конца. Есть быстрое решение, хотя и неполное. 

Пост технический, но проблема не совсем техническая. Вобще, я нормально отношусь к маркетологам (нет, вру, гореть им в аду, самая паразитическая профессия современности), но тут они снова перегнули палку и победили технарей.  Synology хорошая компания (была?) и славится своими системами хранения домашнего и полупрофессионального уровня (SOHO), пользуется заслуженной популярностью за отличное соотношение цены-качества и за хороший софт в своих устройствах (камень в огород Qnap). Но примерно год назад они страх потеряли почувствовали в себе силы и шагнули в ранг профи. При этом вступили на скользкую дорожку, по которой идут многие крупные игроки, но там это привычно, клиенты платят в том числе и за надежность суммы в разы больше. Клиент платит за безотказность и надёжность и они дают эту надёжность по пятикратной или десятикратной цене с запретом всяких сторонних комплектующих.  Так вот, Synology решили тоже пойти по пути крупных вендоров и выпустили свою линейку дисков для своих дисковых хранилищ. На самом деле, это перешитые Тошибы, но суть не в этом. Поначалу они вообще решили запретить использование других дисков, чем вызвали негодование клиентов и, возможно, сильно потеряли продажи своих устройств, потому что довольно быстро пошли на попятную и полную блокировку сняли, но «чужие» диски устройства принимают неохотно и с «особенностями». Проблема касается не всех устройств, насколько я понял. Самые простые бытовые серии работают как и раньше. А теперь к сути вопроса. 

Купили мы себе в контору 2 хранилки от Синолоджи для организации из них кластера массива данных для дальнейшего использования в кластере виртуальных машин. Успели по старой цене по 270 тысяч за устройство, сейчас они стоят 500  (RS2412+). Плюс 4 SSD диска Kingston по 4Тб для организации рэйда (ещё 200тр). Итого почти лимон денег

Кратко затрону тему, что без интернета устройство в принципе нельзя запустить для начальной установки, интерфейс просто висит и чего-то ждет, а потом говорит что установить соединение с утройством не удалось. Даже если хотите поставить прошивку, скачанную вручную с сайта, а не обновиться через интернет, всё равно при отключенном интернете оно даже не дойдёт до кнопки обновления. Может и есть способ, но интуитивно не дошёл до него, просто дал прямой интернет (прокси она не понимает при начальной установке, что странно для Enterprise).  Это тоже в наше время сомнительная тема. Я вообще не верю в облака, когда ты теряешь контроль над собственным устройством и в любой момент его могут отключить, заблокировать или облако накроется медным тазом. Если и делать облако то своё собственное. Да, это всё красиво и здорово, когда Вы заходите на сайт и оно находит в вашей сети устройство прямо с сайта. И управлять с сайта устройством прикольно и ТП сможет удаленно помочь. Но всё это до поры до времени, пока они не решат Вас отключить. Вобщем, о надёжности такого решения Синолоджи для клиента говорить не приходится, ладно хоть потом оно работает без интернета.

В итоге, втыкаем диски, устанавливаем систему (сначала поставил DSM 7.1, потом откатывал, думая что проблема в ней, на DSM 6.2.4), собираем пул из дисков, создаём тома и видим следующую картину : 

идём куда посылают и там видим: 

(на скриншотах будут разные диски и разные версии DSM, отдельно поставил диск 240Гб чтобы можно было вытащить оба диска 4Тб и система работала, она ведь ставится на диски, которые в неё вставлены и если достать все диски сразу, система не запустится от слова совсем. Тоже сомнительное решение для enterprise системы, хотя лучше, чем дохнущие системные флешки у Qnap)

поначалу не придал значения этому сообщению, думаю, «что за непроверенные диски и как их проверить?», смотрю дальше: 

там есть ссылочка на сайт синолоджи, где написано что непроверенные диски надо просто заменить на проверенные, бинго!

вот тебе, бабушка, и Юрьев день! То есть буквально «покупайте наших слонов» (с) 

Нет, при этом система работает, (спасибо синолоджи за смягчение требований, в начале этой всей фигни год назад диски не виделись бы совсем) позволяет собрать диски в пул, сделать тома, но эта надпись висит всегда и если настроить оповещения о проблемах в почту, оно будет постоянно доставать этой ерундой, что нас не устраивает категорически. 

Начинаю гуглить и яндексить  проблему. Рунет вообще ничего не знает, или поиск не находит, на импортных форумах всё-таки нашел информацию, благодаря которой проблему решить удалось. Выражаю благодарность инженерам Синолоджи, которые (пока) не пошли на поводу у маркетологов и на закрыли доступ в систему, а также сделали понятный формат файлов. 

Так вот. У операционной системы DSM появился «список совместимых дисков», который можно загрузить с их сайта как в автоматическом режиме так и вручную, скачав файлик на диск. Если Вашего диска нет в списке, поздравляю, Вы пират Вы будете лицезреть красную надпись пока Синолоджи не включит его в этот список (или пока Вы сами это не сделаете).

Название файла примерно такое SynoOfflinePack-rs2421+-0023.sa

Найти файл можно тут https://www.synology.com/ru-ru/releaseNote/SynoOfflinePack?model=RS2421%2B

но мне кажется, они убрали возможность загружать его вручную, по-крайней мере в DSM 7.1.1 нет пункта в меню для его загрузки, видимо, он грузится теперь вместе с обновлениями ОС. На случай, если они и страничку эту уберут, сделал скриншот 

Казалось бы, всё просто, берем файл, добавляем в него нужные нам модели дисков и заливаем в систему. Но формат файла нечитаемый (может, кто сделает софт для расшифровки и добавления своих дисков, это было бы самым элегантным решением, хотя, сейчас смысл теряется).  В начале файла идёт открытый текст, из которого можно понять что это, но затем набор символов (возможно, какое-то шифрование). Начало файла (со 2 по 6 строку) примерно выглядит так: 

version="0023"
maintainer="Synology Inc."
model="rs2421+"
description="The Synology offline offline pack for offline use to upgrade their database or firmwares"
displayname="Synology Offline Pack"

если кому интересно, на сайте Синолоджи есть список совместимых дисков: 

https://www.synology.com/ru-ru/compatibility?search_by=products&model=RS2421%2B&category=hdds_no_ssd_trim&p=1&change_log_p=1

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

На наше счастье, этот файл при заливке в систему там превращается во вполне читаемые файлы, чем мы и воспользуемся. 

Итак: добавление несовместимого диска в Synology RS2421+ (и другие модели)

Внимание! Это вмешательство в ОС устройства и может привести к поломке, «окирпичиванию» и лишению гарантии, поэтому никаких претензий, делаем на свой страх и риск, я предупредил, что делать это нельзя!

Если слова SSH, Telnet, root, vi Вам ничего не говорят, даже не пытайтесь!

Делалось на версии DSM 6.2.2, на 7.0.1 и на 7.1.1

Отдельно про даунгрейд с 7.1 до 6.2.4 (думал что проблема появилась в 7-ке, но нет, она появилась в 6.2.4, так что если найдёте более старую прошивку, возможно это также решит проблему). В сети много инструкций про редактирование файла VERSION через SSH но не везде сказано,  что после первой попытки обновить вручную на 6.2 выйдет ошибка и надо без перезагрузки подключиться через telnet (логин root пароль 101-0101) и внести изменения ещё раз 

сдержимое файла /etc.defaults/VERSION

majorversion="6"
minorversion="2"
productversion="6.2.3"
buildphase="GM"
buildnumber="25426"
smallfixnumber="0"
builddate="2020/07/01"
buildtime="06:24:39"

версия, котрую прописываем в файл может быть любой из ветки 6-х, главное чтобы она была не выше прошиваемой 

тут подробнее:

https://www.synology-forum.ru/index.php?/topic/19460-%D0%BE%D1%82%D0%BA%D0%B0%D1%82-%D1%81-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8-711-42962-%D0%BD%D0%B0-617-15284/

но вернёмся к нашим баранам:

1. Включаем SSH и Telnet в веб-интерфейсе DSM в настройках сети (кстати, если забыть включить Telnet при даунгрейде, ничего страшного не случится, пре перешивке он сам активируется, проверено на себе)

2. Подключаемся через putty (если у вас Windows, если Linux, то Вы и так знаете как подключиться по SSH)  логин и пароль те же, что у админа в веб-интерфейсе

3. Ищем файл своего устройства (рекомендую воспользоваться WinSCP, если у вас Windows) в каталоге /var/lib/disk-compatibility

в нашем случае это файл rs2421+_host.db , там много похожих файлов, в названии которых фигурирует название вашего устройства. Файлы идут по 3 штуки с одинаковым именем и разными расширениями *.db  *.version  и *.release, также есть файлы *_V7.db — для 7 версии DSM, также для семерки есть файлы  *_V7.db.new  и многие источники стоветуют его модифицировать также как и без new, но я этого не делал, работает и так. Больше похоже что это файл обновления, а использует система как раз первый вариант.

Файл *.release содержит дату добавления в формате 20210307 ; файл *.version версию — четырехзначный номер. Возможно, чтобы не влезать в файлы host, можно добавить отдельные файлы для своих дисков, там таких уже есть несколько, но у меня не получилось. То ли права не те, то ли система знает какие файлы брать какие нет.

Также немного посмотрел другие интересности файловой системы: есть файлик diskaction.xml в папке diskaction, там включаются опции для конкретной модели диска, пока не разбирался, но кто хочет может поковырять, максимум что может случиться, убьёте свой диск  

формат строки (одна строка для примера):  

	<disk model="ST1(0|2|4)000NM0(048|038|528)" eunit="RX1217sas">HIBERNATION_OFF</disk>

можно видеть, что поддерживаются регулярные выражения, а также  можно отключить или включить конкретную опцию для конкретной модели диска и для конкретной хранилки, вобщем, есть информация для изучения. Как я понял, этот файл не связан с проблемой непроверенных дисков и работает отдельно. По названиям опций можно понять их смысл, например: HIBERNATION_OFF; NCQ_ADJUST; DSLEEP_OFF; NCQ_OFF; WCACHE_OFF;  TRIM_OFF и т.п. Причём, там явно полно дисков, которые являются «непроверенными», так что это отдельные инструменты. 

Ещё файл с настройками drive_attribute.db в папке drive_attribute, судя по параметрам, это настройка атрибутов SMART. Но там только свои синолодживские диски. Можно попробовать добавить свой диск, чтобы смарт показывал больше параметров. 

Вот пример конфига по одной модели диска. По названию нашёл, что это синолоджиевский SSD диск на 3.8Tb, почти как мои Кингстоны, только по цене в 3 раза больше. Кому интересно, можно разобрать что к чему: 

"SAT5210-3840G":{"bundle_reserve_1":6000,"bad_block_cnt_thr":285,"bundle_smart_attrs":{"power_on_hour":{"id":9,"mask":"0xffffffffffff","shift":0},"avg_erase_count":{"id":164,"mask":"0xffffffffffff","shift":0},"later_bad_block_count":{"id":196,"mask":"0xffffffffffff","shift":0}},"is_bundle":1},

Для начала нам надо узнать модели наших дисков и версии прошивок.

смотрим имена дисковых устройств

fdisk -i 

находим среди служебных дисков свои (по размеру) и смотрим подробную информацию по именам, например:

smartctl -i /dev/sata1

нас интересует строчка Product и строчка Revision

Но! В строчке Revision у меня почему-то обрезает номер до последних 4 символов, тогда идем вторым путём и смотрим в веб-интерфейсе DSM

Да, можно вообще не лезть так глубоко и посмотреть сразу в диспетчере DSM в списке дисков — там будет модель и версия прошивки (версию прошивки можно не добавлять. Лучше не добавить, чем добавить неправильную, должно работать и без неё, вместо версии прошивки пишем default, но я не проверял)

У меня было 2 модели дисков для добавления: 

Kingston 4Тб (марка не фигурирует в файле, только модель и версия прошивки) Product: SEDC500M3840G Rev: SKECJ2.8

и Kingston 240Gb (служебный) Product: SA400S37240G Rev: S3E00100

Сначала редактируем файл rs2421+_host.db. Изначально файл для версии 6, но для 7-ки в него тоже нужно добавить описанные изменения, (или не надо, но это не точно, в любом случае, если у вас прошивка 6 версии то обязательно) редактируем сразу 2 файла. Начало имени файла соответствует модели устройства, если у вас другое утройство, находим свой файл.

Содержимое файла начинается с записи {«success»:1,»list»:[ заканчивается  «nas_model»:»rs2421+»} (или модель вашего устройства) 

добавляем свои записи между записями от других устройств, можно вместо какого-то ненужного. Файл идёт в одну строку, переводов строк нет, разделение записей фигурными скобками и запятыми, в моём случае я добавил:

{"model":"SEDC500M3840G","firmware":"SKECJ2.8","rec_intvl”:[1]},{"model":"SA400S37240G","firmware":"S3E0010","rec_intvl”:[1]},

это необходимые опции чтобы диск считался проверенным, подставляем свои данные, следим за запятыми между записями. 

Там в формате записи к другим дискам есть ещё опции, например название файла прошивки. Возможно, DSM умеет принудительно перешивать диски. Вот для примера часть строки из этого файла «fw_buildnumber»:1,»firm_bin»:»MG08_SATA_1401.ftd»

У файлов для 7 версии свой синтаксис, (добавлять нужно в оба файла!) В файл rs2421+_host_V7.db добавил:

"SEDC500M3840G":{"SKECJ2.8":{"compatibility_interval":[{"compatibility":"support"}]},"default":{"compatibility_interval":[{"compatibility":"support"}]}},"SA400S37240G":{"S3E00100":{"compatibility_interval":[{"compatibility":"support"}]},"default":{"compatibility_interval":[{"compatibility":"support"}]}},

не забываем запятые между устройствами

можно просто добавить как тут, заменив своими модель диска и версию и дальше не читать  

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

Начало содержимого файла:   {«disk_compatbility_info»: {

заканчивается записью   ,»nas_model»:»rs2421+»} (или модель вашего устройства) 

формат записей тут интереснее: 

сначала модель в кавычках, потом версия прошивки, опции одна внутри другой и внутри их остальные опции. Между названием параметра и значением двоеточие. Сложно обьяснить словами, вот форма на примере одного диска (какой-то Western Digital): 

{«WD4003FFBX»:{«default»:{«compatibility_interval»:[{«compatibility»:»support»,

дальше через запятую идут опции и в конце закрывающие скобки и в конце разделяющая запятая ]}},

Вместо номера прошивки можно указать default как в примере выше, то есть достаточно только модели. Вторая запись default в строчке, которую я записал в свой конфиг появляется при явном указании версии прошивки в начале и относится к другой версии прошивки, то есть можно сделать чтобы с определенной версией прошивки, которая указана явно в начале был один конфиг, а с остальными (default или явно указанными) другой, например там задается номер прошивки, которую надо прошить. В результате может быть несколько конфигов для одного устройства с разными прошивками. default обозначает любую версию прошивки. Вообще, там по скобочкам можно понять что к чему относится, программисты поймут быстро. 

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

Между версией прошивки и compability_interval может попадаться версия прошивки, видимо, для дисков, которые DSM может самостоятельно прошивать при обновлении, пример:

«SAT5200-480G»:{«SCEMJ2.1»:{«fw_buildnumber»:1,»firm_bin»:»SCEMJ2.1.bin»,»compatibility_interval»:

Опции, которые внутри конструкции compability_interval :

«not_yet_rolling_status»:»support» 

это, видимо, статус раскрутки диска, для SSD не акуально

«fw_dsm_update_status_notify»:false  

похоже что это оповещение о прошивке диска, замечена включенной, там где указан файл для перешивки диска для родных дисков Синолоджи

«barebone_installable»:true

это, видимо, возможность установки на горячую, хотя, все диски сейчас это поддерживают, не очень понятно при чем тут barebone

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

Редактировать наши файлы можно напрямую в vi или vim, но я, как человек, избалованный mc, а ставить его на хранилку так себе идея, копировал файлы себе, редактировал на компе и заливал обратно с помощью WinSCP. Маленький lifehack: обратно скопировать прямо не даст из-за отсутствия прав, копируем в папку в каталоге tmp (например, папка 1), а оттуда уже в ssh сессии копируем на место:  sudo cp /tmp/1/*.* /var/lib/disk-compatibility/ 

После того, как отредактирвали файлы, перезагружаем устройство и радуемся. 

Кстати, в нижней ссылке в конце чел пишет, что можно не перезагружать устройство, а перечитать конфигурацию командой, но я не проверял: 

/usr/syno/sbin/synostgdisk —check-all-disks-compatibility 

А вообще, есть способ проще, просто редактируем файл /etc.defaults/synoinfo.conf 

и в строчке support_disk_compatibility=»yes»  меняем yes на no и всё    

После этого надо перезагрузить устройство. Но это прокатывает не на всех моделях устройств!

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

И, кроме того, после изменения в файле synoinfo.conf если мы не редактирвали файлы совместимых дисков, ругаться DSM все равно будет в диспетчере хранения, правда только в одном месте, на вкладке «обзор»

Кроме этого, вылезают такие нехорошие сообщения в оповещениях:

Поэтому, я предпочел добавить модели дисков в файлы, но и опцию оставил. 

Кстати, при даунгрейде системы, надо диски отдельно чистить, иначе получаем такое сообщение:

При обновлении с 6.2.4 на 7.0.1 настройки не слетают (возможно, потому что я делал откат версии и у меня уже были файлы для 7 версии, которые при обновлении не перезаписались), но лучше убедиться.

При обновлении с 7.0.1 на 7.1 настройки слетают, там вообще больше изменений в системных файлах, по сравнению с переходом с 6.2.4 на 7.0.1. Например, файл synoinfo.conf сильно изменился. Но все описанные манипуляции и опция support_disk_compatibility=»no» работют, их надо просто прописать заново. И лучше добавить диски в файлы как было описано. Для кого это проблема, эта статья может уместиться в одну строчку:

Заходим на устройство по SSH и меняем в файле /etc.defaults/synoinfo.conf значение параметра «support_disk_compatibility» на «no»      

Чтобы снова не заниматься этими манипуляциями, отключите автоматические обновления, иначе после каждого обновления параметры могут слететь. Можно сохранить свои файлики на компе и после обновления менять свежие на них, всё равно там ничего интересного не прилетит  

Благодарность товарищам с форума www.synology-forum.ru и иностранным коллегам с форумов по нижеприведенным ссылкам: 

Welk 14.10.23  (с) можете копировать, только ссылку сюда оставьте 

Я купил футляр Interstellar Snail C во время катастрофы на шахте, два красных диска для хранения данных. Я не ожидал, что качество красных дисков будет таким низким. С начала прошлого года до настоящего времени ошибки UNC появлялись периодически. На этой неделе произошел сбой. Запишите процесс восстановления:

Система Synology использует внутреннее управление программным рейдом. После того, как новый жесткий диск вставлен и инициализирован, он обычно будет отформатирован на 3 раздела. Как правило, первые два связаны с системой, а последний используется как диск для хранения. На рисунке ниже показан мой плохой сектор. Ситуация с разделами жесткого диска

Обратите внимание на то, какой тип является типом рейда, в настоящее время его нельзя использовать напрямую.
Когда в системе несколько жестких дисков, каждый жесткий диск является таким разделом. Вместе первый раздел каждого жесткого диска образует массив режима raid1 (данные хранятся в нескольких местах) В этом случае на каждом жестком диске есть резервная копия системных файлов. Это также причина, по которой система все еще работает нормально, когда жесткий диск отключен от машины Synology. См. Рисунок ниже:

После того, как массив мягких дисков составлен, массив дисков в это время эквивалентен жесткому диску, и его необходимо разбить на разделы.
Система Synology использует раздел управления lvm, сначала отделяет группу томов, а затем добавляет том в группу томов. Фактически, при управлении пространством хранения через веб-интерфейс пул хранения соответствует группе томов , Объем памяти соответствует тому. На моей машине есть два жестких диска и создано две группы томов. В каждой группе томов по несколько томов. Я использовал команду lvm, чтобы перечислить группы томов и тома следующим образом:

При создании тома будет указан формат файла.Теперь Synology рекомендует файловую систему btrfs. Обычно возникают ошибки файловой системы, для этого необходимо проверить /var/log/disk.log и scemd.log. То, с чем я столкнулся, было более сложным.
Сначала восстановите файловую систему btrfs, используя команду:

btrfs-find-root /dev/vg1/volume_1 &> /tmp/test.txt

Обратите внимание, что путь к тому в этой файловой системе варьируется от человека к человеку. Моя плохая область диска — volume_1 / volume_2 / volume_3 в группе томов vg1, поэтому это именно этот путь. Эта команда используется для поиска проблемного блока.
обычно встречается так

Выберите первый, чтобы начать восстановление:

btrfs check --repair -r 117784576 -s 0/1/2

Необходимо обратить внимание на — после добавления восстановления, это рискованно. Восстановление может завершиться неудачно и файловая система будет беспорядочной. Поэтому перед восстановлением необходимо сделать резервную копию жесткого диска. Выберите один после -s и замените его после сбоя. Как правило, после выполнения этого Noabort / failed — успешно
Если вы столкнулись с ошибкой с ключевым словом «RDWR» во время выполнения, вам необходимо выполнить команду очистки кеша.

btrfs check --clear-space-cache v2

После непрерывного восстановления всех блоков файловая система btrfs, как правило, завершена. Удачи на данный момент, общее пространство для хранения доступно после перезапуска dsm, а режим только для чтения восстанавливается до режима чтения-записи.

Не повезло, процесс восстановления файловой системы мог повлиять на формат soft raid. Вам нужно проверить журнал. К сожалению, я столкнулся с этим. Посмотрев на файл scemd.log, я обнаружил ключевое слово / dev / md2 RAID crash, поэтому я перестроил raid-формат третьего раздела моего жесткого диска / dev / sdc3. Конкретные приемы:
1. Отключите неисправный диск.
2. Перезагрузите компьютер.
3. Горячее подключение поврежденного диска
4. Запустите команду:

mdadm -Cf -e1.2 /dev/md2 -n1 -l1 /dev/sdc3

После завершения реконструкции вы можете сделать проверку, -e — это версия, 1.2 и 0.9 можете попробовать сами

mdadm -D /dev/md2

Пространство для хранения больше не регистрируется как поврежденное после перезапуска компьютера. Однако процесс восстановления по-прежнему повлиял на систему. DSM предлагает восстановить систему. Процесс восстановления — это процесс синхронизации RAID. Как показано на рисунке ниже, вы можете видеть, что мой неисправный диск является жестким диском sdc, а данные sde1 в md0 синхронизируются с sdc1.

Сводка:
Linux от Synology более чувствителен к поврежденным секторам жесткого диска, поскольку файловая система является журнальной, она может вовремя обнаруживать поврежденные сектора жесткого диска. Если есть сообщение о повреждении, необходимо вовремя создать резервную копию данных и заменить жесткий диск. . Данные бесценны