Недавно я испытал крах файловой системы. У меня сервер работал около 180 дней без перерыва без каких-либо проблем, но затем я заметил странные вещи, и, очевидно, файловая система ext3 была в очень плохом состоянии. Я проверил диски и память, и все было в порядке. В конечном итоге мне пришлось промыть систему и сделать полную переустановку. fsck.ext3 только ухудшало положение.
Я не хочу, чтобы это повторилось снова, поэтому на этот раз я выбрал XFS, который, как мне кажется, более зрелый, чем ext3, но я не понимаю, как контролировать состояние файловой системы. xfs_check просто не позволяет сканировать устройство, пока оно смонтировано.
Итак, как вы отслеживаете состояние файловой системы XFS, когда система находится в сети?
По правде говоря, вы мало что можете сделать для мониторинга работоспособности самой файловой системы. Эта ветка объясняет причины, по которым вы не можете выполнить проверку в стиле fsck для файловой системы, которая находится в оперативном режиме как чтение / запись.
Отчасти вы должны верить, что как журналирующая файловая система XFS делает все возможное, чтобы поддерживать ваши данные в хорошем состоянии. Вы также можете найти утешение, зная, что xfs_check намного быстрее, чем fsck.ext3 и XFS не предусматривает периодических проверок, как правило монтирования ext3 180 дней / x.
Редактировать комментарии:
Хотя я понимаю, что ты один раз укусил, два раза стеснялся. Могу заверить вас, что «полный сбой» не является систематической проблемой, связанной с файловыми системами UNIX. По моему опыту, такие события имеют тенденцию материализоваться только в связи с отказом оборудования, ошибкой пользователя (никакого неуважения) или неудачным сочетанием того и другого. Однако с технической точки зрения это довольно сложно объяснить без некоторых очень конкретных деталей того, что пошло не так с вашей предыдущей установкой ext3.
Поместите файловую систему на Логический том LVM, создайте временный снимок из логического тома, а затем fsck этот моментальный снимок (пока логический том все еще находится в сети).
Может быть Теодор Тсо e2croncheck скрипт для ext3 поможет вам начать работу.
(Как упоминалось в 3dinfluence: ZFS, безусловно, лучшее решение ...)
Я заметил странные вещи
Тогда проблема не в файловой системе (или, по крайней мере, это крайне маловероятно). ext3 - одна из наиболее часто используемых FS, и любая ошибка, достаточно серьезная, чтобы вызвать катастрофическое повреждение, должна быть уже обнаружена и исправлена.
Причина кроется в другом, возможно, в самом оборудовании (возможно, в оперативной памяти).
Чтобы ответить на ваш вопрос: вы можете проверить файловую систему XFS онлайн, но только если она смонтирована только для чтения.
Просто НЕ рекомендуется проверять целостность любой смонтированной файловой системы.
Краткий отказ от ответственности: мне нравится XFS и его скорость. Это не столько напыщенная речь, сколько предупреждение.
Немедленный ответ: нет, вам нужно будет размонтировать файловую систему для выполнения проверки. Запускать fsck на работающей файловой системе - плохо. Файловая система постоянно меняется в ходе такой проверки, а это означает, что вы никогда не можете быть уверены в том, постоянно ли она проверяется или, что еще хуже, если ваш «ремонт» не сделает ее хуже.
Пока это не непосредственный ответ ясен. Ext3, вероятно, лучший вариант для вас, и если вы столкнулись с повреждением в Ext3, вам нужно повторно проверить свое оборудование. Из любви к $ {DIETY}, вам не следует использовать XFS, если вы ищете что-то, что (потенциально) не потеряет данные во время восстановления. При определенных обстоятельствах он обнулит блоки данных во время восстановления.
Цитируется по 2-й ссылке:
5.1 Ошибки записи
Данные: мы видим, что ошибки данных в основном игнорируются или предпринимаются незначительные действия, кроме информирования пользователя об ошибке. В большинстве случаев потеря данных происходит незаметно, без ведома пользователя.
Имейте в виду, что XFS изначально разрабатывался с учетом работы с видео, поэтому, если у вас был поврежденный видеофайл, это не было проблемой, вы всегда могли вставить видео, чтобы исправить «плохое место»; Ожидание нескольких дней для fsck на 14-терабайтной файловой системе было большим делом, поэтому время проверки заменяется целостностью данных.
Повреждения файловой системы происходят независимо от того, какую файловую систему вы используете. За эти годы у меня были файловые системы Ext3 и XFS, которые меня угнетали.
ZFS, хотя и недоступна в Linux, за исключением использования FUSE, имеет оперативную фоновую очистку, которая может обнаруживать и исправлять ошибки до того, как вы столкнетесь с потерей данных. Он также выполняет много операций ECC для всех операций файловой системы и должен обнаруживать и сообщать о любых обнаруженных ошибках. Однако он должен быть в состоянии восстановиться и излечиться от большинства из них. Но даже со всеми уловками ECC, которые использует ZFS, были некоторые крайние случаи, обычно проблемы с оборудованием, когда файловая система ZFS была повреждена.
Лучше всего иметь хорошую стратегию резервного копирования и план аварийного восстановления. Восстановление данных из заведомо исправной резервной копии - самый быстрый способ справиться с подобными проблемами. Прохождение lost+found это болезненный процесс, подверженный ошибкам.