Ext4 такая ext4

to УМВРЧЯДНТ Боевой серв с дебианом никаких левых патчей никаких ковыряний в fstab. Конкретный мысли по восстановлению данных в таких случаях есть ? Или считать связку lvm+ext4 нестабильной ? Возможно при инсталяции самой виртуалки сначала тоже сделали lvm (весь этот зоопарк инсталировался до меня) тоесть lvm+lvm+ext4.

Мы уже выяснили, что определению «обычного» файла у тебя свое, глубоко личное.

Махнут такой Махнут. Все у него дураки, один он умный.

По теме: и в NTFS $MFT и прочие служебные структуры с журналом вместе — тоже обычные файлы, так что ext* тут не исключение

обоснуй.

Традиция.

to УМВРЧЯДНТ Боевой серв с дебианом никаких левых патчей никаких ковыряний в fstab. Конкретный мысли по восстановлению данных в таких случаях есть ?

да. делай бекапы. Я уже говорил - сбой по питанию _может_ убить _любую_ ФС. Что-бы не говорили здешние теоретики - я не теоретик. Я практик.

Или считать связку lvm+ext4 нестабильной ? Возможно при инсталяции самой виртуалки сначала тоже сделали lvm (весь этот зоопарк инсталировался до меня) тоесть lvm+lvm+ext4

100% гарантии даёт только морг. И да, lvm+lvm+ext4 я не тестировал. И в продакшене не буду. ССЗБ.

Что-бы не говорили здешние теоретики

Этого тут никто и не говорил :). Более того, а кто гарантирует целостность данных при отсутствии сбоя питания? Да никто. Если какие-то ошибки можно выявить и устранить на уровне ОС контрольными суммами, то вот внезапную смерть харда никто не отменял. Да что харда, у меня на ноуте оператива сбойнула и в зашифрованных файлах ecryptfs появился мусор.

Короче, никто ничего на 100% не гарантирует.

100% гарантии даёт только морг

google://в морге нашли живого

Никому нельзя верить.

Этого тут никто и не говорил

некоторые ещё надеются...

Короче, никто ничего на 100% не гарантирует.

согласен.

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

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

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

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

Сходу нигде ничего не нашёл про поведение хардов без питания.

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

Пришёл к выводу что это чья-то шутка на которую многие купились.

Навскидку, US 2010/0165811 A1

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

Навскидку, US 2010/0165811 A1

А это ничего не доказывает, просто застолбили идею.

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

Возможно, это позволит немного инфы скинуть на флеш.

Кстати на это я тоже видел патент, 2001 года, кажется. Правда в нём не было сказано про флеш, но non-volatile memory. И батарейка (power storage).

Хм, хотел было сказать что проще воткнуть ионистр за бакс, но подсчитал энергию и, как ни странно, с блинов гораздо больше можно снять чем с 0.1Ф 5V ионистра.

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

требуется это не уродовать уже записанные данные при обрыве питания.

Это всё и нужно только для того, чтобы иметь возможность рапортовать о данных в кэше записи как о записанных, то есть не портить «записанные» данные.

Это всё и нужно только для того, чтобы иметь возможность рапортовать о данных в кэше записи как о записанных, то есть не портить «записанные» данные.

а харды так и не делают. И рейды без батарейки не делают.

насколько я понял - это для всего кеша.

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

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

один сектор можно защитить и по другому - достаточно одной ячейки в энергонезависимой памяти, в которой хранится номер последнего записанного сектора. Если питание выключится в момент записи X, то последним будет считаться предыдущий Y, а сектор X будет считаться свободным. Сектор X будет считаться записанным лишь в том случае, если запись завершилась успешно. Таким же образом можно обезопасить запись на цилиндр. Это такое «микрожурналирование», и наверняка оно уже запатентовано и везде применяется.

Это такое «микрожурналирование», и наверняка оно уже запатентовано и везде применяется.

«Мы в компании называем это микрожурналирование. Кстати, это запатентованное выражение, так что если у вас с этим какие-то проблемы, увидимся в суде».

да возможно и так. главный вывод это то что запись на уровне сектора атомарна и на это можно расcчитывать.

что-бы всё правильно было сделано в момент этого sync'а - думаю нельзя.

поэтому для настоящей надежности нужно делать fsync() посекторно. добавили 100K данных - сделали fsync() - сделали отметку о этих данных где то в дереве (отметка занимает не больше одного сектора) - сделали fsync()

главный вывод это то что запись на уровне сектора атомарна и на это можно расcчитывать.

обидно то, что на уровне дискового кеша запись может и не закончится... Во всяком случае, рассчитывать на это нельзя. А EXT4 на это рассчитывает, как и _все_ остальные ФС.

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

поэтому для настоящей надежности нужно делать fsync() посекторно.

этим диск должен заниматься. Где ты такой диск нашёл? Почём?

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

Есть ata-комманда FLUSH CACHE EXT которая как раз и создана для этого. На уровне линуха поддержка, вроде, есть.

этим диск должен заниматься. Где ты такой диск нашёл? Почём?

поэтому для настоящей надежности нужно делать fsync() посекторно - программа должна делать fsync() посекторно - выше я привел пример

После fsync (если он успешно завершился) данные уже лежат на диске (больные на голову рейды с writeback и без батарейки не в счёт). Не надо ничего мудрить.

Есть ata-комманда FLUSH CACHE EXT

если ты после каждых 100К будешь выполнять эту команду, то она и будет выполняться, в момент отключения питания. И что станет с твоими данными?

После fsync (если он успешно завершился

а если нет?

а если нет?

значит или хард сдох или питание исчезло. Первое и так непоправимо, а второе не имеет значение, ведь мы знаем что именно недозаписалось.

И что станет с твоими данными?

всё отлично, не будет только последнего куска. Это не то же самое «не будет произвольного куска» или «повреждение данных в произвольном месте». Поэтому транзакции рулят.

Ну а что на практике бывает когда один из уровней не удовлетворяет спекам нам ТС написал.

не имеет значение, ведь мы знаем что именно недозаписалось.

откуда нам знать, что именно было недозаписано из дискового кеша? И что - было.

всё отлично, не будет только последнего куска.

почему именно последнего?

После fsync (если он успешно завершился) данные уже лежат на диске (больные на голову рейды с writeback и без батарейки не в счёт). Не надо ничего мудрить.

я о том же о чем drBatty - например у тебя есть гигавайт данных в кеше - ты делаешь fsync() - где гарантия что во время fsync() запишется все? гарантии нет - потому для надежных приложений лучше делать какой то журнал и при работе с журналом иметь ввиду что запись с пределах сектора атомарна

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

да просто надо делать как сделано в базах данных, там уже давно всё продумано.

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

да просто надо делать как сделано в базах данных, там уже давно всё продумано.

вот это нужно учитывать

если всё такое журналируемое и надёжное то от чего файлы обнуляются или мусором забиваются.

одно из двух либо не правильный дизайн либо не правильная реализация)

А вот нашлось руководство для ССЗБ желающего выстрелить себе в ногу http://jakshi.org.ua/dokuwiki/оптимальные_настройки_для_файловой_системы_ext4... И кто то же пишет такие руководства ...

Ты ещё скажи кто же пишет такие файловые системы.

Кому надёжность, кому производительность...

извиняюсь,но не охото читать все сооьщения: к чему пришла дискуссия, есть в ext4 какие-то косяки, рискованные ситуации, которых нужно избегать для избежания потери данных? просто все о чём-то так спорят в течении нескольких дней, а о чём - не пойму - о каких-то проблемах с кэшем?

Мне тоже интересно, практически не читал треда, хоть я и ТС.

все о чём-то так спорят в течении нескольких дней

да всё вокруг одного: ничто не заменит бэкап.

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

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

1. создаём новый файл в 0 байт

2. копируем туда старый со всеми изменениями

3. одновременно преименовываем старый file в file~, и новый файл в file.

Операции №1 и №3 являются атомарными, не откладываются, и не кешируются. Однако операция №2 атомарной НЕ является, мало того, она ещё и откладывается и кешируется. Потому, если в момент сбоя отложенная операция №2 ещё не завершилась, новый файл откатывается на последнее непротиворечивое состояние, когда он был размером 0 байт, т.е. обнуляется. Фишка в том, что операция №3 выполняется ДО операции №2, о чём почему-то всегда забывают, потому в момент восстановления после сбоя, файл УЖЕ является новым, а старый переименовался в file~, или вообще выкинут в /dev/null, если админу на него наплевать.

А вот как появляется файлы с «мусором» - не знаю, ибо не встречал подобного поведения.

вот это нужно учитывать

нужно-ли?

одно из двух либо не правильный дизайн либо не правильная реализация

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

извиняюсь,но не охото читать все сооьщения: к чему пришла дискуссия, есть в ext4 какие-то косяки, рискованные ситуации, которых нужно избегать для избежания потери данных?

да. есть рискованные ситуации - это ВНЕЗАПНОЕ пропадание питания при отсутствии бекапа. Только вот это беда _всех_ ФС, а не только EXT4. EXT4 в этой ситуации обычно хотя-бы структуру свою сохраняет, а данные например в СУБД, можно восстановить силами этой СУБД. Райзер как-то убил у меня раздел так, что возможно было лишь восстановление отдельных обрывков файлов с помощью photorec.

просто все о чём-то так спорят в течении нескольких дней, а о чём - не пойму - о каких-то проблемах с кэшем?

речь о том, что некоторые не понимают слово «компромисс». Нельзя и на ёлку влезть, и жопу не уколоть. Если отложить операцию записи, и скинуть данные в кеш, не стоит удивляться, что данные будут безвозвратно потеряны, если память отключить до того, как данные будут записаны на диск. Но некоторые почему-то верят в какую-то неведомую магию журналирования...

нужно-ли?

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

а если большой

а 3 это много или мало? а 33? Что за ГСМ-термины «если большой»? Это у меня - большой, а в этой теме пиши грамотно.

и мы хотим надежности то нужно учитывать.

ясный-красный - хотим. Но не в ущерб производительности и объёму. Предполагается, что места для 100500 снапшотов нет. А CPU не умеет бесконечный цикл за 5 секунд. А ещё предполагается, что есть UPS+бекапы. Или их нет, но и данные не важны, а даже вредны и опасны (явки,пароли).

Короче - это неконструктивный разговор.

А ещё предполагается, что есть UPS+бекапы. Или их нет, но и данные не важны

мир не делится на чёрное и белое. Есть данные которые не очень важны, но которые не хочется терять. Или если не хочется восстанавливать десятки ТБ данных из бэкапа потому что быстро эту операцию не сделать, а время - деньги.

мир не делится на чёрное и белое. Есть данные которые не очень важны, но которые не хочется терять. Или если не хочется восстанавливать десятки ТБ данных из бэкапа потому что быстро эту операцию не сделать, а время - деньги.

да. время === деньги.

а теперь, вы ГОТОВЫ тратить время-деньги на КАЖДУЮ операцию записи, ежели, её можно будет отменить? Вам рассказать, СКОЛЬКО это будет стоить?

Что за ГСМ-термины «если большой»?

от задачи зависит. если файл 1 мегабайт и ты изменяешь его раз в месяц это одно, а если он 10 гигов и изменяется раз в секунду это другое...

А почему никто не говорит что в ext4 журналируются только метаданные ? И ситуация с обнулением типична при подобном подходе ? Btrfs еще сырой остается только ReiserFS ?

вообще там есть разные режимы. data={journal|ordered|writeback}

journal - All data is committed into the journal prior to being written into the main filesystem.

у меня ext4 на ноуте переживает резкие вырубания пару раз в неделю в течении уже не первого и не второго месяца. максимум - fsck просит и ничего не гикнулось еще.