The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проблемы с потерей данных на Ext4 разделах в тестовой версии..., opennews (??), 12-Мрт-09, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


32. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от _umka_ (ok), 12-Мрт-09, 19:02 
>>работать на ура. Проблему надумали?
>
>На самом деле трабл в том что ФС печется о валидности метаданных
>а что по факту случится с файлом и юзерскими данными в
>нем ей как бы это помягче сказать, глубоко фиолетово.И это неизбежно
>ведет к потере данных.И не то чтобы это следует приветствовать, ОСОБЕННО
>если это ведет к вот такому откровенному просеру данных.

можно еще вспомнить что в современных HDD (а уж тем более в SCSI & SAS) контролерах есть свой кэш - часто на десятки мегабайт.
Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся на поверхности (persistent storage).
Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная,
Даже и с fsync - не сильно лучше. Опишу ситуацию.

создали очень много каталогов в нем сделали файл и туда записали.
после чего вызвали fsync.
Как вы думаете - закомитятся на диск все созданые каталоги? Да? не угадали.
согластно man fsync - это не делается, согластно POSIX - остается на усмотрение разрабочиков FS и системы.
>>>>>

       Calling  fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk.  For that an explicit fsync() on
       a file descriptor for the directory is also needed.
>>>>>>

Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает обновленя data + metadata для всех файлов. Но это скорее особенность FS чем требуемое по стандарту поведение.

Ответить | Правка | Наверх | Cообщить модератору

45. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от User294 (??), 12-Мрт-09, 19:42 
>можно еще вспомнить что в современных HDD (а уж тем более в
>SCSI & SAS) контролерах есть свой кэш - часто на десятки
>мегабайт.

Вообще, насколько я помню, нынче все порядочные жесткие диски (и драйвера контроллеров) способны рапортовать факт окончания именно *физической* записи на блин а не в кэш.Раньше натурально была такая проблема что харды врали о успехе факта записи всего лишь сложив данные в кэш но сейчас вроде за счет воплей юзерья до производителей хардов и дровописателей дошло и это крайне паскудное явление насколько я знаю вроде пролечили в массе своей.Поскольку оно больно уж сурово клещится с логикой любого журналирования (если железо врет о успехе записи - с этим ничего не сделать, на таком железе просто нельзя надежно работать).Еще кстати некоторые харды умеют юзать заряд конденсаторов и инерцию шпинделя чтобы завершить запись.Некоторые ограничивают размер своего кэша на запись кстати - из 32 мегов на *запись* может юзаться и меньше чем 32 мега.

>Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся
>на поверхности (persistent storage).

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

>Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная,

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

>согластно man fsync - это не делается, согластно POSIX - остается на
>усмотрение разрабочиков FS и системы.

Угу, все сделано для того чтобы можно было просрать данные как можно более изящно.Круто!

>Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает
>обновленя data + metadata для всех файлов. Но это скорее особенность
>FS чем требуемое по стандарту поведение.

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

Ответить | Правка | Наверх | Cообщить модератору

48. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от darkkemail (?), 12-Мрт-09, 19:51 
>Некоторые ограничивают размер своего кэша на запись кстати - из 32 мегов
>на *запись* может юзаться и меньше чем 32 мега.

А зачем в самом винте буфер на чтение? С readahead вроде система неплохо справляется, нет?

Ответить | Правка | Наверх | Cообщить модератору

92. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от User294 (??), 12-Мрт-09, 23:36 
>А зачем в самом винте буфер на чтение? С readahead вроде система
>неплохо справляется, нет?

Не у всех есть readahead, особенно пока система только грузится, etc.

Еще харду его истинная геометрия виднее.Может умудряются что-то оптимизнуть на основе этого знания?Система то видит это как линейный массив или совершенно левые CHS, особенности физики она не знает.А вот фирмвара контроллера в курсе истинной картины.

Ответить | Правка | Наверх | Cообщить модератору

101. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от _umka_ (ok), 13-Мрт-09, 10:02 
>[оверквотинг удален]
>
>Вообще, насколько я помню, нынче все порядочные жесткие диски (и драйвера контроллеров)
>способны рапортовать факт окончания именно *физической* записи на блин а не
>в кэш.Раньше натурально была такая проблема что харды врали о успехе
>факта записи всего лишь сложив данные в кэш но сейчас вроде
>за счет воплей юзерья до производителей хардов и дровописателей дошло и
>это крайне паскудное явление насколько я знаю вроде пролечили в массе
>своей.Поскольку оно больно уж сурово клещится с логикой любого журналирования (если
>железо врет о успехе записи - с этим ничего не сделать,
>на таком железе просто нельзя надежно работать).

Сделав то что вы говорите - вы убьете процентов 40 производительности hdd, собственно по тому и есть контролеры с батарейками и подпитывание диска какое-то время и тп.

>
>>Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся
>>на поверхности (persistent storage).
>
>Оно все так, но вроде современные диски и драйвера контроллеров все-таки научились
>совместно играть в эту игру правильно в массе своей?Потому что данное
>поведение сильно рушит логику любого журналинга вообще.Журнал не может работать коректно
>если железо врет о успехе записи а запись журнала потом взяла
>и просралась из-за слета питания.

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

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

как вы сами заметили далеко не со всеми девайсами и не со всеми дровами.

>
>>согластно man fsync - это не делается, согластно POSIX - остается на
>>усмотрение разрабочиков FS и системы.
>
>Угу, все сделано для того чтобы можно было просрать данные как можно
>более изящно.Круто!

именно ;) тут звучали слова о fsync как панацеие от этого - вот разочарование.


>
>>Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает
>>обновленя data + metadata для всех файлов. Но это скорее особенность
>>FS чем требуемое по стандарту поведение.
>
>Понимаете в чем проблема, мне если честно несколько насрать на стандарты когда
>вопрос идет о сохранности моих данных.Тот факт что мои данные по
>стандарту можно просрать для меня как-то довольно слабое утешение.

Включите sync и радуйтесь жизни :)
любой async потенциально опасная вещь - и соблюдение всех стандартов не гарантирует что FS будет не противоречива. Я лиш это пытался донести.
Это как весы - скорость vs надежность - обе вещи одновременно не бывает.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру