LINUX.ORG.RU
ФорумTalks

Ext4 такая ext4


0

3

Странное событие только что произошло - вырубился внезапно ноутбук (не настроил автовыключение), и все файлы проекта сразу стали пустыми. Благо есть git, и всё было благополучно возвращено.
**** гитовские файлы тоже покорёжило, как и один документ libreoffice.

★★★★

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

Ответ на: комментарий от true_admin

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

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

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

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

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

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

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от post-factum

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

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

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

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

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

гарантия 99%.

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

drBatty ★★
()

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

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

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

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

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

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

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

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

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

post-factum ★★★★★
()
Ответ на: комментарий от drBatty

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

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

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от Manhunt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

хуже

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

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

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

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

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

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

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

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

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от post-factum

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

логично.

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

мне тоже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как скажешь:

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

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

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

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

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

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

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

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

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

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

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

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

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

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

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

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

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от i-rinat

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

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

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

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

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

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

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

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

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

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

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

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

Нет, LVM том.

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

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

ага.

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

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

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

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

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

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

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

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

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

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

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

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

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

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

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

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

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

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

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

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

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

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

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

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