The OpenNET Project / Index page

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



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

Оглавление

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

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


25. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от User294 (??), 12-Мрт-09, 18:39 
>работать на ура. Проблему надумали?

На самом деле трабл в том что ФС печется о валидности метаданных а что по факту случится с файлом и юзерскими данными в нем ей как бы это помягче сказать, глубоко фиолетово.И это неизбежно ведет к потере данных.И не то чтобы это следует приветствовать, ОСОБЕННО если это ведет к вот такому откровенному просеру данных.

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

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ообщить модератору

40. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от Аноним (56), 12-Мрт-09, 19:26 
>На самом деле трабл в том что ФС печется о валидности метаданных
>а что по факту случится с файлом и юзерскими данными в
>нем ей как бы это помягче сказать, глубоко фиолетово.

Это не трабл. Это ОЖИДАЕМОЕ поведение операционной системы. О данных программы должна заботится сама программа. За подробностями смотри man 2 write, когда данные реально пишутся на диск, и как программа может этот процесс контролировать.

>И это неизбежно ведет к потере данных.

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

>И не то чтобы это следует приветствовать, ОСОБЕННО
>если это ведет к вот такому откровенному просеру данных.

Кривой софт должен быть исправлен или выброшен.


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

113. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."  +/
Сообщение от User294 (??), 13-Мрт-09, 15:42 
>Это не трабл. Это ОЖИДАЕМОЕ поведение операционной системы.

Если вы хотите юзать операционку которая норовит поднасрать - это ваше право.А я хочу чтобы дефолты операционки не стреляли мне в пятки.Если меня перфоманс будет колыхать больше интегрити, я согласен подкрутить параметры ФС - для скоростных применений тюнить 1 хрен придется, как часть процесса это нормально.А вот херить мои файлы по дефолту - не сметь.Говно та ФС которая осмелится на такое.И это не обсуждается.Мои данные мне ценнее чем левые отмазки разработчиков про юзеж sqlite и правильную работу с файлами.Грубо говоря - да, я не приветсвую софт сделанный по принципу "на отъ..сь".Даже если он и соответствует каким-то там стандартам, меня это мало колышет.У меня есть некоторый набор МОИХ критериев при которых я рискну связаться с тем или иным софтом.Пока-что то что я увидел насчет EXT4 для меня означает что у МЕНЯ его в СИСТЕМНОМ КАТАЛОГЕ не будет.А там где меня колыхала скорость, я давно поюзал XFS подпертый упсой, с барьерами и прочая, по возможности с readonly (насколько возможно) данными.Нафиг мне тогда этот EXT4 вообще сдался?У XFS все что в нем есть было сто лет назад уже.Не было - такой же стабильности и надежности к которой все привыкли за годы юзежа EXTов (во всяком случае ора про зануление файлов - хватает).

>О данных программы должна заботится сама программа.

Конечно, вместо того чтобы ОДНИМ програмерм сделать надежную ФС надо ВСЕХ попытаться построить.Это безнадежное начинание ессно заведомо ПРОВАЛИТСЯ и как всегда итог будет прост: У ЮЗЕРОВ БУДУТ ХЕРИТЬСЯ ФАЙЛЫ.И никого не будет колыхать что программы "неправильные", раньше они прекрасно работали.А на стандарты позикса всем глубоко положить.И отмазка програмера что поведение соответствует позиксу мало кого волнует кроме него самого.Остальным нужна работающая и надежная ФС а не соответствие стандартам и прочая - принцип "на отъ...сь" в таком вопросе ИМХО не пройдет.

>За подробностями смотри man 2 write, когда данные
>реально пишутся на диск, и как программа может этот процесс контролировать.

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

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

Сравнили БД у которой поди свое журналирование припахано (чтобы не зависеть от ФС вообще) и обычные программы.Если каждую программу делать монстренком типа постгреса, виндовс виста покажется очень скромной, быстрой и не требовательной к ресурсам ОС :)

>Кривой софт должен быть исправлен или выброшен.

Исправляйте.Выбрасывайте.Вот только исправлялка может сломаться а если все выбросить - зачем вам тогда вообще компьютер?А так - программы неидеальные, да.И совсем не обязательно помогать програмерам лищний раз нарваться на грабли или заставлять их воркэраундить закидоны не в меру капризных ФС.И исправлять абы какую работу ФС путем запрягания програмеров на написание вычурных конструкций - странный подход.Так и на сраный фат можно файлы писать.Зачем тогда вообще журналируемые ФС какие-то?

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

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

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




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

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