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

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

для /home

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

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

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

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

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

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

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

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

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

copy-on-write

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У всех, конечно, по разному.

Ага. Я для себя посчитал, и оказалось, что мне как раз таки пора: Прозрачное сжатие EXT4/Отговорите от BTRFS/Поток сознания (комментарий)

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

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

Го, я создал: Постмортем BTRFS от рук съехавшего с катушек железа