Ext4 такая ext4

Что ещё за линейный лог? :) Мы же про БД говорили. Там журнал+данные.

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

Для бд настройки vm* нужно делать в зависимости от типа нагрузки. Но все равно большой dirty_ratio в плане кеша не нужен, ибо будет двойное кеширование, т.к. СУБД тоже кеширует.

Но данные теряет только ext4.

4.2

т.к. СУБД тоже кеширует.

если она знает об O_DIRECT то нет. Но тогда и vm.dirty* на неё не распространяются.

Это было давным-давно.

если она знает об O_DIRECT то нет. Но тогда и vm.dirty* на неё не распространяются.

O_DIRECT во многом аналогичен -sync, в частности по ухудшению производительности. Про него стоит думать только в крайних случаях. Когда реально нет вообще никакого упса.

Журналируемая fs гарантирует целостность fs, но не целостность данных.

в случае аппаратного сбоя гарантии НИКТО не даст. Даже при журналировании данных.

Речь идёт не о данных, а о структуре ФС.

А если сохранность данных все-таки волнует, то очень естественно ожидать от ФС следующего:

наивный... Если ты не делаешь бекапы, у тебя НЕТ важных данных. А если есть, то тот дурак, который тебе эти данные доверил, скоро их лишится.

Речь идёт не о данных, а о структуре ФС.

в случае ТС, как я понял, структура не нарушилась. Все файлы на месте. Только там ничего нет.

И да, а что тебе с этой структуры? Тебе за неё деньги платят?

fsck и потом найдет и присоединит к нужной директории

гарантия 99%.

Но в целом ППКС

O_DIRECT во многом аналогичен -sync,

http://www.kernel.org/doc/man-pages/online/pages/man2/open.2.html
The O_DIRECT flag on its own makes at an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC that data and necessary metadata are transferred.

Меня в последнее время напрягает, что ext4 теряет содержимое файлов при нехватке места. Т.е. копируешь из mc на раздел, забитый под завязку, скажем, фотки, бац — место кончилось. Жмёшь отмену копирования, чистишь, копируешь остаток... опаньки, часть фоток оказалась битой. Я уже десятка два файлов с астрофото так убил.

Ситуация усугубляется тем, что свободное место может криво показываться. df показывает ещё 2Гб, mc показывает 4Гб, на деле после копирования гигабайта место кончается. df при этом честно показывает 0, mc — что ещё дофига :)

в случае ТС, как я понял, структура не нарушилась.

Вот поэтому к ФС претензий нет, так как большего она не может гарантировать.

И да, а что тебе с этой структуры?

Если сохранилась структура, можно не создавать ФС заново.

Тебе за неё деньги платят?

Нет. За бекапы платят.

Если ты не делаешь бекапы, у тебя НЕТ важных данных

это уже обсуждалось. ФС для которой нужно полное восстановление данных после малейшего сбоя не нужна. Просто потому что неудобно/долго бегать каждый раз за бэкапами. Вот мне что-то не хочется восстанавливать 3тб данных даже на sas-дисках. А небольшую потерю контента допустима. А ещё лучше если файлуха напишет какие файлы покоцались (хотя бы иноды укажет) чтобы можно было выборочно восстановить.

Меня в последнее время напрягает, что ext4 теряет содержимое файлов при нехватке места.

копируешь из mc на раздел, забитый под завязку

А не с mc ли это связано?

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

проблема в том, что IRL устройства не на 100% надёжные. И даже сильно не на 100%. HDD - не исключение. И исправить все 100% ошибок во всех 100% случаев не может ни одна ФС. Мало того - и не должна. Защита от сбоев - важная характеристика ФС, но не самая важная, и уж тем более не единственная.

fsck в случае ext4 не слишком-то способствует нахождению данных. Вот такой факт, увы.

ты не поверишь, но в число задач fsck восстановление данных никогда и НЕ входило. fsck восстанавливает только структуру данных, да и то, только в большинстве случаев, когда повреждения незначительны. В любом случае, вызов fsck после сбоя - это нештатный режим, и он нужен в основном лишь для того, что-бы _проверить_ целостность ФС.

Не распарсил.

узнай, как работает rename в Linux. Всё станет понятнее.

Какой смысл в целостности ФС, если она невменяемым и непредсказуемым образом теряет данные, и заявляет, что это не её проблемы?

вообще-то это не ФС потеряла данные. Данные были испорчены из-за аппаратного сбоя. А ты хаешь ФС за то, что она не смогла восстановить. Но если ты не знал, то это и не возможно.

Давайте тогда сразу после блэкаута делать mkfs, так по-крайней мере будет уверенность, что все данные в самом деле восстановлены, пусть и из бэкапа.

дык так и делаем. У тебя не так?

и если отрубят свет то данные в кеше просто изчезнут

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

Поэтому бесперебойник при отложенной записи в фс или дисковой системе де-факто необходим.

ИМХО можно и без бесперибойника, но тогда надо быть готовым к тому, что придётся иногда откатиться к последнему бекапу. Ситуация маловероятная, но IRL это возможно.

За счет чего журнал может оказаться поврежденным? Недозаписанным - да, может, но для него это штатная ситуация.

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

Она есть дефакто. Кеды за собой тащат то ли постгрес, то ли мускуль

хуже

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

повторяю ссылку: [KDE][Торт?][Готов для десктопа?]Virtuoso-t

А можешь ссылочек накидать про такую настройку СУБД?

это действительно самоочевидный стандарт дефакто.

Хочешь сказать, что это не баг и не неисправность аппаратуры, а именно by design?

именно так. такие вот хреновые у нас HDD. Ничего не поделать...

в число задач fsck восстановление данных никогда и НЕ входило

Смотря какая файлуха, какой fsck и какая ошибка.

Меня в последнее время напрягает, что ext4 теряет содержимое файлов при нехватке места. Т.е. копируешь из mc на раздел, забитый под завязку, скажем, фотки, бац — место кончилось. Жмёшь отмену копирования, чистишь, копируешь остаток... опаньки, часть фоток оказалась битой. Я уже десятка два файлов с астрофото так убил.

копирую cp, Dolphin, Thunar - УМВР. Может что-то с mc?

Если сохранилась структура, можно не создавать ФС заново.

логично.

Нет. За бекапы платят.

мне тоже.

это уже обсуждалось. ФС для которой нужно полное восстановление данных после малейшего сбоя не нужна. Просто потому что неудобно/долго бегать каждый раз за бэкапами. Вот мне что-то не хочется восстанавливать 3тб данных даже на sas-дисках. А небольшую потерю контента допустима. А ещё лучше если файлуха напишет какие файлы покоцались (хотя бы иноды укажет) чтобы можно было выборочно восстановить.

это всё безусловно верно, и в EXT4 это всё реализовано. В большинстве случаев данные успешно переживают сбои. В крайнем случае в MySQL есть REPAIR TABLE, которое всегда спасает. В других СУБД тоже есть. Ну и уж совсем для редкого (хотя и возможного IRL) случая имеются бекапы.

В EXT3 были проблемы (fsck работала хорошо, но иногда оочееень меееедлееееннноооо), но сегодня эти проблемы решены.

Смотря какая файлуха, какой fsck и какая ошибка.

я говорил про fsck.ext4. И про ошибку связанную с аппаратным сбоем, например пропадание питания или скажем перегрев, который вызвал выключение системы или ещё что-нибудь подобное. При этом никакой журнал не может ничего гарантировать, и никакая ФС.

При этом никакой журнал не может ничего гарантировать

По твоей логике он вообще ничего не гарантирует. Для чего он вообще тогда нужен?

Ответ: максимально минимизировать потери информации.

Ну и гарантии в каком-то виде есть. Если пропало питание то всё что уже записалось никуда не денется. Вопрос в том что делать с недозаписанными данными. Вот тут хочется чтобы fsck который-никому-ничего-не-должен не разнёс лишнего.

По твоей логике он вообще ничего не гарантирует. Для чего он вообще тогда нужен? Ответ: максимально минимизировать потери информации.

да, согласен. Ничего не гарантирует, но тем не менее минимизирует потери. Пиво вот продают в стеклянных закрытых герметично бутылках. Они гарантируют сохранность пива при правильном хранении. При неправильном - не гарантируют. И тем не менее, пиву ничего не будет, если его скажем 5 минут подержать на открытом солнце, или использовать на след. день после окончания срока годности. Но вот если бутылку открыть, то через сутки пиво выдохнется. Точно так же и с ФС.

Ну и гарантии в каком-то виде есть. Если пропало питание то всё что уже записалось никуда не денется. Вопрос в том что делать с недозаписанными данными. Вот тут хочется чтобы fsck который-никому-ничего-не-должен не разнёс лишнего.

fsck.ext4 ничего и не разносит. Ну были недозаписанные файлы открытые каким-то недоIDE - не смогли восстановится. В случае VIM всё было-бы нормально (там есть средства восстановления. свои).

Точно так же и с ФС.

не точно так же. Именно для неправильного хранения журнал и нужен.

не точно так же. Именно для неправильного хранения журнал и нужен.

точно. журнал == герметически закрытая бутылка из тёмного стекла. Но даже она НЕ защищает на 100% от хранения в неправильных условиях.

журнал == герметически закрытая бутылка из тёмного стекла

хватит тратить своё и моё время этой фигнёй.

Речь о том когда и как теряются/уродуются данные и как минимизировать риски, а не о стеклотаре.

хватит тратить своё и моё время этой фигнёй.

как скажешь:

Ну и гарантии в каком-то виде есть. Если пропало питание то всё что уже записалось никуда не денется.

о каких гарантиях ты говоришь? Что-бы всё _гарантированно_ записалось, нужно syncнуть раздел, а лучше вообще размонтировать. Тогда его можно безопасно(для данных) отключить. Ну и понятно, что так никто никогда делать не станет. А даже если и станет, то нет гарантии, что момент выключения не затронет sync(скорее всего как раз и затронет, ибо он будет происходить 99% времени)

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

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

а ты дашь гарантию, что данные записываются _подряд_? Ну как на FDD, сектор за сектором? Я что-то очень сомневаюсь...

о каких гарантиях ты говоришь?

нужно syncнуть раздел

Сам ответил. Хотя искорёженный журнал или ещё что-нить могут повредить. Вот интересно выявить эти случаи.

момент выключения не затронет sync

в смысле свет в этот момент не вырубится?

а ты дашь гарантию, что данные записываются _подряд_?

Нет. Даже не намекал что я так думаю. Почему ты спросил?

А не с mc ли это связано?

Нет. По cp тоже накрывается, просто я пользуюсь им много реже. Но пару раз запарывал кино. При чём что в фотках, что в видео, накрывается не весь файл, а кусок. Фотка частично показывается, частично — битая. В видео накрывается небольшой кусок, который потом после перехеширования докачивается из торрента.

Может попробовать найти условия в которых воспроизводится?

Кстати, это не внешний USB-диск?

Сам ответил. Хотя искорёженный журнал или ещё что-нить могут повредить. Вот интересно выявить эти случаи.

по идее - не может повредить, если каждая запись там имеет что-то вроде контрольной суммы. Вот только это долго, и восстановится далеко не всё - ФС просто откатится на тот момент, в котором она ТОЧНО уверена. В данном случае, не было возможности понять, что было в данных файлах. Вот ФС их и откатила к начальному состоянию, которое известно точно. Мне кажется, это более логично, чем попытка угадать содержимое файла прямо перед аварией. Ну и очевидно быстрее и проще.

в смысле свет в этот момент не вырубится?

в смысле, что ты постоянно будешь syncать свой журнал, и свет точно вырубится именно в момент этого sync'а.

Не, можно требовать хранения старых данных, которые были записаны ДО прошлого sync'а и не тронуты после него. Можно потребовать, что новые записи были отменены, если они не были завершены. Но требовать что-бы всё правильно было сделано в момент этого sync'а - думаю нельзя. Потому, как раз для надёжности, лучше-бы этих sync'ов было-бы поменьше. Пусть пишет кусками, по своему усмотрению, нравится ей по 12345 байт, пусть так и пишет, особенно учитывая, что насильно заставить писать по 23 байта не получится, оно всё равно будет писать по 12345, ибо иначе не умеет. А потом - переписывать.

Нет. Даже не намекал что я так думаю. Почему ты спросил?

потому-что неизвестно, КАК записываются данные, и потому непонятно, ЧТО получится, если прервать запись в произвольный момент. В принципе, нетрудно показать, что получится может ВСЁ, ЧТО УГОДНО. Мы только можем увеличить вероятность восстановления структуры и данных разными костылями, типа журналирования. Кроме того, несложно показать, что чем лучше наш костыль, тем сильнее он тормозит штатную работу. А деньги платят именно за последнюю.

При чём что в фотках, что в видео, накрывается не весь файл, а кусок. Фотка частично показывается, частично — битая. В видео накрывается небольшой кусок, который потом после перехеширования докачивается из торрента.

а железо точно нормальное? такое у мну было с битой памятью (ага, memtest работал несколько часов, перед тем, как показать сбой. ИЧСХ, это происходило именно при нехватке места на HDD. Почему так - я не знаю)

Может попробовать найти условия в которых воспроизводится?

Я же пишу, что нашёл. Когда копируешь на забитый под завязку диск ext4 :) С некоторых пор воспроизводимость почти 100%. При чём повредиться может даже уже скопированный до этого файл.

Кстати, это не внешний USB-диск?

Нет, LVM том. Может, правда, связано именно со связкой ext4+lvm (на xfs+lvm такого нет, на чистой ext4 не сталкивался, так как место никогда не кончалось в условиях большого копирования).

а железо точно нормальное?

На XFS всё отлично. И пока не утыкаешься в нехватку места, то ext4 тоже работает отлично, хоть десятками гигабайт копируй.

такое у мну было с битой памятью

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

Я же пишу, что нашёл. Когда копируешь на забитый под завязку диск ext4 :) С некоторых пор воспроизводимость почти 100%. При чём повредиться может даже уже скопированный до этого файл.

ну я копирую, УМВР.

Нет, LVM том.

не пробовал, у меня без LVM

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

ага.

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

вот у меня тоже почему-то _только_ при копировании и нехватке места. И да, ещё перезагружалась сама по себе примерно раза 3 в месяц (из-за этого и стал гонять тест памяти). Кстати, там была EXT3, но думаю это не важно.

Читаю и неверю что все это происходит в 2012 году ... ппц... Сам недавно столкнулся с ситуацией когда после сбой улетел раздел виртуально машины который был LVM+ext4 проверка fsck его так вылечила что мертвые лучше выгледят. Я грешил на LVM но выходит связка LVM+ext4 не для продакшена ... Вобщем откройте для себя ZFS.

ЗЫ помнится O_DIRECT ставят innodb для выключения двойной буферизации ... ЗЫ Сам использую ubuntu mint на десктопе как раз под ext4 и там тоже есть lvm ... печально.

улетел раздел виртуально машины который был LVM+ext4

у меня была «жопа»: было снято дофига снапшотов LVM, были активные io, удаление снапшотов, sync и один из процессов связанных с LV застрял в состояние D и продолжалось это крайне долго. Я решил вырубить рубильником - благо были и бэкапы и критичного не было и время ночь.

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

Я же пишу, что нашёл. Когда копируешь на забитый под завязку диск ext4 :) С некоторых пор воспроизводимость почти 100%. При чём повредиться может даже уже скопированный до этого файл.

Не смог воспроизвести. Попробовал 4-х гиговый раздел с ext4 на LVM, заливал в одном случае большие файлы, в другом — кучу маленьких. После отмонтирования-монтирования все md5-хэши совпали.

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

После отмонтирования-монтирования все md5-хэши совпали.

А оно тут при чём? o_O

мы не имеем на сегодня никакого _гарантированного_ способа сохранения файлов

man fsync

man fdatasync

А оно тут при чём? o_O

Кэши таким образом сбросил.

Не, можно требовать хранения старых данных, которые были записаны ДО прошлого sync'а и не тронуты после него.

вот этого все и хотят тут :). Это и обсуждаем.

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

никто тут не требует :).

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

не, наоборот, пусть чаще маленькими кусками накатывает транзакции (или что там) чтобы минимизировать повреждения.

ЧТО получится, если прервать запись в произвольный момент.

надо спеки хардов посмотреть для интереса...

Читаю и неверю что все это происходит в 2012 году ... ппц... Сам недавно столкнулся с ситуацией когда после сбой улетел раздел виртуально машины который был LVM+ext4 проверка fsck его так вылечила что мертвые лучше выгледят. Я грешил на LVM но выходит связка LVM+ext4 не для продакшена ...

откуда я знаю? УМВР. А какие улучшательные патчи ставил ты - мне неведомо.

Вобщем откройте для себя ZFS.

зачем? если УМВР? ЧЯДНТ?