форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от opennews (??) on 12-Мрт-09, 16:06

При тестировании экспериментальной версии Ubuntu 9.04 всплыли (https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/31...) неожиданные проблемы с надежностью работы Ext4. В Ubuntu по умолчанию включена возможность отложенного распределение информации в ext4 (http://wiki.opennet.ru/Ext4) (Delayed allocation), при которой данные и мета-данные могут оставаться незаписанными до 60 секунд. Данная возможность является одним из главных факторов значительного повышения производительности ext4 по сравнению с ext3. Но пользователи экспериментальной ветки Ubuntu отметили случаи произвольного краха системы, после которого терялось содержимое большого числа файлов, в основном связанных с работой KDE или GNOME. Разбор ситуации показал, что при загрузке KDE и GMOME пересоздают большое число мелких файлов, и если системный крах произойдет через небольшое после загрузки время, эти файлы окажутся обнуленными (в журнал изменения вносятся сразу, но сами данные на диск записаться не успевают). ... URL: http://www.h-online.com/open/Possible-data-loss-in-Ext4--/ne... Новость: http://www.opennet.dev/opennews/art.shtml?num=20715

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Ivan (??) on 12-Мрт-09, 16:06

> Разбор ситуации показал, что при загрузке KDE и GMOME пересоздают большое число мелких файлов Вот! И это, в частности, плохо.

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

	41. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 19:28
	А я в упор не понимаю, в чём проблема, освещенная в новости. Кого-то удивляет, что данные теряются при цепочке read/truncate/write ? Так это нормально — пусть, например, прилетит пишущему процессу SIGKILL в момент между truncate и write... Для конфигов и прочих мелких файлов стандартной идиомой считалось всегда read/write/rename. В man 2 rename отдельно сказано о гарантиях атомарности.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:50
	ну хоть один вразумительный коммент....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 19:59
	>ну хоть один вразумительный коммент.... Если сходить по ссылке дважды — можно найти ответ на глупый вопрос «а что не так с rename». https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/31... Вкратце — в схеме read/create/write/rename тоже не всё гладко из-за этой баги, а говноприложения были названы говноприложениями только из-за того, что они (судя по всему) обновляют файлы конфигов без необходимости... Хотя, может я что-то и недопонял.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 22:13
	можно. (пока по ссылке не ходил, но) с ним многое не так. начиная от фрагментации и заканчивая модными ныне конфигами в xml-формате. но ёлки-палки. как часто меняется конфиг? он имеет важность не менее, чем сама программа. он и есть часть программы. если разработчик о нём не побеспокоиться, то кто? логи конечно не так важны... но как работает с ними логротейт!.. с чужими логами кстати. если какие-то данные в конфиге меняются часто, то это уже не данные для конфига... надо выносить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	95. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от pavlinux (ok) on 13-Мрт-09, 03:18
	У Юниксовой проги вообще не должно быть конфига!!! Это от врагов, из M$ДОС и OS/2, притащилось!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	110. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 14:48
	>У Юниксовой проги вообще не должно быть конфига!!! Да, давайте еще у init стартовые скрипты отнимем :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	135. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 19:07
	init-скрипты не конфиги... и уж точно не перезаписываются во время загрузки. аминь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	151. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 16-Мрт-09, 19:01
	>init-скрипты не конфиги... Это смотря с какой стороны посмотреть :) > и уж точно не перезаписываются во время загрузки. Зато перезаписываются при установке\удалении программ.И некузяво будет если у свежеустановленной программы при внеплановом рестарте вдруг ^#нется стартовый скрипт ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	153. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 16-Мрт-09, 22:13
	нагрузка на фс при установке ни в какое сравнение не идёт с загрузкой... это первое. второе. при установке файло не обнуляется, а заменяется.... т.е. либо то, либо это. :-) а изменённые конфиги вообще не принято менять. видимо дистростроители более правильно понимают работу с файлами. :-DDDDDDDD кстати, вот маленькая статейка для ознакомления - http://ru.opensuse.org/%D0%9E%D0%BF%...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от друг pavlinux on 12-Мрт-09, 16:17

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

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

	8. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним2 on 12-Мрт-09, 16:45
	А че вы так, собственно, бурно реагируете? Не нравится - не пользуйтесь...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 17:10
	>А че вы так, собственно, бурно реагируете? Не нравится - не пользуйтесь... Ага, круто.Сначала у юзеров #@нутся данные а потом - они и не будут использовать.Рассказывая всем вокруг какое г эта система: сама дохнет на ровном месте.Ну не должна операционка дохнуть от ребута невовремя.Это - критчный баг и ниипет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 18:58
	операционка и не дохнет. (вернее дохнет, но не от этого) дохнут файлы. и то только те, которые использовались вот так (если не сказать грубее): >Ted пообещал выпустить патч, изменяющий поведение отложенной записи в ext4 при фиксировании фактов обнуления или переименования файлов. Патч не успеет войти в состав ядра 2.6.29, но намечен для включения в ядро 2.6.30. и в принципе логично. если я пишу прогу, которая читает файл, потом обнуляет его, а потом в слегка изменённом виде туже информацию записывает обратно... на не журналируемой фс эффект был бы тот же, если отрубить питание по-середине этого процесса. (в журналируемой - этот период может бытьбольше за счёт отложенности записи). ext3 справлялась за счёт ordered. (означает ли это, что в других она будет вести себя также как и ext4?) крах системы - это причина (и заслуживает отделного и не менее пристального внимания). а битые файлы - это всего лишь последствия. в новости же вроде по-русски всё описано?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 19:20
	>операционка и не дохнет. (вернее дохнет, но не от этого) Ну, с точки зрения юзера - система сыграла в ящик от слета питания.Надежность?Хаха, уровня Win95?Вот пикинь, мне срочно надо допустим что-то оплатить а у меня система не грузится.Мило, да? :) >дохнут файлы. и то только те, которые использовались вот так (если не >сказать грубее): Отлично, а какого они собственно дохнут?Это разве так и надо?И на ext3 не дохли, по крайней мере - вот так вот :) >и в принципе логично. если я пишу прогу, которая читает файл, потом >обнуляет его, а потом в слегка изменённом виде туже информацию записывает >обратно... А как еще предлагается записать такой файл если он был изменен?Допустим в начале, середине и конце файла были изменения.Допустим, размер файла поменялся.Как его еще записать то можно?Единственное что для пущей надежности можно сдвинуть его в бэкапную копию и с нуля записать новый.Но это несколько тормознее. А так - как по мне, если уж сообщили софту что файл записан - извольте натурально записать его. >на не журналируемой фс эффект был бы тот же, если отрубить питание >по-середине этого процесса. (в журналируемой - этот период может бытьбольше за >счёт отложенности записи). Ага, т.е. EXT4 будет теперь как с XFS и зануленными файлами?А то EXT3 ведь не просирал в этом случае эти файлы как я понимаю?!Хоть он и журналируемый. >ext3 справлялась за счёт ordered. (означает ли это, что в других она >будет вести себя также как и ext4?) Ну, тут собственно вопрос в том какой у ФС приоритет.Если скорость во главе угла а на целостность данных юзера положить, можно и так.А если важна сохранность данных то так делать не нужно.Скорость... а то ли это чего все хотят от EXTов?Быстрые но не столь надежные и заботящиеся о целостности данных ФС есть уже много лет.Зачем нужно +1 в этом семействе?И чем EXT4 лучше чем то что уже было?А то отложенная запись и экстенты и b-деревья уж много лет как есть у других.В том же XFS и т.п..И воплей про зануленные файлы - есть :).И чинили это дофига раз, а все-равно какие-то остатки этих граблей иногда кому-то шищку на лоб ставят.Я XFSы подпираю упсой.Но блин делать это для EXTов?!?Ать-ать-ать их там всех за такое журналирование. >крах системы - это причина (и заслуживает отделного и не менее пристального >внимания). Ну, знаешь, Чубайсовская шарага надежностью не отличается.А писючное говножелезо устроено так что если питание слетело, софт об этом уже никогда не узнает и среагировать не успеет.Кроме случая когда упс есть.Это только в embedded можно задетектить начинающуюся просадку питалова и успеть слить в EEPROM все данные из RAM за счет заряда конденсаторов :P >а битые файлы - это всего лишь последствия. Это последствия.Но не "всего лишь".Shit happens, по определению.Кто-то может нечаянно ресет нажать или питание может слететь.Это не повод радостно похерить юзеру файлы. >в новости же вроде по-русски всё описано? Ага, только вот хочется чтобы система не подыхала на ровном месте от простого нажатия ресета.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:32
	>Ну, с точки зрения юзера - система сыграла в ящик от слета питания.Надежность?Хаха, уровня Win95?Вот пикинь, мне срочно надо допустим что-то оплатить а у меня система не грузится.Мило, да? :) именно. вот это и надо обсуждать. >Отлично, а какого они собственно дохнут?Это разве так и надо?И на ext3 не дохли, по крайней мере - вот так вот :) читаем внимательно новость и видим слово ordered. и что? только в этом режиме она надёжна? а чего раньше не сказали? сколько лет уж!! :-DDDDDDDDDDDDDDD дальше комментировать уж нету сил ;-) напомню, что бьюся только те файлы, которые используются раком. теперь будет патч для защиты от извращенцев... все рады. все довольны. занавес.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 19:50
	>вот это и надо обсуждать. Моя имха: если в старой ФС что-то работало без потерь данных а в новой - данные теряются, это регресс.Думаешь, мне хочется на своей шкуре проверять сколько еще разработчиков делают так же?Я и так без проверки уверен что их таких молодцов более чем дофига.И у меня нет никакого желания превращать проблемы ФС и разработчиков софта в *мои* проблемы если честно :).Я понимаю желание разработчиков достичь скорости, но от EXTов имхо скорость нужна далеко не в первую очередь.И покуда меня будут ждать такие грабли - мне проще будет юзать для системного раздела EXT3 чтобы не получить в один "прекрасный" день слетевшие настройки всего и вся или еще какой просер данных в тот момент когда это меньше всего было нужно. >напомню, что бьюся только те файлы, которые используются раком. Так ты предложи другую вменяемую технологию записи измененного в несколких местах файла у которого поменялся размер приложением, если уж хочешь блеснуть сообразительностью?Я что-то предложений не вижу ;).А то с програмерской не вижу как эстетично записать такой файл.Единственное что сделать самопальный механизм с переимменовкой файла в .bak или подобный и запись с нуля измененного файла (в случае проблем можно откатиться на старый) но это по сути "журналирование" на уровне приложений уже получается.Несколько изврат :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 19:56
	>Единственное что сделать самопальный механизм с переимменовкой файла в >.bak или подобный и запись с нуля измененного файла (в случае >проблем можно откатиться на старый) но это по сути "журналирование" на >уровне приложений уже получается.Несколько изврат :) Эм... Это не журналирование на уровне приложений, это правильный метод работы. Вот допустим вы удалили старый файл и начали писать новый. А после того, как вы файл удалили — неожиданно кто-то еще записал на диск и место кончилось, после чего писать на диск некуда и новый файл записать не получается, а вот старый уже удалён. Беда?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от . on 12-Мрт-09, 20:21
	это неправильный метод работы. для приложения запись файла можно считать почти атомарным действием. а всеми там проблемами версионности, теневых копий, резервирования, контроля целостности и прочая должна заниматься грамотно тюнингованная файловая система. для приложения подобные операции обязны быть прозрачными. иначе нафиг такую фс, которая бьет файло с кешированием, или нафиг такое кеширование, которое добавляет проблем больше чем решает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 20:23
	>это неправильный метод работы. >для приложения запись файла можно считать почти атомарным действием. а всеми там >проблемами версионности, теневых копий, резервирования, контроля целостности и прочая должна заниматься >грамотно тюнингованная файловая система. Эмм... Ну а как вы предлагаете решать ту самую задачу с нехваткой диска? А ведь несколько лет назад в mcedit(?) был такой баг "при нехватке диска mcedit удаляет файл при сохранении не сохраняя новый".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 20:57
	>Эмм... Ну а как вы предлагаете решать ту самую задачу с нехваткой >диска? По нормальному - проверив сколько места на ФС есть _до_ начала записи файла.Если места меньше чем нужно - можно просто обматериться.Вообще ничего и никуда не записывая.Нет, разумеется, если в поле лежат грабли, есть два подхода.Первый - увидев что грабли, убрать их наф и поругаться на то что какой-то дурак их кинул.Второй - просто попрыгать и получив по лбу убедиться что это, натурально, грабли.Вы предлагаете всем выбирать второй метод.Круто! :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 21:12
	>По нормальному - проверив сколько места на ФС есть _до_ начала записи >файла. Да, с точки зрения пользовательского интерфейса, не писать, если нет места - чудесное дополнение... но это не решит проблему полностью - вы не можете атомарно проверить-и-записать. Вам знакомо понятие атомарности? >Второй - просто попрыгать и получив по лбу убедиться что это, натурально, грабли. >Вы предлагаете всем выбирать второй метод.Круто! :) Вот скажите, вы - тролль, не компетентны или попросту передергиваете? И еще - данное обсуждение про методы записи обновленных файлов не имеет ничего общего с топиком - в комментариях разработчика (по ссылке выше) к багу об этом довольно прямо сказано.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 21:54
	>чудесное дополнение... но это не решит проблему полностью - вы не >можете атомарно проверить-и-записать. Все так, но вероятность нарваться на эту ситуацию очень мала.К тому же можно проверять наличие места с достаточным запасом, как раз "на случай чего" :).Правда это тоже до некоторой степени воркэраунд, но это воркэраунд лишь того факта что система - многозадачна и срать на диск можем не только мы но и одновременно другие процессы тоже и фиг его там знает что они там сделают за это время :). >Вам знакомо понятие атомарности? Конечно :).И вы в этом правы, правда это ну очень уж экзотичный граничный случай, вероятность наступить на который мала.Но все-таки есть, да.Об этом я не подумал.Можно заворкэраундить проверяя место с запасом, можно даже запас выбрать так что практически гарантирован успех даже при пессимистичном случае - диск активно загаживается еще кем-то, но это как-то совсем уж костыльненько и настолько заморачиваются разве что программы установки да и то не все. >Вот скажите, вы - тролль, не компетентны или попросту передергиваете? На самом деле - я просто склонен сегодня к туплению и стебу т.к. злой и невыспавшийся, так что видимо последнее.Постараюсь вести себя покультурнее и думать побольше, извините. >И еще - данное обсуждение про методы записи обновленных файлов не имеет >ничего общего с топиком Хотите сказать что про файлы народ не читающий ссылок вообще развел миф?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 22:12
	>Хотите сказать что про файлы народ не читающий ссылок вообще развел миф? Аккуратно и вдумчиво прочел баг и ответ Теодора. Я, конечно, извиняюсь но вот такое в его ответе: =============== Instead, the answer is to use a proper small database like sqllite for application registries =============== Мне не понравилось.А ему не кажется что это - то чем должна заниматься его ФС?Или нахрена она вообще нужна?Записи в БД - то же самое что файлы в ФС.Типа, если не можем сделать нормально в ФС, городите оверлейную "фс" и трахайтесь с проблемой сами?Как-то неспортивно это... :).И вообще, жертвовать надежностью ради скорости для EXTов явно плохой выбор.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 22:25
	>Я, конечно, извиняюсь но вот такое в его ответе: >>>Instead, the answer is to use a proper small database like sqllite >>>for application registries >Мне не понравилось.А ему не кажется что это - то чем должна >заниматься его ФС?Или нахрена она вообще нужна? Во-первых, config != registry. Во-вторых, БД отличается от ФС задачами довольно сильно. Например, насколько я знаю, все ФС (в отличие от БД) довольно плохо работают с кучей мелких записей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 22:42
	>Во-первых, config != registry. +100 на время жизни программы (приложение запущенное на выполнение) это величина постоянная. и только внешним сигналом можно заставить перечитать его. иначе это не конфиг. и тогда его нельзя править во время выполнения проги..... а это не только не *никс вей - это маразм.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 22:56
	> Во-первых, config != registry. Что вы этим хотели сказать?Я хотел сказать что сбагривать проблему с похериванием файлов на сторонние базы - хреновая практика.То есть база может и спасет, но весь софт никогда не будет юзать базы.А значит данные будут просираться в таких вот сценариях.И кайфа юзерам это не добавит - мнение о надежности ОС и ФС будет такое какое в общем то и должно быть о таких фортелях.Со стороны выглядит примерно так: мы не осилили сделать надежную ФС поэтому пусть с вопросами надежности мудохаются другие.Скажем sqlite или кто там еще. В моем понимании, если аппа закрыла файл - его надо выдавить на диск, ибо нефиг.Крохоборство с меньшей фрагментацией и темпами в оперативе с отложенной записью в этом случае себе дороже выходит при внезапном ребуте.Как максимум - можно оставить такой режим для камикадзов которым на целостность данных насрать а вот скорость позарез нужна даже ценой целостности данных.Но - ессно не дефолтным а включаемым явно отдельной опцией.На эту тему помнится XFS допилили юзать барьеры чтобы данные регулярно сливались раз в сколько-то секунд несмотря ни на что.Да, это поднасрет аллокатору но в конечном итоге XFS и так показывает весьма непозорные результаты.И по фрагментации и по скорости.Ну и нефиг, соответственно с супер-агрессивным кешированием выпендриваться.Потому что когда все что в этом кеше похерится при ребуте - будет здорово, ага.А за 150 секунд данных записать можно о-го-го. >Во-вторых, БД отличается от ФС задачами довольно сильно. В конечном итоге - они занимаются одним и тем же.Файлы можно рассмотреть как очень специфичные записи в очень специфичной БД затюненой под специфичные задачи.А некоторые БД умеют жить на raw разделах, являясь сами себе файловой системой по сути :).Так что на самом деле - а где та грань? ;) >Например, насколько я знаю, все ФС Допустим что не все.Тот же рейзер не так уж и плох на мелочи, насколько знаю я.Да и все современные ФС юзают индексирование каталогов в b-дереве, применяют ряд оптимизаций (например засовывая мелочь прямо к метаданным о ней).Так что не так уж они и плохи с мелочью зачастую.Другое дело что ФС - это что-то типа базы (key, value) при том key'ем выступает путь и имя файла а value - сами данные.Тот индекс который по key - он довольно неплохо шпарит в современных ФС за счет b-деревьев и т.п. :-).Понятно что "тюнинг" разный, но все-таки по сути 2 инкарнации одной вещи под сильно разным соусом. >(в отличие от БД) довольно плохо работают с кучей >мелких записей. А дядька Рейзер помнится в свое время говорил что "если вам нужен лишний слой БД - у вас просто используется дерьмовая ФС".И некоторый смысл в этой заяве есть - ФС здорово смахивают на типичную базу key-value :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	99. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 13-Мрт-09, 06:44
	>> Во-первых, config != registry. > >Что вы этим хотели сказать? ... >В моем понимании, если аппа закрыла файл - его надо выдавить на >диск, ибо нефиг.Крохоборство с меньшей фрагментацией и темпами в оперативе с >отложенной записью в этом случае себе дороже выходит при внезапном ребуте. Только то, что конфиг — ведь постоянная, а база — изменчивая. Люди из sqlite проделали неплохую работу по созданию устойчивой к крахам питания библиотеки, повторять весь тот код в ядре.... Ну, можно. Например, монтируйте FS с опцией sync и будет вам счастье :-) >>Во-вторых, БД отличается от ФС задачами довольно сильно. > >Так что на самом деле - а где та грань? ;) Количественная эта грань и не говорите, что размер не имеет значения. Я бы её провёл по размеру блока ФС и размеру соответствующей записи БД.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	111. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 15:23
	>>В моем понимании, если аппа закрыла файл - его надо выдавить на >>диск, ибо нефиг [...] >Только то, что конфиг — ведь постоянная, а база — изменчивая. Есть конфиги которые часто меняются.И есть неизменчивые базы.Скажем CDB - вообще создан для read-only баз.Кроме того ФС хранит не только конфиги, isn't it? И фс в целом - довольно изменчивая штука.Не хуже любых баз. >Люди из sqlite проделали неплохую работу по созданию устойчивой к крахам питания >библиотеки, повторять весь тот код в ядре.... Простите, они просто сделали нормальные логи и транзакции.Самие обычные, так как это и должно быть.При том - как и положено, несколько тормозные.Повторять код в ядре?Не развалятся, ФС должна быть реализована без халтуры.Все програмеры никогда не станут юзать левую стороннюю библу во всех прогах а некоторым именно SQL к тому же плохо подойдет под их задачи и даст лишние тормоза и оверхед - отсюда не следует что их файлы надо херить.А при безбашенном использовании - sqlite еще и тормозить умеет.Это сиквель, со всеми вытекающими.Тормознуть его безбашенно сделанной кверей да еще без правильных индексов - не вопрос ни разу.Примеры?! Ну вон Maemo Mapper 2.6.1 @ Nokia n800. Там как бэкенд кеша карт ранее юзался GDBM а теперь еще и sqlite прикрутили.Так вот sqlite на данный момент *намного* тормознее GDBM-а.Это вот програмер его поюзал.Просто не грея мозг особо оптимизацией его работы.И вот так оно будет в 90% мест куда его воткнут.Да, его можно затюнить.Но 90% програмеров этим морочаться не будут.И получится еще одна виндусь виста, которой 2-ядерника мало для шустрой работы.Нафиг нужно.Пусть лучше ядерщики нормальную файловую систему сделают которой не требуются костыли и подпорки по дефолту, чем все остальные трахаются с воркэраундами для сыпучей ФС. >Ну, можно. Например, монтируйте FS с опцией sync и будет вам счастье :-) Счастье?Это в виде обуительных тормозов?Сомнительное счастье.Я таким макаром могу ФС вообще без журнала юзать.Правда работать будет М-Е-Д-Л-Е-Н-Н-О.А нафиг тогда вообще журнал? :) >Количественная эта грань и не говорите, что размер не имеет значения. Я >бы её провёл по размеру блока ФС и размеру соответствующей записи >БД. Эээ а как вы ее проводить собрались?Полно народа хранит в БД блобы (обычные файлы зачастую), равно как и в ФС нередко хранят мелкие файлы.Тот же sqlite вообще даже не требует чтобы запись умещалась в памяти.А размеры самой бд бывают терабайтные.Блок?Что для БД блок?Страницы?Ну их размер бывает похожий на блок ФС.У фс бывает пакинг мелочи.И ... что? Как пример: Maemo Mapper раньше юзал для кэша карт напрямую ФС.В принципе работало но фат32 на картах памяти отрицательно относился к большому числу файлов (не очень то и мелких в принципе, тайлы карт).Засунули в GDBM, дерьмовой ФС эпохи 80-х полегчало.Ессно - работу которую говноФС делала хромая на обе ноги спихнули на более вменяемо (чем ФАТ) сделанную базу.Ессно говнецу полегчало.А если нормальную ФС на карту засунуть, хотя-бы ext3 с индексированием дир, разницы особо не будет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 22:17
	>Все так, но вероятность нарваться на эту ситуацию очень мала. Конечно, вероятность аппаратного сбоя и повреждения структур ФС тоже невелика. Кстати, если верить теории вероятности, даже событие с нулевой вероятностью не является невозможным. >>Вам знакомо понятие атомарности? > >Конечно :).И вы в этом правы, правда это ну очень уж экзотичный >граничный случай, вероятность наступить на который мала. Гмгм... Ну я наступал, правда, там не диск был переполнен а квота исчерпана - но это почти одно и то же. >>И еще - данное обсуждение про методы записи обновленных файлов не имеет >>ничего общего с топиком > >Хотите сказать что про файлы народ не читающий ссылок вообще развел миф? Отчасти. Как я понял, кривизна прог была не столько в способе работы с файлами (read/truncate/write vs. read/mktemp/write/rename) а в том, что файлы обновлялись без необходимости. Зачем же конфиги перезаписывать при старте, если опции не менялись? По-моему незачем и вполне логично программу, так делающую, назвать в меру кривой. Почитав ответ разработчика ФС на обсуждаемый баг я именно такой вывод и сделал.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 22:34
	блин! ребята! речь не о методах обновления файлов! эта херь почему-то встречается исключительно с конфигами! особенно в последнее время. ну согласитесь, врядли oo перед записью изменений стирает старое (на 30 мб), а потом пишет новое... и так со всеми... даже с гимпом.... амарок с чем работает? про xml-конфиги - вообще отдельный разговор... а ведь есть ещё и блокировки, seak, дублирование дескрипторов,... и аля sqlite наконец (и не надо говорить, что это глупо для конфига в 30 mb. вот как раз глупо держать его в flat файле)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:09
	>Конечно, вероятность аппаратного сбоя и повреждения структур ФС тоже невелика. Кстати, >если верить теории вероятности, даже событие с нулевой вероятностью не является >невозможным. Да.Например, есть вероятность что все молекулы воздуха резко улетят в другую комнату и она - НЕ НОЛЬ.Желающие могут уже драпать закупать скафандры если хотят, потому что оказаться в вакууме - не рулит :) >Гмгм... Ну я наступал, правда, там не диск был переполнен а квота >исчерпана - но это почти одно и то же. Удивительно имхо.Но мало ли чего бывает.Наверное и такое тоже. >>Хотите сказать что про файлы народ не читающий ссылок вообще развел миф? >Отчасти. Как я понял, кривизна прог была не столько в способе работы >с файлами (read/truncate/write vs. read/mktemp/write/rename) а в том, >что файлы обновлялись без необходимости. Нет, я все понимаю, что это плохо.Но это не значит что ФС из семейства EXTов имеет право быть ненадежной по дефолту.Особенно когда 3-я версия зарекомендовала себя достаточно позитивно в этом плане и требования юзеров уже никогда не упадут ниже (кроме специальных случаев когда важна скорость любой ценой). >Зачем же конфиги перезаписывать при старте, если опции не менялись? По-моему незачем >и вполне логично программу, так делающую, назвать в меру кривой. Да.Это - верно.Но вот если автор ФС заявляет что для надежности надо юзать добавочный слой типа sqlite'а - простите, но мне не понятно: а какого надежность должен обеспечивать костыль а не сама ФС?Ради скорости?Такой ценой?Спасибо, ага.А чем это лучше XFS?Который хорош по скорости но по надежности - лично я ему доверяю сильно меньше чем EXT3. >Почитав ответ разработчика ФС на обсуждаемый баг я именно такой вывод и >сделал. Я сделал еще один вывод - он технично попытался спихнуть проблемную область на других, e.g. sqlite и прочих.Почему ФС этим не должна заниматься - я честно гря не понял.Странный подход к вопросу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 23:17
	>Но это не значит что ФС из семейства EXTов имеет право быть ненадежной по дефолту.Особенно когда 3-я версия зарекомендовала себя достаточно позитивно ну наедь на бздишников с софтапдейтом.... вон, ниже тусуются. > он технично попытался спихнуть проблемную область на других, e.g. sqlite и прочих.Почему ФС этим не должна заниматься - я честно гря не понял.Странный подход к вопросу. не правда. патч то будет.... и решать эти вопросы будут... но разработчикам (и не мелких программ) звездюлей дать надо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Tim (??) on 12-Мрт-09, 21:50
	>>Эмм... Ну а как вы предлагаете решать ту самую задачу с нехваткой >>диска? >По нормальному - проверив сколько места на ФС есть _до_ начала записи файла. Это работает _только_ в однозадачной системе. Hint: свободное место _до_, _вовремя_ и _после_ записи файла не зависит от размера файла. Различные процесы могут "одновременно" удалять и/или записывать другие файлы. >увидев что грабли, убрать их наф и поругаться на то что... ругаться нужно _до_ того, как убиты данные однозначно. Классическая последовательность 1) backup 2) create, write имеет свои проблемы. Например в п.2 вероятность сбоя потенциально выше, следовательно выше вероятность восстановления из bak файла. IMHO надежная последовательность перезаписи: 1) запись в "file.temp" с проверкой при закрытии файла. 2) переименование "file" в "file.bak" 3) переименование "file.temp" в "file" PS. Для "почти атомарной записи" ФС должна корректно реализовать функцию синхронизации ala fflush, а разработчик реализовать (не менее корректно) проверку всех возвращаемых значений
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от const86 (ok) on 12-Мрт-09, 22:48
	>Для "почти атомарной записи" ФС должна корректно реализовать функцию синхронизации ala fflush fsync Вот я делаю creat("file.tmp"); write; fsync; close; rename("file.tmp", "file"); - и если после успешного завершения всего этого содержимое file может потеряться при сбое, то это проблема ФС. В остальных случаях не надо валить с больной головы на здоровую, тем более что в манах чётко написано, что write ничего не гарантирует, как и close.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 22:52
	точно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	141. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Volodymyr Lisivka on 14-Мрт-09, 02:10
	>>Для "почти атомарной записи" ФС должна корректно реализовать функцию синхронизации ala fflush > >fsync > >Вот я делаю creat("file.tmp"); write; fsync; close; rename("file.tmp", "file"); - и если >после успешного завершения всего этого содержимое file может потеряться при сбое, >то это проблема ФС. В остальных случаях не надо валить с >больной головы на здоровую, тем более что в манах чётко написано, >что write ничего не гарантирует, как и close. POSIX позволяет пустую реализацию fsync(). Пример: MacOSX. Если у вас SSD или ноут или смартфон, то в ваших интересах не позволять приложениям дёргать fsync() попусту чтобы не палить флешку или разряжать батарею впустую.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	152. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 16-Мрт-09, 19:19
	>POSIX позволяет пустую реализацию fsync(). Пример: MacOSX. Я сердечно поздравляю юзеров макоси с этим фактом.Не думаю что он их напрягает.Если уж им не в облом покупать втридорога только "одобренное свыше" железо (освященное богами, мля), не смущает DRM и ограничилово - то уж на целостность данных таким юзерам и вовсе насрать.Свое гей-порно они заново перекачают из интернета а ничего ценней там у них все-равно нету. >Если у вас SSD или ноут или смартфон, то в ваших интересах >не позволять приложениям дёргать fsync() попусту чтобы не палить флешку или >разряжать батарею впустую. А вы представляете себе слет конфигов на смарте вообще?Юзер не просто кардинально влопается и будет зол, сделав антирекламу.Он потащится в сервис и принесет вагон убытков. Более того - в смартах флеш прицеплен напрямую к процу и ФС обязана сама озаботиться его wear leveling'ом, иначе он очень быстро протрется в некоторых областях.Для этого сделаны специальные ФС и уровни трансляции.Они стараются выравнивать операции на erase block, используют свойства физики флеша и так далее.Как пример - JFFS2, UBIFS и прочие.Они и журналят с поправкой на природу носителя. Никому в здравом уме не приходит в голову юзать обычную ФС в смартфоне.И это правильно.Почему - см.выше. А SSD - простите у него свой контроллер который wear leveling'ом занимается и софту и ОС строго говоря не видно во что по факту трансформируется тот или иной системный вызов.В принципе delayed allocation может подыграть но - в основном при очень специальной организации, когда записи пытаются выравняться на границы erase block-ов.Только учтя что в SSD реальная геометрия флеша скрыта его контроллером, драйвера ФС и ОС могут только гадать, попало ли выравнивание в цель или нет.В общем то если такое инфо не скрывать, драйвера ФС могли бы осмысленнее тюнить свое поведение под геометрию накопителя.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:14
	>Это работает _только_ в однозадачной системе. Так точно - darkk уже указал мне на этот ляп.И вы добавить хотите?Признаю недосмотр, уели, да :) >Различные процесы могут "одновременно" удалять и/или записывать другие файлы. Так точно. >ругаться нужно _до_ того, как убиты данные однозначно. Согласен.И последовательности - не так уж плохо.Но и тормознее соответственно. В общем я кажется понимаю в чем прикол: ни автор ФС ни авторы приложений не хотят трахаться с обеспечением надежности и пытаются перепихать друг на друга этот вопрос :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 20:03
	>Моя имха: если в старой ФС что-то работало без потерь данных а в новой - данные теряются, это регресс.Думаешь, мне хочется на своей шкуре проверять сколько еще разработчиков делают так же? а ведь придется! :-DDDDDDDDDDDDDDDDDDDDDd да и удивляться не чему. чем сложнее система, тем больше её надо отлаживать. >Я понимаю желание разработчиков достичь скорости, но от EXTов имхо скорость нужна далеко не в первую очередь. и они её давали. я всегда так и писал. и судя по новости - будут и дальше. в ванилле обещают патч к 30. в убунте скорее всего бекпартируют. так что всё отлично. но звездюлей коре писателям из кде, гнома и т.д. дать надо бы... этож прописные истины! >Так ты предложи другую вменяемую технологию записи измененного в несколких местах файла у которого поменялся размер приложением, если уж хочешь блеснуть сообразительностью? read/write /rename - практически стандарт ещё со времён, когда о журналах и не думали. терять конфиги всегда было "не модно". :-) почему-то вспоминается сразу syslogd. :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 21:22
	>а ведь придется! :-DDDDDDDDDDDDDDDDDDDDDd (вертя перед монитором фигой) это вы сами как-нить, без меня.А я лучше ext3 поюзаю пока.Захрен мне прыгать по любезно разложенным граблям если я уже в курсе что они вон там есть?Более того, я круто сомневаюсь что из-за одного Теодора оравы разработчиков резко проникнутся идеей переписать всю работу с файлами в квадриллионах программ и построившись в два ряда побегут стройными колоннами переписывать свой софт.Никто этого делать не будет.Ну а крайними окажутся как всегда юзеры.Тупой подход к вопросу.Ни к чему кроме геморроя и потерь данных у юзеров такой подход не приведет. >да и удивляться не чему. чем сложнее система, тем больше её надо >отлаживать. Это да.Но сдается мне что в отладке на "ноутах разработчиков" есть жирный минус :).Ноут - это по сути комп с упсой.А это извините читерство.Кто так не считает - может подогнать пару самосвалов UPSов в близлежащие дома и офисы, ессно за свой счет что поспособствует выправлению мнения о данном вопросе :) >в ванилле обещают патч к 30. ... а убунту обещают только 29 ядро.Итого жесткие даты релизов опять играют дурную шутку.Нате вам дескать систему со встроенным шреддером для ваших данных.Это мило, ага =) >в убунте скорее всего бекпартируют. так что всё отлично. Кроме того что в результате будет много воплей про убитые данные. >но звездюлей коре писателям из кде, гнома и т.д. дать надо бы... Боюсь, звиздюлей придется давать этак процентам так 90 всех программеров.Нереально.Пусть Теодор свою ФС все-таки делает в рассчете на имеющиеся реалии а не на то как в теории должны по его мнению делать програмеры, а?Или пусть строит самолично всех этих програмеров если не боится что строилка сломается.Иначе юзать его ФС будет "немного" так геморройно и чревато. >read/write /rename - практически стандарт ещё со времён, когда о журналах и >не думали. Конечно.Без журнала то никто попу программы не прикроет в случае чего.Вот и делали такое псевдожурналирование по сельски.По сути rename -> запись нового файла чем-то напоминает идею журналирования.Наверное ближе всего к этакому своеобразному варианту CoW-журналироваия :).Вот только не понятно почему програмеры апликух должны заморачиваться с этими наворотами.Они этого делать не будут. >терять конфиги всегда было "не модно". :-) На серверах такой проблемы нет - сие не модно. Кстати MS хаят за их реестр но тем не менее, это таки БД подпертая дополнительно своим собственным журналом транзакций - наверное как раз чтобы не требовать делать журналинг от программеров при желании сохранить конфигурацию...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	129. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Filosof on 13-Мрт-09, 17:50
	>А то с програмерской не вижу как эстетично >записать такой файл.Единственное что сделать самопальный механизм с переимменовкой файла в >.bak или подобный и запись с нуля измененного файла (в случае >проблем можно откатиться на старый) но это по сути "журналирование" на >уровне приложений уже получается.Несколько изврат :) этим всякие Оффисы активно занимаюьтся. потихоньку распложая свои темпы, а апосля забывая их херить. Про производительность тут вообще нечего говорить. Но нечто подобное продумано в ZFS(?) где все новое сохраняется в пустое место, а старое затирается по мере устаревания
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от yalur (ok) on 12-Мрт-09, 20:03
	>напомню, что бьюся только те файлы, которые используются раком. теперь будет патч для защиты от >извращенцев... все рады. все довольны. занавес. Ну не знаю, по ссылке чувак пишет: Also some of my MySQL databases were killed... Походу придем к тому, что все проги "используются раком". Вобщим ФС такая крутая, что все остальное - это сплошной глюк и все нада переписать заново.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от const86 (ok) on 12-Мрт-09, 22:41
	> Also some of my MySQL databases were killed... MyISAM?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 22:58
	пипец. >Also some of my MySQL databases were killed... ну и кем она килед? читайте новость... там система ПАДАЕТ! то что патч добавят + плюс... за всеми не уследишь.. но тут то фс при чём? нормальной б/д фс вообще пох.... и в этом плане MySQL нормальная.. уже пол года на ext4 юзаю в тестовом режиме.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:21
	>читайте новость... там система ПАДАЕТ! Ну вот журналы и транзакции изначально и были нужны чтобы это не создавало проблем.Или доводится до логичного финала целиком или нафиг откатывается в вид как было.Почему-то люди так и норовят забыть эту простую истину.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	112. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 15:33
	после транзакции всегда идёт commit или rollback. здесь же нет ни начала тразакции, ни сэйвпоинт (будущий патч - отдалённый аналог), ни коммитов с ролбеками... поэтому либо ПО следит за своей "транзакцией" сама, либо не обижается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	114. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 15:51
	>здесь же нет ни начала тразакции, ни сэйвпоинт (будущий патч - отдалённый >аналог), ни коммитов с ролбеками... Да, я и не спорил - большей части ФС глубоко положить на состояние файла после краха.Они пекутся только о корректности метаданных.При том понятие корректности определено очень вольно - дескать непротиворечивое состояние ну и хватит с нас. Я для себя считаю что приведение файла в какое-то вменяемое состояние - это тоже часть вопроса о корректности метаданных. На мое имхо в идеале должно быть просрано лишь то что не успело физически слиться из кеша на диск и не более того а слив должен происходить при первой возможности, а уж close файла == форсирование слива этого файла на диск ASAP.А не держание его в кеше 150 секунд в надежде что он прое..тся.Выигрыш окажется небольшой (ext3 и так по части фрагментации не особо проблемный) а вот сколько при удобном случае просрется файлов при записи всякой мелочи за 150 секунд кеширование - понятно и дебилу.За 150 секунд много навалить можно.И все это отправится в случае краха в /dev/null.Как-то стремно такие ФС юзать - всех програмеров не построишь а просирать столько данных как-то не с руки. >поэтому либо ПО следит за своей "транзакцией" сама, либо не обижается. Если с одной ФС все работает а с другой сыпется ко всем чертям, затрудняюсь назвать это плюсом ФС.Как ни крути.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	117. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 16:03
	на самом деле важно не это. важный вопрос, как всегда за кадром.. (по теме - почему падает система? и насколько будет рабочим релиз? 9.04 - лонглайф и его многие ждут. в чем то он даже революционен.... в конце концов никто не заставляет использовать ext4, а вот релиз - на носу) и второе. механизм, подобный транзакциям, но который не заставил бы переписывать все проги, не придуман. фс откатывает, фигурально говоря, на последнюю контрольную точку... если в этот момент файл был нулевым, то так тому и быть.... до патча.... но патч не изменит кардинально положение вещей. если придумаете как, то... я скажу спасибо! :-) >Если с одной ФС все работает а с другой сыпется ко всем чертям, затрудняюсь назвать это плюсом ФС.Как ни крути. все это обязано всего-лишь установкам по-умолчанию "data=ordered"? ну это даже уже не смешно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от анонимус on 12-Мрт-09, 19:20
	>и в принципе логично. если я пишу прогу, которая читает файл, потом >обнуляет его, а потом в слегка изменённом виде туже информацию записывает >обратно... >на не журналируемой фс эффект был бы тот же, если отрубить питание >по-середине этого процесса. (в журналируемой - этот период может бытьбольше за >счёт отложенности записи). Что за дурь, твое приложение передало в ОС данные для записи в файл с помощью вызова 'write' и упало после этого. Это не значит что данные при этом должны потеряться. После успешного завершения вызова 'write' ОС берет на себя все обязательства о сохранности этих данных, что оно сними будет делать (журналировать, буферизировать и т.п.) это нас не волнует, пусть хот мы трижды после этого упали или зависли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:25
	ещё раз повторяю: падает не приложение, а система... она же ОС... тот же эффект при выключении питания. что ещё не понятно? новость вообще хоть кто-нибудь читает? про хождение по ссылкам я уже не говорю.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:23
	>ещё раз повторяю: >падает не приложение, а система... она же ОС... тот же эффект при >выключении питания. Отлично.А почему при этом должно что-то хериться?Изначально журналы и транзакции как раз и были придуманы чтобы внезапные проблемы не приводили к потерям данных.Или доводится до победного финала или откатывается в вид как было.И это то чего всем и хочется.Правда вот платить скоростью за это никто не любит :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 13-Мрт-09, 06:41
	>Изначально журналы и транзакции как раз >и были придуманы чтобы внезапные проблемы не приводили к потерям данных.Или >доводится до победного финала или откатывается в вид как было. А был момент, когда файл был нулевого размера и данных в нём не было? Если был — можно ведь и на него откатиться ;-) Вообще, как понимаю, в ext3 та же самая ситуация с потерей данных происходить может при data=writeback, так что проблема не в самой ФС а в значениях по-умолчанию.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	116. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 15:58
	>А был момент, когда файл был нулевого размера и данных в нём >не было? Если был — можно ведь и на него откатиться ;-) Все так, но было бы логично если бы ФС не особо торопилась с коммитом именно таких изменений, зато если в файл что-то записали и ЗАКРЫЛИ его - старалась бы как можно быстрее закоммитить файл работа с которым завершена на диск.И держать его еще 150 секунд в кеше пардон конкретный идиотизм.Парни перепутали рамдиск с дисковой ФС.Если мне надо будет рамдиск в темпе - я его ей-богу и без них сделаю.Зная что на него нельзя полагаться при слетах питания.А вот на дисковую ФС хочется все-таки полагаться в плане сохранности данных. >Вообще, как понимаю, в ext3 та же самая ситуация с потерей данных >происходить может при data=writeback, так что проблема не в самой ФС >а в значениях по-умолчанию. Ну вот и пусть сделают режим "для истинных камикадзе" в ext4.С повышенной скоростью и все такое.А по дефолту такое паскудное поведение ФС нефиг подсовывать :-\.Это все-таки не XFS который обычно выбирают умные люди знающие чего хотят получить осмысленно.Это кандидат в новую дефолтную ФС линуха.И потому он должен быть в частности и достаточно неубиваемым по дефолту.Даже в отличных от тепличных условиях.Как ext3.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от xand on 12-Мрт-09, 18:31
	Разве кто сказал, что виноваты пользователи? Внимательней нужно читать. Если не помогает - несколько раз... Вина была возложена на разработчиков "падающего" софта.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Проблемы с потерей данных на Ext4 разделах в тестовой версии"

Сообщение от Аноним (??) on 12-Мрт-09, 16:22

но это не повод угробить систему...

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

	17. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 17:20
	>Тут рассказывается о проблемах убунты и ее хреновых настройщиках >а сама фс делает то что и должна Знаете, ФС не должна палить в пятки юзера по дефолту.И я не думаю что убунтуйцы специально крутили опасные настройки.А то что это можно как-то там заворкэраундить в настройках (скорее всего просрав хваленый прирост производительности) - дело хренадцатое.Эксты обычно все юзают за их трудноубиваемость.Если у них просрется это достоинство - а кому и нафига они вообще нужны будут? И отмазки про приложения выглядят жидковато.Хотелось бы чтобы журнал все-таки занимался своим делом - или все(запись в файл доведена до конца), или ничего(откачено нахрен в вид как было).Переписывать файлы по поводу и без - дрянная тактика, но файловую систему теряющую данные это не оправдывает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Konstantin (??) on 12-Мрт-09, 17:46
	Это у экстов то трудноубиваемость? ) Да даже Fat и тот надежней.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 18:57
	>Это у экстов то трудноубиваемость? ) Да даже Fat и тот надежней. Да что вы говорите?У меня на FAT при слете питания однажды %#нулось несколько больших директорий, рассыпавшись по lost кластерам в свое время.Очень мило.Также был ряд случаев когда скандиск заявлял что ФС валидная но вот система считала иначе. В итоге на руках была ФС с которой не понятно что делать - половина ФС недоступна а родные утили чинить ее не собираются.А еще винда нарисовала ФЭЙКОВЫЕ бэды на абсолютно исправном диске разок.Просто в результате хитрого глюка дефрагера.И потом я их снести ничем не мог.Пришлось руками в дискэдиторе колупаться.Надежнее просто некуда.ИМХО такие эксперты как вы летят как стая напильников на http://lleo.aha.ru/na А вот EXT3 настолько убить - постараться еще надо.Крепко так постараться.На исправном железе он к разрушениям не особо склонен.Да и вообще, устроен тупо и топорно, в счет чего неплохо чинится родными утилями и т.п..У меня за несколько лет достаточно неаккуратного обращения с оным ни разу не получилось по крупному потерять данные на нем.Так что впечатления от оного довольно позитивные.В плане надежности.В плане скорости - тормоз ессно.Что при его дизайне ФС вполне предсказуемо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:08
	ну это Вы точно загнули! 2-е копии FAT (имеется ввиду File Allocation Table, а не название фс) меня пугали ещё 20 лет назад (петька нортон даже их бекап предлагал делать пере выключением в своих утелитах). и за мой опыт слетали обе нах несколько раз.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от prapor (??) on 12-Мрт-09, 16:42

Намедни поймал такое на Debian unstable+experimental. Списал на глюк KDE4.

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

	16. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 17:20
	>Списал на глюк KDE4. и правильно сделал... но базовая фс всё равно должна быть не убиваемой. может это заставит разработчиков гном и кде подправить эти сопли... тогда и на других фс будут работать и быстрее, и надёжней.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 17:29
	>и правильно сделал... А по-моему не очень.Понижение надежности работы ФС приветствовать имхо нельзя.В ext3 ведь этой проблемы не было. >но базовая фс всё равно должна быть не убиваемой. Вот именно.И никакие кеды, сандалии, гномы и прочие тут не при чем. >может это заставит разработчиков гном и кде подправить эти сопли... Это было бы позитивно в плане времени жизни SSD дисков например.Но с другой стороны - спасибо им за сопли.Позволили получить граблями быстро.А иначе эти грабли бы тихонько лежали еще фиг знает сколько и ждали бы своего часа. > тогда и на других фс будут работать и быстрее, и надёжней. Но не будут помогать вычислить ненадежные ФС :) Как раз спасибо что тут разрушение файлов заметно.А херились бы другие файлы - вы бы это заметили только когда у вас уже куча файлов побилась.Гм.Это типа, лучше, когда вам поднасирают втихарика? oO
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 18:40
	т.е. пишите глюкавые программы! это позволяет отслеживать ошибки в фс и не только! :-D это хорошо, что в понедельник тестирование беты убунту провели. и видимо хорошо, что много желающих откликнулось... а так сидели бы с релизом... и битой фс. резюмирую. тестирование должно носить системный характер. для системных вещей уж точно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 19:23
	>резюмирую. тестирование должно носить системный характер. для системных вещей уж точно. Как по мне так убунтуйцам надо спасибо сказать за ранний отлов грабель.Данный трабл может привести к тому что файлы будут втихаря засираться при рестартах а юзер об этом узнает только когда засрется столько файлов что это зацепит что-то нужное юзеру.А тогда обычно уже поздно пить боржоми...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:35
	>Как по мне так убунтуйцам надо спасибо сказать за ранний отлов грабель. именно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:39
	>Данный трабл может привести к тому что файлы будут втихаря засираться при рестартах а юзер об этом узнает только когда засрется столько файлов что это зацепит что-то нужное юзеру это происходит только если есть прога, которая работает с ними через анальное отверстие. бьются не все подряд файлы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 19:56
	>это происходит только если есть прога, которая работает с ними через анальное >отверстие. Боюсь что если такая ФС пойдет в массы - мы узнаем много нового о привычном софте и его методах работы с файлами.Ты именно этого хочешь, да?Сидеть и чесать репу какого черта там-то и там-то просралось вон то и вон это?Я что-то сомневаюсь что юзеров сильно утешит осознание факта что их любимые программы оказывается неидеально работают с файлами :).Раньше то данные не просирались... ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 23:03
	ну я и так о нём не мало знаю... одно кде чего стоит. вот и палинух своему другу не отвечает... с nvidia тоже траблов дохера... интел вот никак всё вместе собрать не могут (в одном дистре одно глючит, в другом другое)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	91. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:30
	>ну я и так о нём не мало знаю... одно кде чего стоит. Но стоит себе на EXT3 в 8.10 и почему-то ничего не сыпется... :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от prapor (??) on 13-Мрт-09, 02:24
	>>ну я и так о нём не мало знаю... одно кде чего стоит. > >Но стоит себе на EXT3 в 8.10 и почему-то ничего не сыпется... >:-) Вот, собственно, +1 :) Думал на десктопе /home перевести, но теперь передумал...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	119. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 16:11
	>Вот, собственно, +1 :) Думал на десктопе /home перевести, но теперь передумал... И наверное правильно сделал.Потому что иначе рискуешь узнать много нового о пряморукости большинства программистов.И я сомневаюсь что сюрпризы будут приятными.Скорее, будет слет настроек софта при каждом удобном случае(большинство програмеров привыкнув к неприхотливости ext'ов плевать хотели на позиксы и что там еще с высокой колокольни).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от terminus (ok) on 12-Мрт-09, 16:45

Release early, release often?

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

10. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от XoRe (ok) on 12-Мрт-09, 16:48

Имхо, это больше кирпич в огороды Ubuntu, Gnome и KDE, чем в огород ext4. Во первых, в ext4 отложенное распределение (delayed allocation) можно и отключить. Во вторых, такой способ оптимизации (delayed allocation) есть не только в ext4. В третьих, "крах системы" - это не нормальное состояние. Это все равно что сказать: все современные ОС ненадежны - если тыкать в кнопку RESET в случаном порядке, есть шанс потерять данные. Вообще обнуление файлов при перезаписи, связанное с отложенно записью - это не такая уж новость. Это вполне логичное следствие возможных последствий отложенной записи (когда возникает сбой или когда компьютер резко выключается/перезагружается). И это вполне может лечиться на уровне приложения. Например, можно открывать файл для записи как раз перед записью. А не так, что fopen(...), подумали, посчитали, вычислили, что будем писать, потом printf, потом ещё подумали, потом fclose. Ещё можно указать синхронизировать данные для только что записанного файла (что-то типа sync). Может программистам KDE и Gnome стоит переделать способы работы с конфиг файлами? P.S. Я бы изменил название новости на "Проблемы с потерей данных на Ubuntu 9.04 с дефолтными настройками".

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

	22. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 18:17
	>Имхо, это больше кирпич в огороды Ubuntu, Gnome и KDE, чем в >огород ext4. Да, все пи...сы, а вот ext4 Д`Артаньян.А пардон, почему у ext3 таких граблей нет?Или теперь EXT4 будет нулить файлы как XFS? >Во первых, в ext4 отложенное распределение (delayed allocation) можно и отключить. Да-да-да, только во-первых, все привыкли к тому что EXTы прежде всего надежные и как правило не гадят изподтишка.Если это будет не так - нафига они вообще нужны?Практически все что ext4 могут предложить было уже много лет в других ФС. >Во вторых, такой способ оптимизации (delayed allocation) есть не только в ext4. Во вторых, вот я и спрашиваю - а нафиг ext4 нужен если он ни чем не лучше?XFS вон давно уже умел шустро работать с большими файлами.Но с некоторым риском профукать свежезаписанные данные.И за сие ему много доставалось от тех у кого данные просрались.И сие много и долго допиливали в ядрах начиная с древних каких-то и заканчивая чуть ли не 2.6.27 а то и новее. >В третьих, "крах системы" - это не нормальное состояние. В третьих, просер данных ФСом - это ненормальное явление.Как класс. >Это все равно что сказать: все современные ОС ненадежны - если тыкать >в кнопку RESET в случаном порядке, есть шанс потерять данные. Так это не есть правильно.В идеале - или уж дописалось в новом варианте, или уж роллбэк к старому варианту.Иначе нафиг вообще журнал нужен, по большому счету? >Вообще обнуление файлов при перезаписи, связанное с отложенно записью - это не >такая уж новость. Это не новость.Это известное пи...ство разработчиков ФС. >Это вполне логичное следствие возможных последствий отложенной записи >(когда возникает сбой или когда компьютер резко выключается/перезагружается). Ну да, конечно, а нахрен тогда по большому счету журнал?Для юзера его данные ценнее метаданных ФС.Так что можно и без журнала вообще.Положить на ребут да и все.Если уж на данные насрать - на метаданные ФС и вовсе можно положить с прибором :) >И это вполне может лечиться на уровне приложения. А еще можно гланды, через жопу, автогеном.В смысле, создать raw партицию без ФС и запрячь приложени выполнять всю логику ФС самостоятельно.Некоторые СУБД так и делают, но нельзя требовать от всех приложений стать такими же монстрилами как эти СУБД :) >printf, потом ещё подумали, потом fclose. Все так, НО это не извиняет просирона данных ФСом.Простите, чуваки, XFS умел с просироном данных быстро работать уже сколько там лет.И экстенты у него есть.И b-деревья для индексирования.Наф нужно еще одно почти такое же по свойствам? :) >Ещё можно указать синхронизировать данные для только что записанного файла (что-то типа >sync). Ага.А можно еще костылей и подпорок напихать, ведь "ожегшись на молоке, на воду дуют".А может, лучше будет если ФС по дефолту будет надежной?А кто сильно хочет пальнуть себе в пятку пусть включает небезопасные опции сам. >Может программистам KDE и Gnome стоит переделать способы работы с конфиг файлами? А юзерам наслаждаться втихаря засранными другими файлами?И правда, обнаружить разрушение других файлов труднее - заметите только когда у вас уже порушится достаточно много файлов. >P.S. >Я бы изменил название новости на "Проблемы с потерей данных на Ubuntu >9.04 с дефолтными настройками". А вы - кто такой чтобы за всех решать?И кстати, как я помню, в убунте EXT4 - не дефолтная ФС, но выбрать ее при инсталле тем не менее можно.И то что оно себя по дефолту (ext4 а не убунтов) так ведет не есть гуд.Так что давайте названия будет менять кто-то покомпетентнее в вопросе чем вы, ага?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	96. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от szh (ok) on 13-Мрт-09, 03:44
	+1 по всем пунктам
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	115. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 15:51
	>>P.S. >>Я бы изменил название новости на "Проблемы с потерей данных на Ubuntu >>9.04 с дефолтными настройками". >А вы - кто такой чтобы за всех решать?И кстати, как я >помню, в убунте EXT4 - не дефолтная ФС, но выбрать ее >при инсталле тем не менее можно.И то что оно себя по >дефолту (ext4 а не убунтов) так ведет не есть гуд.Так что >давайте названия будет менять кто-то покомпетентнее в вопросе чем вы, ага? если ext3 считается надёжной только потому, что додумались ставить по-умолчанию data=ordered, то новость именно так и должна звучать, т.к. с такими же настройками и ext4 не менее надёжна..... хоть и не проверена временем. кстати, а что за барский вопрос: >А вы - кто такой чтобы за всех решать? давайте проголосуем! :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 12-Мрт-09, 20:09
	>В третьих, "крах системы" - это не нормальное состояние. >Это все равно что сказать: все современные ОС ненадежны - если тыкать >в кнопку RESET в случаном порядке, есть шанс потерять данные. микроядро - и заветную кнопку можно исключить из аппаратуры на...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:28
	>микроядро - и заветную кнопку можно исключить из аппаратуры на... А Чубайса ты куда денешь, умник?Или ты морально готов купить всем упсы за свой счет?Или может микроядро превратится при слете питания в дизель-генератор?Если вы не поняли - я кнопкой ресет и с обычным линуховым ядром не пользуюсь - в релизных версиях системы оно не падает, пардон, месяцами.Что не мешает например чубайсовской шараге срубать питалово.Ну и прочая.И микроядро ну вообще никак не поможет в этих случаях.А если вы считаете что в этом случае система имеет право подохнуть - пройдите на http://lleo.aha.ru/na - вас юзеры с такой системой которая при внеплановом рестарте херит данные отправят именно туда.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	104. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 12:07
	>Во вторых, такой способ оптимизации (delayed allocation) есть не только в ext4. >Вообще обнуление файлов при перезаписи, связанное с отложенно записью - это не такая уж новость. >Это вполне логичное следствие возможных последствий отложенной записи (когда возникает сбой или когда компьютер резко выключается/перезагружается). Ну вот на Reiser4 тоже использует отложенную запись, только почему-то подобных казусов с ней не происходит. Наверное из-та того, что Reiser4 это "неправильная" FS ? =D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	105. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 12:40
	>Ну вот на Reiser4 тоже использует отложенную запись, только почему-то подобных казусов >с ней не происходит. Наверное из-та того, что Reiser4 это "неправильная" >FS ? =D К рейзерам у юзерей по жизни масса предъяв почему-то.Третий рейзер вообще зачотная штука.На сайте amule.org можно посмотреть на очередных юзерей^W админов радостно констатирующих тотальный дестрой фс у себя на серваке.Там очень колоритные коменты по части того что перец думает о рейзере :).В общем такое ощущение что в рейзере уделили маловато внимания утилитам починки фс.А юзеру как-то пофиг на плюсы фс если она может развалиться а родные утили спасуют.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	107. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 13:34
	>На сайте amule.org можно посмотреть на очередных юзерей^W админов радостно констатирующих тотальный дестрой фс у себя на серваке. amule.org -> "No DNS records"  - как бы намекает на то, что это было давно или неправда >А юзеру как-то пофиг на плюсы фс если она может развалиться а родные утили спасуют. ну шансов развалиться у reiserfs (с учетом проверок в драйвере) куда меньше, чем у той же ext3
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	120. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 16:13
	проверок у ext3 не меньше. fresco подтвердит... :-) его то мнению Вы доверяете? у него очень не плохие статьи по фс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	121. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 16:30
	>проверок у ext3 не меньше. >fresco подтвердит... :-) >его то мнению Вы доверяете? у него очень не плохие статьи по фс. Он в подобные детали не вникал, судя по его статьям. А вот эти ребята вникали: http://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf (смотрим на число кружочков и читаем выводы, если лениво читать всё)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	124. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 16:58
	более развернутая версия http://www.cs.wisc.edu/adsl/Publications/vijayan-thesis06.pdf
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	134. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 19:04
	ну тогда и я ещё раз :-)  оттуда же: ext3 recovery: For most detected errors, ext3 propagates the error to the user (RPropagate). For read failures, ext3 also often aborts the journal (RStop); aborting the journal usually leads to a read-only remount of the file system, preventing future updates without explicit administrator interaction. Ext3 also uses retry (RRetry), although sparingly; when a prefetch read fails, ext3 retries only the originally requested block. ReiserFS recovery: The most prominent aspect of the recovery policy of ReiserFS is its tendency to panic the system upon detection of virtually any write failure (RStop). When ReiserFS calls panic, the file system crashes, usually leading to a reboot and recovery sequence. By doing so, ReiserFS attempts to ensure that its on-disk structures are not corrupted. ReiserFS recovers from read and write failures differently. For most read failures, ReiserFS propagates the error to the user (RPropagate) and sometimes performs a single retry (RRetry) (e.g., when a data block read fails, or when an indirect block read fails during unlink, truncate, and write operations). However, ReiserFS never retries upon a write failure.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	137. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 14-Мрт-09, 01:14
	там ещё четко написано относительно проверок на ошибки при записи, но кто-то почему-то это не процитировал... :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	127. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 17:28
	да читал я эту статью. уж и не помню сколько лет назад... по-моему в 2005. вывод статьи: We now describe our implementation and evaluation of IRON ext3 (ixt3). Within ixt3, we implement a family of recovery techniques that most commodity file systems do not currently provide. ... ixt3 applies checksums to both metadata and data blocks, uses pure replication for metadata, and employs parity-based redundancy to protect user data.......... 6.1 Implementation: We now briefly describe the ixt3 implementation. We explain how we add checksumming, metadata replication, user parity, and a new performance enhancement known as transactional checksums into the existing ext3 file system framework........ про fresco - я не знаю в какие детали он не влез, а меня исходники вполне убедили... да и с 2005 уже как 4 года прошло.... и победного шествия ixt3 не наблюдается.. как и рейзера4. заявить о возможностях - это одно. реализовать - другое. да и сравнивать красное с мягким - мне не интересно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	138. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 14-Мрт-09, 01:26
	>и победного шествия ixt3 не наблюдается.. часть идей из ixt3 перекочевала в ext4 на самом деле (те же jounral checksums) >да и сравнивать красное с мягким - мне не интересно. ну подняли же выше вопрос о надежности reiserfs - я дал по-моему вполне адекватную ссылку для "защиты чести" этой fs, и, наверное, каждый раз её буду давать если подобные темы будут всплывать =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	142. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 14-Мрт-09, 12:48
	о чём и речь. именно этого и ждут от ext4. и что интересно не ждут от ext3. ссылку можете приводить хоть сто порций. она также доказывает следующее: повторю свои аргументы - во первых она старая. во вторых мне не нравится, когда ядро паникует при обнаружении ошибки по записи на 128-м винте с порнушкой любимых пользователей. третье - за это время много исправилось и в самом коде ext3, а также появился ext4 и они даже порой совместимы и будут совместимы с btrfs. четвертое - мне импонирует четкое планирование выхода релизов, это позволяет мне разрабатывать определенную средне-срочную стратегию моих систем. пятое - о пункте 4 не приходится говорить ни в рейзере, ни в ixt3. ну и шестое - я никому не навязываю своего мнения, более того - рекомендую, т.к. новые идеи идут порой от самых экзотичных применений...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	144. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 16-Мрт-09, 13:42
	>во вторых мне не нравится, когда ядро паникует Это никому не нравится, но это политика reiserfs относительно сохранности данных (First, do not harm), которя уж куда лучше, чем у ext3 (Ignore) >за это время много исправилось и в самом коде ext3 однако это ж не повод преподносить ext3 как "надежность последней инстанции", т.к. за это время и в reiserfs тоже много чего исправилось (желающие могут глянуть на marc.info) >четвертое - мне импонирует четкое планирование выхода релизов Release (англ., сущ.) - выходь, выпуск.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	148. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 16-Мрт-09, 14:48
	никто и не преподносит. просто на все дополнительные возможности становится как-то насрать после паники ядра.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	118. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 16:10
	особенно это не происходит на десктопах... с активно работающими гном и кде... наверное потому, что процент таких машин с рейзером4 от машин с экст3 стремиться к нулю.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	122. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 16:36
	>наверное потому, что процент таких машин с рейзером4 от машин с экст3 стремиться к нулю. Тем не менее, ни я, ни кто другой и байта подобным образом не потерял за все время пользования reiser4 (ну если брать последний год-два). Хотя одно время даже старался, делал ресеты во время интенсивной работы fs. Наверное я что-то делаю не так =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	130. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 17:53
	тоже самое с ext3. а если нет разницы, то... дося. :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	145. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 16-Мрт-09, 13:43
	>тоже самое с ext3. >а если нет разницы, то... дося. :-D В ext3 нет delayed allocation, да и reiser4 она не конкурент
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	147. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 16-Мрт-09, 14:46
	да и хрен с ней. кто ж спорит. речь о надёжности и только.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Thorn (??) on 12-Мрт-09, 16:53

Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"? Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! Зачем ещё какие-то параноидальные "повышения надёжности"? Крах системы - это какой-то нонсенс. Падать должны гномики, а дисковая система работать на ура. Проблему надумали?

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

	13. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Анонимус on 12-Мрт-09, 17:08
	ЧЕстно говоря, даже отвечать лень. Почитай вики про журнал, что ль... У меня система действительно не падало ОЧЕНЬ давно... хотя убунту упала почти сразу после установки))) (вроде 8.10) ПС. Это бета или альфа, так что крах для неё - это норма...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 19:17
	>ПС. Это бета или альфа, так что крах для неё - это норма... во истину так.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 12-Мрт-09, 17:13
	Проблема есть, была и будет. Суть ее в кэшировании. А что именно отвалится если кэш или часть кэша не сброшена - все равно. Не хотите явно управлять современными сложнейшими устройствами, где надо делать fsync и прочее ? Хочется чтоб все "по волшебству" работало, как будто данные из регистров процессора пишутся сразу на поверхность жесткого диска? Ну тогда не нойте, или надежно будет или быстро, выбирайте что лучше для вас.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 12-Мрт-09, 17:43
	>Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"? >Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! Не понимаешь - читай книжки )) «Системная инфа» это называется метаданные, и они обновляются не атомарно. Надо писать в нескольких местах (поменять директорию, пометить блок как занятый). Если сбой происходит в момент обновления, (например блоки данных помечены как занятые, а в директорию изменения не записаны), то файловая система в противоречивом положении. Без журнала надо проверять всю файловую систему, а журнал позволяет БЫСТРО найти то место где была работа во время сбоя и исправить его.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 18:39
	>работать на ура. Проблему надумали? На самом деле трабл в том что ФС печется о валидности метаданных а что по факту случится с файлом и юзерскими данными в нем ей как бы это помягче сказать, глубоко фиолетово.И это неизбежно ведет к потере данных.И не то чтобы это следует приветствовать, ОСОБЕННО если это ведет к вот такому откровенному просеру данных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от _umka_ (ok) on 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 (??) on 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 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 19:51
	>Некоторые ограничивают размер своего кэша на запись кстати - из 32 мегов >на *запись* может юзаться и меньше чем 32 мега. А зачем в самом винте буфер на чтение? С readahead вроде система неплохо справляется, нет?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 12-Мрт-09, 23:36
	>А зачем в самом винте буфер на чтение? С readahead вроде система >неплохо справляется, нет? Не у всех есть readahead, особенно пока система только грузится, etc. Еще харду его истинная геометрия виднее.Может умудряются что-то оптимизнуть на основе этого знания?Система то видит это как линейный массив или совершенно левые CHS, особенности физики она не знает.А вот фирмвара контроллера в курсе истинной картины.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	101. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от _umka_ (ok) on 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 надежность - обе вещи одновременно не бывает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 12-Мрт-09, 19:26
	>На самом деле трабл в том что ФС печется о валидности метаданных >а что по факту случится с файлом и юзерскими данными в >нем ей как бы это помягче сказать, глубоко фиолетово. Это не трабл. Это ОЖИДАЕМОЕ поведение операционной системы. О данных программы должна заботится сама программа. За подробностями смотри man 2 write, когда данные реально пишутся на диск, и как программа может этот процесс контролировать. >И это неизбежно ведет к потере данных. Неизбежно только для кривого софта. postgresql и на xfs данные не теряет при внезапном выключении, потому что делает всё правильно, как положено. >И не то чтобы это следует приветствовать, ОСОБЕННО >если это ведет к вот такому откровенному просеру данных. Кривой софт должен быть исправлен или выброшен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	113. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от User294 (??) on 13-Мрт-09, 15:42
	>Это не трабл. Это ОЖИДАЕМОЕ поведение операционной системы. Если вы хотите юзать операционку которая норовит поднасрать - это ваше право.А я хочу чтобы дефолты операционки не стреляли мне в пятки.Если меня перфоманс будет колыхать больше интегрити, я согласен подкрутить параметры ФС - для скоростных применений тюнить 1 хрен придется, как часть процесса это нормально.А вот херить мои файлы по дефолту - не сметь.Говно та ФС которая осмелится на такое.И это не обсуждается.Мои данные мне ценнее чем левые отмазки разработчиков про юзеж sqlite и правильную работу с файлами.Грубо говоря - да, я не приветсвую софт сделанный по принципу "на отъ..сь".Даже если он и соответствует каким-то там стандартам, меня это мало колышет.У меня есть некоторый набор МОИХ критериев при которых я рискну связаться с тем или иным софтом.Пока-что то что я увидел насчет EXT4 для меня означает что у МЕНЯ его в СИСТЕМНОМ КАТАЛОГЕ не будет.А там где меня колыхала скорость, я давно поюзал XFS подпертый упсой, с барьерами и прочая, по возможности с readonly (насколько возможно) данными.Нафиг мне тогда этот EXT4 вообще сдался?У XFS все что в нем есть было сто лет назад уже.Не было - такой же стабильности и надежности к которой все привыкли за годы юзежа EXTов (во всяком случае ора про зануление файлов - хватает). >О данных программы должна заботится сама программа. Конечно, вместо того чтобы ОДНИМ програмерм сделать надежную ФС надо ВСЕХ попытаться построить.Это безнадежное начинание ессно заведомо ПРОВАЛИТСЯ и как всегда итог будет прост: У ЮЗЕРОВ БУДУТ ХЕРИТЬСЯ ФАЙЛЫ.И никого не будет колыхать что программы "неправильные", раньше они прекрасно работали.А на стандарты позикса всем глубоко положить.И отмазка програмера что поведение соответствует позиксу мало кого волнует кроме него самого.Остальным нужна работающая и надежная ФС а не соответствие стандартам и прочая - принцип "на отъ...сь" в таком вопросе ИМХО не пройдет. >За подробностями смотри man 2 write, когда данные >реально пишутся на диск, и как программа может этот процесс контролировать. Да, я уже побежал строить миллионы програмеров писать программы правильно или переписывать их терабайты кода на правильный манер.Специально для Теодора вот так разопрусь, ага, мля. >Неизбежно только для кривого софта. postgresql и на xfs данные не теряет >при внезапном выключении, потому что делает всё правильно, как положено. Сравнили БД у которой поди свое журналирование припахано (чтобы не зависеть от ФС вообще) и обычные программы.Если каждую программу делать монстренком типа постгреса, виндовс виста покажется очень скромной, быстрой и не требовательной к ресурсам ОС :) >Кривой софт должен быть исправлен или выброшен. Исправляйте.Выбрасывайте.Вот только исправлялка может сломаться а если все выбросить - зачем вам тогда вообще компьютер?А так - программы неидеальные, да.И совсем не обязательно помогать програмерам лищний раз нарваться на грабли или заставлять их воркэраундить закидоны не в меру капризных ФС.И исправлять абы какую работу ФС путем запрягания програмеров на написание вычурных конструкций - странный подход.Так и на сраный фат можно файлы писать.Зачем тогда вообще журналируемые ФС какие-то?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Tim (??) on 12-Мрт-09, 18:49
	> Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! IMHO во FreeBSD это называется SoftUpdate. > Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"? 1) технология журналирования уже расPRена (журнал магически исправляет ошибки дизайна) 2) новую "надежную ФС" могут написать даже "индусы" (речь не об конкретной ФС и тем более ОС) 3) идея журналирования широко используется уже 20 лет главный козырь) у нас -- как в ntfs, только лучше! ;-) > Зачем ещё какие-то параноидальные "повышения надёжности"? журналирование ФС используется не для повышения надежности, а для сокращения времени восстановления ?_внутренних_ структур ФС после сбоев. О сохранности пользовательских данных речи вообще _нет_. Для повышения надежности используется аппаратный кэш (статическая память*) дисковой подсистемы. Или в бюджетном варианте синхронная запись на диск. * статическая память -- может пережить отключение питания, при этом очень быстрая и очень дорогая. > Проблему надумали? Нет, любое техническое решение -- это компромис, ширпотреб "кукурузник" не сможет летать как дорогой "истребитель". В данном случае пытались ускорить запись, за счет снижения надежности. Думаю все знают, что последовательная запись большого файла идет значительно быстрее, чем запись множества коротких. С увеличением задержки, можно сгруппировать обращение к диску -- следовательно скорость увеличится. Но чем больше задержка, тем больше потери при крахе системы. В статье говорилось о задержке перед записью в 60 сек -- значит при падении системы, будут терятся (в среднем) все записи сделанные за последние 30 сек перед сбоем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от _umka_ (ok) on 12-Мрт-09, 19:25
	>> Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! > >IMHO во FreeBSD это называется SoftUpdate. > только в extXXX - журнал на диске в специальной inode. а в FreeBSD - это в памяти, а в остальном функциональность похожая. Поэтому после падения - в ext можно что-то прочитать, а в freebsd - этого нету. Но в FreeBSD добавили журналирование через GEOM (geom_journal) - насколько я понял это полное журналирование данных и лучше такое держать на внешнем девайсе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Tim (??) on 12-Мрт-09, 22:42
	>>> Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! >> >>IMHO во FreeBSD это называется SoftUpdate. >> > >только в extXXX - журнал на диске в специальной inode. >а в FreeBSD - это в памяти, а в остальном функциональность похожая. Работа extXXX классическая - 1) отметка в журнале "начало операции" 2) выполнение операции (обычно группируются в пакеты для производительности) 3) отметка в журнале "завершение операции" При сбое: чтение журнала и откат до валидного состояния. IMHO основная идея SoftUpdate выполнять изменения метаданных в таком _порядке_, чтобы состояние ФС на _диске_ всегда было валидным! Основной упор делается на _порядок_ изменений. PS. Подробности реализации этого чуда во FreeBSD я незнаю (не интересовался), по-этому судить о сильных/слабых сторонах не могу. PPS. Вероятно я ошибаюсь, ушел искать FM по SU ;-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	102. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от _umka_ (ok) on 13-Мрт-09, 10:13
	>[оверквотинг удален] >>> >>>IMHO во FreeBSD это называется SoftUpdate. >>> >> >>только в extXXX - журнал на диске в специальной inode. >>а в FreeBSD - это в памяти, а в остальном функциональность похожая. > >Работа extXXX классическая - >1) отметка в журнале "начало операции" >2) выполнение операции (обычно группируются в пакеты для производительности) тут разное, бывает журналирование обновлений блоков метаданных, бывает всего. главная задача создать правильный порядок обновления - как вобщем-то и SU. >3) отметка в журнале "завершение операции" ошибка. journal commit + очистка журнала - журнал не растет бесконечно. >При сбое: чтение журнала и откат до валидного состояния. не откат а journal replay. операции из журнала применяются повторно - чем гарантирует что по концу журнала FS будет +/- не противоречиво. > >IMHO основная идея SoftUpdate выполнять изменения метаданных в таком _порядке_, чтобы состояние >ФС на _диске_ всегда было валидным! Основной упор делается на _порядок_ >изменений. будете смеяться - но в ext - тоже самое, задача получить правильный порядок обновления. > >PPS. Вероятно я ошибаюсь, ушел искать FM по SU ;-) я там копался весьма мало - но по результатам сложилось стойкое впечатление что это тот же журнал - только в памяти. для ext такое тоже делают для ускорения - journal на внешнем флэш девайсе или в ram которая искуственно подпитывается.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	108. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Tim (??) on 13-Мрт-09, 14:02
	>тут разное, бывает журналирование обновлений блоков метаданных, бывает всего. >главная задача создать правильный порядок обновления - как вобщем-то и SU. Нет, вы неправы. В журналированных ФС порядок операций в составе одной транзакции практически неважен. (Транзакция атомарна по определению и может только выполнится или откатится.) По-этому реализация и главное отладка значительно проще. >не откат а journal replay. операции из журнала применяются повторно - чем >гарантирует что по концу журнала FS будет +/- не противоречиво. Отложенная транзакция - более ресурсоемко, чем откат незавершенной транзакции. И применяется только в работе с распределенной базой данных. Использование механизма отложенной транзакции в ФС избыточно по функциональности и значительно снижает производительность подсистемы. >что это тот же журнал - только в памяти. для ext Нашел прекрасное описание SU написанное McKusick'ом. Если в кратце: 1) изменения метаданных записывается в кэш (как и в extXXX) 2) строится граф зависимостей этих изменений 3) сортируется (топологическая сортировка) 4) выполняется по порядку McKusick указал на два основных недостатка: 1) это сложность реализации (и соответсвенно отладки) 2) возможность утечки свободного дискового пространства при сбоях Второй пункт рекомендует лечить фоновым fsck
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	154. "FreeBSD SoftUpdates vs журнал"
	Сообщение от nuclight (ok) on 21-Мрт-09, 22:37
	По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно такой специфический журнал, только существующий исключительно в памяти. И при сбое он теряется, то есть всегда выполняется rollback транзакций. >McKusick указал на два основных недостатка: >1) это сложность реализации (и соответсвенно отладки) >2) возможность утечки свободного дискового пространства при сбоях >Второй пункт рекомендует лечить фоновым fsck Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. Второй пункт появляется, поскольку на диске реального журнала нет, и если сбой случится в окно записи на диск, то будет ошибка. Однако SU построен таким образом, что класс таких ошибок очень ограничен (по большому счету пропажа места, ага), потому с введением бэкграундного fsck систему можно запускать сразу же на непроверенной fs, очень удобно, в отличие от форсированных проверок "180 дней на ext3 без fsck". Журнал не панацея, хехе. В общем, идея, повторюсь, неплоха, и вполне конкурентоспособна с журналом. Вот только из-за сложности реализации имеются проблемы - например в NetBSD с кодом задолбались и будут SU выкидывать. Печальный пример, как плохая реализация может убить хорошую идею.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Султан on 12-Мрт-09, 18:58

А почему этой проблеме подвержена в том числе и btrfs? Разве оно не copy-on-write?

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

	49. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от yalur (ok) on 12-Мрт-09, 19:54
	Во-во, что то у меня на zfs такого никогда не наблюдается, хоть уже полтора года юзаю вместе с KDE.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 23:07
	оракле туда пихни... или постгрес... развлечения обеспечены. при том, что она ещё и ресурсов жрать будет больше их вместе взятых (на нагрузке конечно)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

53. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Аноним (??) on 12-Мрт-09, 20:00

> при которой данные и мета-данные могут >оставаться незаписанными до 60 секунд. > >Данная возможность является одним из главных факторов значительного повышения производительности ext4 по >сравнению с ext3. man /proc/sys/vm :E

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

59. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Breg (??) on 12-Мрт-09, 20:44

Бок ext4 только в том, что она сразу делает truncate (точнее в журнале записывает, что он уже сделан) и только через t<=60сек записывает новые данные. Вот это и должно быть исправлено. По поводу fsync - из-за него много тормозов возникает, особенно во время загрузки системы. Поэтому, с целью ускорения загрузки и отзывчивости программ, от него избавляются где могут. Вот например исправили такой баг: "Firefox 3 fsync excessively and ui freezes" Описание: "I think you can see where this is going: if there's a lot of data waiting to be written to disk, and Firefox's (sqlite's) request to flush the data for one file actually sends all that data out, we could be waiting for a while. Worse, all the other applications that are writing data may end up waiting for it to complete as well. In artificial, but not entirely impossible, test conditions, those delays can be 30 seconds or more. That experience, to coin a phrase, kinda sucks. Does it suck as much as file corruption wiping out your bookmarks after your computer (not Firefox) crashes? As you might imagine, opinions vary." Резюме: если какое-то приложение делает fsync для большого объемы данных, то оно само в этот момент не отвечает, да еще и другим не дает записать данные, из-за чего и они не отвечают.

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

	155. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от nuclight (ok) on 27-Мрт-09, 12:42
	Это опять таки проблемы реализации некоторых линуксовых fs, а не приложения. На нормальных fs будет fsync только конкретного файла, он не поставит всю систему раком в ожидании. В POSIX всё-таки 2 разных системных вызова - fsync() для одного файла и sync() для всей системы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

62. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Аноним (??) on 12-Мрт-09, 21:20

>Разбор ситуации показал, что при >загрузке KDE и GMOME пересоздают большое число мелких файлов, и если >системный крах произойдет через небольшое после загрузки время, эти файлы окажутся >обнуленными (в журнал изменения вносятся сразу, но сами данные на диск >записаться не успевают).  ... Собственно, а при чем здесь ФС. Или вы хотели и на диск не писать, и при отключении эл-ва чтобы все сохранялось? Покупайте ИБП. >Тем не менее Ted пообещал выпустить патч, изменяющий поведение отложенной записи в ext4 при фиксировании фактов обнуления или переименования файлов. Может быть полезно, главное, чтобы было опционально. Кому-то может оно и не нужно.

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

65. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Аноним (??) on 12-Мрт-09, 21:28

Да, ребятки, что-то тут народ совсем жиденький. :( Хочу обратно на лор. Верните анонимуса! По теме: проблема лишь одна - режим отложенной записи не доллжен быть включен по умолчанию. Вот и все.

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

	66. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от darkk on 12-Мрт-09, 21:30
	>По теме: проблема лишь одна - режим отложенной записи не доллжен быть >включен по умолчанию. Вот и все. А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 12-Мрт-09, 21:49
	>А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-) 5 секунд, на файлопомойке с большой дисковой активностью на запись ) - минута. А в чем проблема, буферизация нах. Можно и sync на каждый чих делать. Еще проще применять аппаратные решения. О чем разговор то? Хотите абсолютной надежности? Дык какого-хрена ЭВМ типа "домашний" пользуете, для этого есть специализированные решения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 12-Мрт-09, 23:10
	>>А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-) > >5 секунд, на файлопомойке с большой дисковой активностью на запись ) - >минута. А в чем проблема, буферизация нах. Можно и sync на >каждый чих делать. Еще проще применять аппаратные решения. О чем разговор >то? Хотите абсолютной надежности? Дык какого-хрена ЭВМ типа "домашний" пользуете, для >этого есть специализированные решения. не пользуем, а рассуждаем.... интересно. где ты ещё увидишь такое бурое обсуждение беты убунты? :-D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

93. "А зачем при старте перезаписывать конфиги?"

Сообщение от Дмитрий Ю. Карпов on 12-Мрт-09, 23:57

Я так и не понял, зачем при старте (даже не при окончании работы, а при старте) надо создавать много мелких файлов (когда можно создать один большой), да ещё и перезаписывать конфиг! Интересно, как эта система может работать с LiveCD?

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

97. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Андрей (??) on 13-Мрт-09, 06:02

Что-то мутное - эти системы конфигурации KDE и gnome. Из-за них я не пользуюсь ни KDE, ни gnome'ом. Пусть они Elekta'у попробуют для конфигов - тогда не будет таких проблем.

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

100. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от fresco (??) on 13-Мрт-09, 09:50

ну накинулись на файловиков. любая файловая система, располагающая механизмом delayed allocation, при сбое в момент интенсивной записи получит сходные проблемы. в той или иной мере это справедливо для XFS, JFS, ZFS, btrfs, ext4. решением тут может стать монтирование с -o sync, использование режима data=ordered в ext4 и btrfs, или применение vfat/ext2 -- словом, отказ от серьезного повышения производительности. понятно даже и ежу -- корень проблемы не в реализации конкретной ФС, в самом механизме отложенного размещения. любому, кто сделал над собой усилие и разобрался в алгоритмах работы современных файловых систем, это совершенно ясно уже много лет. критична надежность -- покупайте UPS, используйте простые ФС или синхронные режимы работы   диском. а в данной ситуации, ИМХО, виноваты исключительно кодеры KDE/GNOME, не корректно обрабатывающих конфиги. можно понять ubuntu-юзеров, которые не хотят разбираться, а хотят работать. но программистов, прекрасно понимающх последствия такой беспечности, я оправдать не могу.

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

	103. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от XoRe (ok) on 13-Мрт-09, 11:21
	>[оверквотинг удален] >понятно даже и ежу -- корень проблемы не в реализации конкретной ФС, >в самом механизме отложенного размещения. любому, кто сделал над собой усилие >и разобрался в алгоритмах работы современных файловых систем, это совершенно ясно >уже много лет. критична надежность -- покупайте UPS, используйте простые ФС >или синхронные режимы работы   диском. > >а в данной ситуации, ИМХО, виноваты исключительно кодеры KDE/GNOME, не корректно обрабатывающих >конфиги. можно понять ubuntu-юзеров, которые не хотят разбираться, а хотят работать. >но программистов, прекрасно понимающх последствия такой беспечности, я оправдать не могу. > +1 Рад вашему ходу мыслей. 2 User294: Я понял, что вам не нравится ext4. А вообще, этой новости, как и обсуждения не случилось бы при любом из 2 условий: 1. В KDE/Gnome лучше бы относились к своим конфигам. 2. В Ubuntu 9.04 по дефолту в ext4 было бы отключено delayed allocation. Первое желательнее, второе реальнее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	106. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от uldus (ok) on 13-Мрт-09, 12:47
	>понятно даже и ежу -- корень проблемы не в реализации конкретной ФС, Разница в реализации огромная - в одном случае получим после сбоя пустые файлы, а в другом файлы со старым содержанием.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	109. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 14:27
	>любая файловая система, располагающая механизмом delayed allocation, при сбое в момент интенсивной записи получит сходные проблемы. в той или иной мере это справедливо для XFS, JFS, ZFS, btrfs, ext4. решением тут может стать монтирование с -o sync, использование режима data=ordered в ext4 и btrfs, или применение vfat/ext2 -- словом, отказ от серьезного повышения производительности. Решение этой проблемы - атомарность, когда несколько действий с файлом объединяются в один атом. Задача драйвера fs в данном случае - максимально корректно строить эти атомы, чтобы эффективно минимизировать число записей в журнал, и минимизировать потерю данных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	123. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 16:50
	есть только один вопрос - как эту атомарность обеспечить? по каким критериям? в транзакциях понятно. известно её начало, контрольные точки и завершение. не говоря о том, что все эти процессы длятся во времени: 1. 15:00 - открыл файл 2. 15:10 - обнулил 3. 16:00 - записал новые данные будем хранить данные 50 минут? ладно. проверку на 0 встроят. но это не панацея. в конце концов фс - это не субд... может быть пока не субд.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	126. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Thorn (??) on 13-Мрт-09, 17:11
	>есть только один вопрос - как эту атомарность обеспечить? Никак. Долго открытый файл - это проблема приложения, ставящего под риск свои данные.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	133. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 18:33
	в том то и дело - как долго? сейчас - 60 секунд. всё остальное - долго. если свести к 0. то получим ordered как в ext3. :-) конечно, мой пример мягко говоря экзотичен,... но не невозможен. и просто для иллюстрации.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	128. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 13-Мрт-09, 17:45
	>1. 15:00 - открыл файл >2. 15:10 - обнулил >3. 16:00 - записал новые данные >будем хранить данные 50 минут? Корень текущей обсуждаемой проблемы - открытие на запись непустого файла с флагом O_TRUNC. Т.е. до форсированной записи данных (по таймауту, давлению, принудительно - как угодно) или закрытия файла можно было бы вообще ничего не делать, а держать изменения в пямяти. А дальше записать транзакцию, результат которой - старый файл или новый. Но не промежуточное состояние, которым является открытие файла с любым флагом. И в нашем случае интервалы не десятиминутные.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	131. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 18:18
	>Корень текущей обсуждаемой проблемы - открытие на запись непустого файла с флагом O_TRUNC. вот именно. объединяем 1-й и 2-ой пункты. получаем 1 час :-D дальше программа готовит данные (время окончания в общем случае не известно) или порционно скидывает на диск (что ещё хуже). >Т.е. до форсированной записи данных (по таймауту, давлению, принудительно - как угодно) или закрытия файла можно было бы вообще ничего не делать, а держать изменения в пямяти. ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение? а программистам из гном, кде,.. выслать инструкции о правильной форсированной записи данных? :-DDDDDD и опять полагаемся на их добросовестность? а результат - критериев нет, множества контрольных точек нет, факта окончания транзакции нет. время окончания транзакции в общем случае не известно. объём необходимой памяти для хранения изменений не известен (а хранить надо все, что пытаются удалить... а если записали только 1-ю порцию? удаляем?.. но ведь пустой конфиг не многим хуже, чем наполовину заполненный - хрен будет работать после сбоя... значит храним до close?... а тогда и часом не отделаешься!!!) описываемые Вами требования решают различные СУБД. и то! с переменным успехом. а мы говорим о фс, которая предположительно будет устанавливаться от смартфонов с нетбуками до самых экзотичных устройств.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	136. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 14-Мрт-09, 01:07
	>вот именно. объединяем 1-й и 2-ой пункты. получаем 1 час :-D нет, есть ведь т.н. время жизни транзакции >ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение? ядро >а программистам из гном, кде,.. выслать инструкции о правильной форсированной записи данных? :-DDDDDD и опять полагаемся на их добросовестность? fsync достаточно, иначе система будет кешировать все, что только можно и как можно дольше, к примеру >а результат - критериев нет, множества контрольных точек нет, факта окончания транзакции >нет. время окончания транзакции в общем случае не известно. объём необходимой >памяти для хранения изменений не известен кешировать все, пока не закончится дисковый кеш или не превысим некоторый утановленный лимит dirty-буферов >(а хранить надо все, что пытаются удалить... с wandering logs и это не проблема >а если записали только 1-ю порцию? удаляем?.. но ведь >пустой конфиг не многим хуже, чем наполовину заполненный - хрен будет >работать после сбоя... значит храним до close?... а тогда и часом >не отделаешься!!!) если запишется только часть данных - это нормально, а вот обнулять кучи файлов - ненормально. >описываемые Вами требования решают различные СУБД. и то! с переменным успехом. в т.ч. reiser4, с постоянным успехом =) >а мы говорим о фс, которая предположительно будет устанавливаться от смартфонов с нетбуками до самых экзотичных устройств. редко кто ext3 ставит на подобную экзотику, не говоря уже о ext4, которую еще пилить и пилить годами
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	143. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 14-Мрт-09, 16:48
	>нет, есть ведь т.н. время жизни транзакции это уже не транзакция, а извиняюсь порнография. основное достоинство oracle - время жизни транзакции определяется исключительно бизнес-требованиями. >>ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение? >ядро э-э-э нет. такой хоккей нам не нужен. >если запишется только часть данных - это нормально, а вот обнулять кучи файлов - ненормально. вот этого мне уж ТОЧНО не надо. ситуация будет ещё хуже и ещё менее диагностируема. пусть это будет в рейзере или ещё где.... так сказать для любителей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	146. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от zzz (??) on 16-Мрт-09, 13:56
	>это уже не транзакция, а извиняюсь порнография. основное достоинство oracle - время жизни транзакции определяется исключительно бизнес-требованиями. смотри те же исходники jbd, reiserfs там это понятие определено как commit_timeout >э-э-э нет. такой хоккей нам не нужен. читай исходники jbd2 (да, да, это ext4 и delayed allocation!) похоже, что ты не монимаешь о чем говоришь, а споришь лишь из принципа =) >пусть это будет в рейзере или ещё где.... так сказать для любителей. действительно, оставим НЕлюбителей наедине с их кактусом =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	149. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 16-Мрт-09, 15:01
	а я где то писал, что в восторге от текущего положения во всех журналируемых фс? :-D пока что все они - это компромис. >действительно, оставим НЕлюбителей наедине с их кактусом =) глупо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

125. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Thorn (??) on 13-Мрт-09, 17:09

Ребят, а нельзя ли взять лучшее от обоих миров? Скажем, есть некий архив-сетап. Если он распаковывает файлы, нам ПОФИК что и как там распакуется, т.к. его всегда можно распаковать заново. Тогда разархиватор даёт команду системе: запиши эти файлы, но они не очень важны - можешь держать в кэше. А если это, скажем, СУБД - она так строго и говорит: "запиши немедленно!". Т.е. драйвер ФС будет иметь несколько типов записи, какой хочешь - такой и выбирай.

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

	132. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от vitek (??) on 13-Мрт-09, 18:28
	в том то и проблема. есть определённые системные вызовы по работе с файлами... они работают годами... и есть куча приложений, которые именно так (и только так) работают. грубо выражаясь они все как в приведённом Вами примере - СУБД... и все так строго и говорят - "запиши немедленно!"... а потом подтверждают ещё по делу и без - flush... а ещё есть асинхронный ввод-вывод...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

139. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от Аноним (??) on 14-Мрт-09, 01:42

кто знает при data=journal delayed allocation? мне скорость понравилась как у ext3 data=ordered и этого глюка нет.

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

	140. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."
	Сообщение от Аноним (??) on 14-Мрт-09, 01:42
	>кто знает при data=journal delayed allocation? >мне скорость понравилась как у ext3 data=ordered и этого глюка нет. работает delayed allocation?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

150. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."

Сообщение от XoRe (ok) on 16-Мрт-09, 17:45

Ребят, чего париться - отключаем delayed allocation и все, что может привести к обнулению и радуемся)

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

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]