LINUX.ORG.RU

Процесс записи файла в Linux и полное журналирование ФС

 ,


0

2

Привет!

Заморочился я тут с журналированием и не могу понять, нужно ли мне data=journal в /etc/fstab для EXT4 или нет. По умолчанию журналирование установлено в data=ordered, где менеджер журнала заносит метаданные файла в журнал, но данные файла пишутся напрямую на диск.

Так вот, хочу понять как происходит запись файла в Linux. Если, доупустим, приложение открыло файл размером 100Mb (допустим некий фотошоп 😄), далее было сделано пару мазков по фотке и нажат был save. Что дальше произойдёт?

  1. Ядро как-то поймёт, что из 10000 блоков этого файла изменились только 1000, ядро «пометит» их как удаленные, а 9000 останутся на месте, затем допишет новые 1000 блоков (мазок в фотошопе) и занесёт новую последовательность блоков в метаинформацию файла?

  2. Ядро оставит на месте все 10000 блоков этого файла, начнёт писать измененные данные всего файла (10000 блоков) в новое место в файловой системе, дописав до конца файл, он удалит старый файл, а новый переименует в старый файл. Если в процессе записи вырубили рубильник, новый файл не дописался, перешёл в состояние corrupted, то он просто стирается с диска (при проверке целостности ФС), старый файл остаётся целостным на диске, теряем только изменения после последнего сохранения.

Если процесс происходит по второму варианту, то в чём заключается смысл data=journal? Достаточно ли режима data=ordered для /home? Насколько это безопасно в плане целостности файлов? Не хочется потерять весь файл, но согласен на утерю изменений после последнего успешного сохранения.



Последнее исправление: dva20 (всего исправлений: 5)

Твое любопытство похвально, но не могу не отметить, что большинство вопросов ему ортогонально.

для /home

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

Не хочется потерять весь файл

Не хочешь потерять файл — забэкапь его. Опции ФС тут вообще не при чем.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

Недавно потерял на NTFS (под виндой) много своих фоточек. Заметил это не сразу, более того, загружался в дуал буте под Manjaro’ой и использовал rsync, который использовался без проверки на хеш содержимого файла и сверялись только метаданные. Вообщем и бекап фоточек на другом диске захерачил :) На винде я так понимаю тоже, аналогичный режим ordered на NTFS был включен скорее всего.

Поэтому, «Ничего не трогай (с)» не годится. Надо разобраться чтобы минимизировать потери. Но моя ситуация усугубляется еще и тем, что планирую заменить системный диск с HDD на SSD и полное журналирование скорее всего будет избыточным, поэтому и появился вопрос - как записываются файлы, большие и маленькие на «физическом уровне».

dva20
() автор топика
Последнее исправление: dva20 (всего исправлений: 1)

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

  1. В C нет удобного гипотетического finsert(). За исключением специализированных программ, вроде баз данных, вряд ли кто-то заморачивается с fseek(). Либо fwrite() добавляют в конец, либо перезаписывают весь файл целиком с новыми данными. Так что в журнал в большинстве случаев упадёт файл целиком.
  2. Не в новое. В случае с ext4 станет перезаписывать уже выделенные блоки. Механика «скопировать и подменить» называется copy-on-write. В Linux есть пока только в btrfs.

data=journal это в некотором виде прародитель CoW.

aidaho ★★★★★
()
Ответ на: комментарий от aidaho

copy-on-write

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

А btrfs безопасно сейчас использовать (для хомяка)? Как она себя ведёт в реальных условиях, на боевых серверах? Или это всё еще эксперементальная ФС?

dva20
() автор топика
Последнее исправление: dva20 (всего исправлений: 1)
Ответ на: комментарий от aidaho

В случае с ext4 станет перезаписывать уже выделенные блоки

Вот это очень, очень плохо для данных, поэтому и думаю о режиме journal, но он избыточен по сравнению с CoW.

dva20
() автор топика
Ответ на: комментарий от aidaho

а я читал еще в ядре 4.9 xfs получила cow способности. Если покопаться наверное еще найдутся фс

jtad
()
Ответ на: комментарий от dva20

А btrfs безопасно сейчас использовать (для хомяка)? Как она себя ведёт в реальных условиях, на боевых серверах? Или это всё еще эксперементальная ФС?

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

Если интересно, то могу запилить топик как недавно из-за глючного железа умирала btrfs с сотнями битфлипов.
Много лет назад в аналогичной ситуации наглухо убилась ext3, а btrfs стонала, деградировала но работала. Я немного впечатлился.

aidaho ★★★★★
()
Ответ на: комментарий от dva20

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

Всё очень просто: HDD.

aidaho ★★★★★
()
Ответ на: комментарий от dva20

о есть еще миллион конфигов в /home от сотни приложений

Посчитал, всего 10 (десять). Всего-то.

anonymous
()

и не могу понять

А зачем? Ни разу не сталкивался с этим. Хомяк (выборочно) бекаплю, и все. В основном конфиги и скрипты из домашнего bin (~/bin). Правда все это на одном и том же компьютере на разных разделах, и ни разу не пригодилось.

anonymous
()
Ответ на: комментарий от aidaho

Всё очень просто: HDD.

Точно! :) Дефрагментация замучает. А вот на SSD как я понимаю дефрагментация btrfs - пофигу. Планирую на днях переехать на SSD, но встал еще один вопрос сейчас - ext4 или btrfs, но ИБП уменя сейчас нету и рубильник стали часто дёргать, раз в месяц стабильно ((

dva20
() автор топика
Ответ на: комментарий от anonymous

Не сталкивался потому видимо, что рубильник не так часто дергают как у меня или ИБП есть. У меня сейчас нет ИБП, нужен мощный, ватистый, пока позволить себе не могу, поэтому и с журналированием заморочился.

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

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

dva20
() автор топика
Ответ на: комментарий от dva20

но встал еще один вопрос сейчас - ext4 или btrfs

Зачем btrfs для домашнего компа? У всех, конечно, по разному. У меня какая-то устоявшаяся конфигурация, никаких снэпшотов просто не надо. Была btrfs, но профита в ней не увидел, правда и не искал.

anonymous
()
Ответ на: комментарий от anonymous

Зачем btrfs для домашнего компа?

Пытаюсь найти что-то надежное, но не такое избыточное как режим data=journal для EXT4 который вдвое быстрее убьёт SSD, при этом, чтобы рубильник который дергают на моей улице не оставил мне все файлы в нечитабельном для ФС состоянии. На NTFS недавно убил с 2 десятка своих фоток, заметил поздно, и они улетели в бекап - синхронизировались с другим диском и так я потерял их (( Метаданные все живые, а вот содержимое - corrupted, причина тому отсутствие журналирования или CoW который в BTRFS имеется. Вот поэтому и нужно для домашнего компа.

dva20
() автор топика
Ответ на: комментарий от aidaho

Если интересно, то могу запилить топик как недавно из-за глючного железа умирала btrfs с сотнями битфлипов.

Запили, плиз.

greenman ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.