ZenWay - Linux сегодня!
  • Главная
  • Форум
  • Контакты
  • Архив
  • Гостевая книга
×
Поиск по сайту
ГлавнаяHужное/полезноеАдминистрированиеИзучаем LinuxДополнительные материалыЖурналируемые файловые системы

Журналируемые файловые системы

Дополнительные материалы, Изучаем Linux, Администрирование, Hужное/полезноеПросмотров: 3814Комментарии: 213 марта 2009 г.
HDD / Администрирование / Комплект инструментов / Учебные материалы
Понятие «журналируемые файловые системы» окружено множеством мифов и легенд, упоминается очень часто, при этом лишь немногие до конца осознают что это такое, что от них ждать, хорошего и не очень...

Что и зачем?

При обычной работе файловой системы все изменения обычно сразу производятся с диском (вернее с кэшем диска в ОС, но это в данном контексте не важно). Но многие операции требует одновременного изменения сразу нескольких структур файловой системы (метаданных), простой пример: при создании hardlink'а нужно одновременно увеличить количество ссылок на inode и изменить содержимое каталога, в который делается ссылка. Нельзя сделать лишь одну из этих операций — содержимое файловой системы будет некорректным.

При обычной работе файловой системы подобная комплексная операция всегда выполняется целиком, если код реализации файловой системы не содержит критических ошибок. Однако при нештатной перезагрузке или аппаратном сбое эта ситуация вполне реальна. Так как после перезагрузки мы не знаем какие операции производились, что было не закончено, а знаем только о том, что диск не был корректно размонтирован (при этом сбрасывается так называемый dirty flag), то нам необходимо проанализировать файловую систему на всём диске, и, таким образом, выявить все ошибки в файловой системе и их исправить. Естественно далеко не всегда это возможно выполнить автоматически (неестественный интеллект, увы, способностям к ясновидению пока обучить никому не удалось), посему та же fsck.ext2 после нештатной перезагрузки может потребовать и ручного вмешательства.

Те кто запускал fsck на разделе в 500Гб–1Тб прекрасно понимают, что удовольствия в этом мало, администраторы же многотерабайтовых массивов, за лишнюю минуту простоя коих им могут «случайно» голову оторвать при слове “fsck” хватаются за валерьянку или просят не ругаться такими словами в их присутствии. Для решения этой проблемы давным-давно была придумана гениальная идея (если кто знает когда и кем — скажите мне, пожалуйста) — сначала записать некое описание планируемой операции на диск, а уж потом её выполнять. Тогда можно будет не тестировать весь диск на корректность, а всего лишь ограничиться просмотром содержимого журнала, и, если операция не была завершена, то откатить её. Для этого не нужно запускать fsck — это делает сам драйвер файловой системы.

Подводя итог... Единственное что может и должна делать журналируемая файловая система, это экономить время на fsck. Соответственно гарантируется непротиворечивость метаданных файловой системы, не больше, не меньше. Цена этого удовольствия, образуется небольшая (обычно измеряемая десятками мегабайт) область диска, на которую приходится максимальная нагрузка, то есть максимальное производительность, измеряемая в количестве i/o операций в секунду, падает и естественно расходуется немного дискового пространства, что в эпоху цен на диски никого уже не волнует.

В журнал обычно пишутся операции с метаданными, однако можно то же самое делать и с данными. Разумеется журналирование данных во многих случаях несколько уменьшает производительность (но далеко не всех, на сайте IBM есть результаты тестов, по которым использование журналирования данных для файловых систем, на которых находятся базы данных, может дать даже прирост производительности). Это средство тоже не гарантирует сохранность данных, однако из моего личного опыта использование ext3 с data=journal является самой надёжной файловой системой. Использование журнала это создание неравномерной нагрузки на диск, на одну маленькую (по сравнению с общим размером файловой системы) область приходится несоразмеримой объём операций.

Есть два очень интересных решения:

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

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

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

- Отложенное создание файла, в момент создания файла не создавать сразу запись в каталоге, а некоторое время держать её только в журнале, возможно файл временный и будет сразу удалён;

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

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

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

— Как же, можно ведь резетом машину перезагружать, она даже и не матюгнётся при загрузке!

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

Скажем reiserfs в подобных ситуациях вполне может оставлять в модифицируемых файлах мусор (произвольные данные которые были в выделенном под файл блоке). Что, по сути, означает вполне вероятную случайную утечку информации. XFS поступает более корректно — она такие блоки прописывает нулями. Что часто шокирует пользователей. Особенно фанатов reiserfs, которая не станет прописывать нулями. В результате reiserfs скорее сохранит модификации, а XFS всеми силами избежит мусора в файлах и утечки данных — просто чуть разные стратегии. Результат один — данные могут быть утеряны, и вы даже об этом не узнаете. Пока не столкнётесь с файлом, который уже год никто не трогал (в архиве лежал), и который вдруг оказался забитым мусором или нулями.

ext3/ext4 с включенным журналированием данных такими особенностями не страдает. Однако заметно проигрывает в производительности. По-хорошему всех этих проблем можно (и нужно) избежать просто покупкой источника бесперебойного питания (UPS / Uninterruptible Power Supply), а журналирование лучше использовать как дополнительный уровень надёжности и средство увеличения производительности.

Журналируемая файловая система всего лишь немного облегчает администрирование, однако не является волшебным средством от потери данных при нештатных перезагрузках. Поэтому если вы не пользуетесь UPS (источник бесперебойного питания) и не делаете резервные копии - Backup, то ваши данные рано или поздно накроются медным тазом...

Автор: posixru
Еще записи по теме
Dstat
Dstat
DDCcontrol
DDCcontrol
thinkfan
thinkfan
deborphan
deborphan
GADMIN SQUID
GADMIN SQUID
extundelete
extundelete

Комментариев: 2 RSS

1Иван26-07-2016 19:58

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

2Иван26-07-2016 20:01

Впрочем "ленивое выделение дискового пространства" за счёт фейкового журнала в ОЗУ может и улучшит показатели.

Оставьте комментарий!

Используйте нормальные имена.

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)

Рубрики
  • Hовости
  • Изучаем Linux
  • Обзоры Linux ПО
    • Hужное/полезное
    • Аудио и видео ПО
    • Графика
    • Офисное ПО
    • Интернет ПО
    • Образовательные
    • Игры
    • Администрирование
    • Системные утилиты
    • Прочие
    • Shareware / Demo
  • Дистрибутивы
  • Дополнительные материалы
Последние комментарии
Profanity
  • zon » проше научится свой клиент написать чем разобратся куда что клацать для отправки получения месаг.
  • vovans » Тут не нужно ничего "клацать". Достаточно пару раз на хоткеи посмотреть.
noteshrink
  • Аноним » Теперь есть плюсовая (не пайтон) версия: //github. com/ ImageProcessing - ElectronicPublications /noteshrink-c/ releases
Page dewarp
  • Аноним » Теперь есть плюсовая (не пайтон) версия: //github. com/ ImageProcessing - ElectronicPublications /pagedewarp/ releases
Strawberry Music Player
  • Rododendron » А как добавить радиостанции в плеер? Нигде найти не могу.
Runtu LITE
  • Бубликус » Прикольно.
Полифон (Polyphone)
  • Игорь » Возможно ли ознакомиться с Руководством по обращению с Polyphone на русском языке ?
NEdit (Nirvana Editor)
  • uxer » Nedit не поддерживает кириллицу и вообще юникод.У меня вместо буков азбуки отображает вот такое:здар ова, а...
DeaDBeeF
  • algri14 » Есть ещё плеер mpz — mpz-player.org , там же ссылка на подключение репо автора.
iMule (невидимый Mule)
  • Сергей » Мусьё не читатель, мусьё писатель? Написано же:I2P маршрутизатор должен быть установленВот его и ставим, запускаем...
Форум
[18/11/2022 11:54:52]
vscode and c/c++
[31/08/2022 12:25:53]
Tor Browser
[26/08/2022 07:57:14]
Музыкальный калейдоскоп
[22/05/2022 15:45:40]
Стратегии RTS
[30/03/2022 09:05:20]
Заметки с синхронизацией
[01/03/2022 20:15:05]
Говорильня (дискуссионный клуб)
[13/02/2022 11:44:28]
[РЕШЕНО] права на запись в примонтированный образ диска (raw.img)
[07/02/2022 13:22:01]
Конвертировать текст набаранный в неправильной раскладке
[04/02/2022 20:35:22]
Редактор тегов
Облако меток
2D338 3D241 ALSA68 ASCII120 Android1 Arch Linux38 Audio416 Backup80 Benchmark78 Bluetooth2 C++969 CD48 Console1318 DJ-система17 DVD47 Debian28 DjVu22 Enlightenment19 FFmpeg191 FLTK29 FPS40 FREE155 FTP18 FVWM21 Fluxbox40 GIMP24 GNU26 GPS22 GTK1302 GUI801 Gambas11 Games686 Gentoo3 Gnome349 Gstreamer133 HDD122 HDR7 HTML62 Hex-редактор14 ICQ17 IP-сети25 IP-телефон22 IRC31 ISO39 IceWM22 ImageMagick56 JACK99 Jabber35 Java308 JavaScript115 KDE209 LAN29 LXDE37 LaTeX66 Live-CD70 Live-DVD55 Live-USB53 Lua61 MATE32 MEncoder31 MIDI91 MMORPG12 Mail42 Markdown53 Mono53 Mplayer75 MySQL2 OSS9 Open Source14 OpenGL301 Openbox89 P2P51 PDF133 PHP12 Pascal17 Perl102 Phonon27 PulseAudio17 Python759 QT894 RAW34 RPG101 RSS53 RTS42 Roguelike70 Ruby19 Rust15 SDL312 SVG39 Screencast32 Screenshot61 Script78 Slackware66 TOR17 TOX3 Tk39 Torrent67 Ubuntu69 VLC16 Vala64 Web629 WebKit72 WebUI34 WiFi47 Window Maker16 Wine8 XMPP35 Xfce70 Xine14 YouTube80 video4linux27 wxWidgets108 Автоматизация31 Администрирование335 Анонимная сеть47 Антивирус14 Апплет120 Аркада235 Архиватор11 Астрономия36 Аудио конвертер70 Аудио редактор50 Аудиоплеер184 Безопасность243 Бизнес-приложение4 Браузер87 Бродилка203 Бухгалтерия11 Веб-камера36 Видео148
© Zen Way, 2023. Работает на MaxSite CMS | Время: 0.1230 | SQL: 15 | Память: 8.75MB | Вход