| 1.1, Ivan (??), 16:06, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Разбор ситуации показал, что при загрузке KDE и GMOME пересоздают большое число мелких файлов
Вот! И это, в частности, плохо.
| | |
| |
| 2.41, darkk (?), 19:28, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
 А я в упор не понимаю, в чём проблема, освещенная в новости.
Кого-то удивляет, что данные теряются при цепочке read/truncate/write ? Так это нормально — пусть, например, прилетит пишущему процессу SIGKILL в момент между truncate и write... Для конфигов и прочих мелких файлов стандартной идиомой считалось всегда read/write/rename. В man 2 rename отдельно сказано о гарантиях атомарности.
| | |
| |
| |
| 4.52, darkk (?), 19:59, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ну хоть один вразумительный коммент....
Если сходить по ссылке дважды — можно найти ответ на глупый вопрос «а что не так с rename».
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45
Вкратце — в схеме read/create/write/rename тоже не всё гладко из-за этой баги, а говноприложения были названы говноприложениями только из-за того, что они (судя по всему) обновляют файлы конфигов без необходимости... Хотя, может я что-то и недопонял.
| | |
| |
| 5.71, vitek (??), 22:13, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
можно. (пока по ссылке не ходил, но) с ним многое не так. начиная от фрагментации и заканчивая модными ныне конфигами в xml-формате.
но ёлки-палки. как часто меняется конфиг? он имеет важность не менее, чем сама программа. он и есть часть программы. если разработчик о нём не побеспокоиться, то кто?
логи конечно не так важны... но как работает с ними логротейт!.. с чужими логами кстати.
если какие-то данные в конфиге меняются часто, то это уже не данные для конфига... надо выносить.
| | |
| |
| 6.95, pavlinux (ok), 03:18, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
 У Юниксовой проги вообще не должно быть конфига!!! Это от врагов, из M$ДОС и OS/2, притащилось!
| | |
| |
| 7.110, User294 (??), 14:48, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>У Юниксовой проги вообще не должно быть конфига!!!
Да, давайте еще у init стартовые скрипты отнимем :)
| | |
|
|
|
|
|
|
| 1.2, друг pavlinux (?), 16:17, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
,,,хм молодец, сразу нашел отговорку - виноват пользователь,,,,,, - ужас! человек который пишет именно системное приложение так говорит!!!! Это подчеркивает о его некомпетенции!!!! Сам программировал микроконтроллеры, ни когда, человек, который пишет именно системные приложения, ни скажет такое!!!
А уж тем более о том, что виновато именно пользовательское приложение,,,,, -узость интеллекта, не более,,,,
| | |
| |
| 2.8, Аноним2 (?), 16:45, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
А че вы так, собственно, бурно реагируете? Не нравится - не пользуйтесь...
| | |
| |
| 3.14, User294 (??), 17:10, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>А че вы так, собственно, бурно реагируете? Не нравится - не пользуйтесь...
Ага, круто.Сначала у юзеров #@нутся данные а потом - они и не будут использовать.Рассказывая всем вокруг какое г эта система: сама дохнет на ровном месте.Ну не должна операционка дохнуть от ребута невовремя.Это - критчный баг и ниипет.
| | |
| |
| 4.30, vitek (??), 18:58, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | операционка и не дохнет вернее дохнет, но не от этого дохнут файлы и то толь... большой текст свёрнут, показать | | |
| |
| 5.35, User294 (??), 19:20, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Ну, с точки зрения юзера - система сыграла в ящик от слета питания Надежность Ха... большой текст свёрнут, показать | | |
| |
| 6.42, vitek (??), 19:32, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Ну, с точки зрения юзера - система сыграла в ящик от слета питания.Надежность?Хаха, уровня Win95?Вот пикинь, мне срочно надо допустим что-то оплатить а у меня система не грузится.Мило, да? :)
именно.
вот это и надо обсуждать.
>Отлично, а какого они собственно дохнут?Это разве так и надо?И на ext3 не дохли, по крайней мере - вот так вот :)
читаем внимательно новость и видим слово ordered. и что? только в этом режиме она надёжна?
а чего раньше не сказали? сколько лет уж!! :-DDDDDDDDDDDDDDD
дальше комментировать уж нету сил ;-)
напомню, что бьюся только те файлы, которые используются раком. теперь будет патч для защиты от извращенцев... все рады. все довольны. занавес.
| | |
| |
| 7.46, User294 (??), 19:50, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Моя имха если в старой ФС что-то работало без потерь данных а в новой - данные ... большой текст свёрнут, показать | | |
| |
| 8.51, darkk (?), 19:56, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Эм Это не журналирование на уровне приложений, это правильный метод работы В... текст свёрнут, показать | | |
| |
| 9.57, . (?), 20:21, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | это неправильный метод работы для приложения запись файла можно считать почти а... текст свёрнут, показать | | |
| |
| |
| |
| 12.61, darkk (?), 21:12, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Да, с точки зрения пользовательского интерфейса, не писать, если нет места - чуд... текст свёрнут, показать | | |
| |
| 13.69, User294 (??), 21:54, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Все так, но вероятность нарваться на эту ситуацию очень мала К тому же можно про... большой текст свёрнут, показать | | |
| |
| |
| |
| 16.76, vitek (??), 22:42, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | 100 на время жизни программы приложение запущенное на выполнение это величина... текст свёрнут, показать | | |
| 16.80, User294 (??), 22:56, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Что вы этим хотели сказать Я хотел сказать что сбагривать проблему с похеривание... большой текст свёрнут, показать | | |
| |
| 17.99, darkk (?), 06:44, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | Только то, что конфиг 8212 ведь постоянная, а база 8212 изменчивая Лю... большой текст свёрнут, показать | | |
|
|
|
| 14.72, darkk (?), 22:17, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Конечно, вероятность аппаратного сбоя и повреждения структур ФС тоже невелика К... большой текст свёрнут, показать | | |
| |
| 15.74, vitek (??), 22:34, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | блин ребята речь не о методах обновления файлов эта херь почему-то встречаетс... текст свёрнут, показать | | |
| 15.84, User294 (??), 23:09, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Да Например, есть вероятность что все молекулы воздуха резко улетят в другую ком... большой текст свёрнут, показать | | |
|
|
|
| 12.68, Tim (??), 21:50, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Это работает _только_ в однозадачной системе Hint свободное место _до_, _вовр... большой текст свёрнут, показать | | |
|
|
|
|
| 8.54, vitek (??), 20:03, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | а ведь придется -DDDDDDDDDDDDDDDDDDDDDd да и удивляться не чему чем сложнее с... большой текст свёрнут, показать | | |
| |
| 9.63, User294 (??), 21:22, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | вертя перед монитором фигой это вы сами как-нить, без меня А я лучше ext3 поюз... большой текст свёрнут, показать | | |
|
|
| 7.55, yalur (ok), 20:03, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>напомню, что бьюся только те файлы, которые используются раком. теперь будет патч для защиты от >извращенцев... все рады. все довольны. занавес.
Ну не знаю, по ссылке чувак пишет:
Also some of my MySQL databases were killed...
Походу придем к тому, что все проги "используются раком". Вобщим ФС такая крутая, что все остальное - это сплошной глюк и все нада переписать заново.
| | |
| |
| 8.81, vitek (??), 22:58, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | пипец ну и кем она килед читайте новость там система ПАДАЕТ то что патч до... текст свёрнут, показать | | |
| |
| |
| |
| |
| 12.117, vitek (??), 16:03, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | на самом деле важно не это важный вопрос, как всегда за кадром по теме - поч... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 5.36, анонимус (?), 19:20, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>и в принципе логично. если я пишу прогу, которая читает файл, потом
>обнуляет его, а потом в слегка изменённом виде туже информацию записывает
>обратно...
>на не журналируемой фс эффект был бы тот же, если отрубить питание
>по-середине этого процесса. (в журналируемой - этот период может бытьбольше за
>счёт отложенности записи).
Что за дурь, твое приложение передало в ОС данные для записи в файл с помощью вызова 'write' и упало после этого. Это не значит что данные при этом должны потеряться.
После успешного завершения вызова 'write' ОС берет на себя все обязательства о сохранности этих данных, что оно сними будет делать (журналировать, буферизировать и т.п.) это нас не волнует, пусть хот мы трижды после этого упали или зависли.
| | |
| |
| 6.38, vitek (??), 19:25, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
ещё раз повторяю:
падает не приложение, а система... она же ОС... тот же эффект при выключении питания.
что ещё не понятно?
новость вообще хоть кто-нибудь читает? про хождение по ссылкам я уже не говорю.
| | |
| |
| 7.89, User294 (??), 23:23, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>ещё раз повторяю:
>падает не приложение, а система... она же ОС... тот же эффект при
>выключении питания.
Отлично.А почему при этом должно что-то хериться?Изначально журналы и транзакции как раз и были придуманы чтобы внезапные проблемы не приводили к потерям данных.Или доводится до победного финала или откатывается в вид как было.И это то чего всем и хочется.Правда вот платить скоростью за это никто не любит :)
| | |
| |
| 8.98, darkk (?), 06:41, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | А был момент, когда файл был нулевого размера и данных в нём не было Если был ... текст свёрнут, показать | | |
| |
| 9.116, User294 (??), 15:58, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | Все так, но было бы логично если бы ФС не особо торопилась с коммитом именно так... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.23, xand (?), 18:31, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Разве кто сказал, что виноваты пользователи? Внимательней нужно читать. Если не помогает - несколько раз...
Вина была возложена на разработчиков "падающего" софта.
| | |
|
| |
| |
| |
| Часть нити удалена модератором |
| 4.17, User294 (??), 17:20, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Тут рассказывается о проблемах убунты и ее хреновых настройщиках
>а сама фс делает то что и должна
Знаете, ФС не должна палить в пятки юзера по дефолту.И я не думаю что убунтуйцы специально крутили опасные настройки.А то что это можно как-то там заворкэраундить в настройках (скорее всего просрав хваленый прирост производительности) - дело хренадцатое.Эксты обычно все юзают за их трудноубиваемость.Если у них просрется это достоинство - а кому и нафига они вообще нужны будут?
И отмазки про приложения выглядят жидковато.Хотелось бы чтобы журнал все-таки занимался своим делом - или все(запись в файл доведена до конца), или ничего(откачено нахрен в вид как было).Переписывать файлы по поводу и без - дрянная тактика, но файловую систему теряющую данные это не оправдывает.
| | |
| |
| |
| 6.28, User294 (??), 18:57, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Да что вы говорите У меня на FAT при слете питания однажды нулось несколько бо... большой текст свёрнут, показать | | |
| 6.33, vitek (??), 19:08, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
ну это Вы точно загнули!
2-е копии FAT (имеется ввиду File Allocation Table, а не название фс) меня пугали ещё 20 лет назад (петька нортон даже их бекап предлагал делать пере выключением в своих утелитах). и за мой опыт слетали обе нах несколько раз.
| | |
|
|
|
|
|
| 1.7, prapor (??), 16:42, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Намедни поймал такое на Debian unstable+experimental. Списал на глюк KDE4.
| | |
| |
| 2.16, vitek (??), 17:20, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Списал на глюк KDE4.
и правильно сделал...
но базовая фс всё равно должна быть не убиваемой.
может это заставит разработчиков гном и кде подправить эти сопли... тогда и на других фс будут работать и быстрее, и надёжней.
| | |
| |
| 3.19, User294 (??), 17:29, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | А по-моему не очень Понижение надежности работы ФС приветствовать имхо нельзя В ... большой текст свёрнут, показать | | |
| |
| 4.26, vitek (??), 18:40, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
т.е. пишите глюкавые программы! это позволяет отслеживать ошибки в фс и не только! :-D
это хорошо, что в понедельник тестирование беты убунту провели. и видимо хорошо, что много желающих откликнулось... а так сидели бы с релизом... и битой фс.
резюмирую. тестирование должно носить системный характер. для системных вещей уж точно.
| | |
| |
| 5.37, User294 (??), 19:23, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>резюмирую. тестирование должно носить системный характер. для системных вещей уж точно.
Как по мне так убунтуйцам надо спасибо сказать за ранний отлов грабель.Данный трабл может привести к тому что файлы будут втихаря засираться при рестартах а юзер об этом узнает только когда засрется столько файлов что это зацепит что-то нужное юзеру.А тогда обычно уже поздно пить боржоми...
| | |
| |
| 6.43, vitek (??), 19:35, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Как по мне так убунтуйцам надо спасибо сказать за ранний отлов грабель.
именно.
| | |
| 6.44, vitek (??), 19:39, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Данный трабл может привести к тому что файлы будут втихаря засираться при рестартах а юзер об этом узнает только когда засрется столько файлов что это зацепит что-то нужное юзеру
это происходит только если есть прога, которая работает с ними через анальное отверстие.
бьются не все подряд файлы.
| | |
| |
| 7.50, User294 (??), 19:56, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>это происходит только если есть прога, которая работает с ними через анальное
>отверстие.
Боюсь что если такая ФС пойдет в массы - мы узнаем много нового о привычном софте и его методах работы с файлами.Ты именно этого хочешь, да?Сидеть и чесать репу какого черта там-то и там-то просралось вон то и вон это?Я что-то сомневаюсь что юзеров сильно утешит осознание факта что их любимые программы оказывается неидеально работают с файлами :).Раньше то данные не просирались... ;)
| | |
| |
| 8.82, vitek (??), 23:03, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | ну я и так о нём не мало знаю одно кде чего стоит вот и палинух своему другу... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.10, XoRe (ok), 16:48, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Имхо, это больше кирпич в огороды Ubuntu, Gnome и KDE, чем в огород ext4.
Во первых, в ext4 отложенное распределение (delayed allocation) можно и отключить.
Во вторых, такой способ оптимизации (delayed allocation) есть не только в ext4.
В третьих, "крах системы" - это не нормальное состояние.
Это все равно что сказать: все современные ОС ненадежны - если тыкать в кнопку RESET в случаном порядке, есть шанс потерять данные.
Вообще обнуление файлов при перезаписи, связанное с отложенно записью - это не такая уж новость.
Это вполне логичное следствие возможных последствий отложенной записи (когда возникает сбой или когда компьютер резко выключается/перезагружается).
И это вполне может лечиться на уровне приложения.
Например, можно открывать файл для записи как раз перед записью.
А не так, что fopen(...), подумали, посчитали, вычислили, что будем писать, потом printf, потом ещё подумали, потом fclose.
Ещё можно указать синхронизировать данные для только что записанного файла (что-то типа sync).
Может программистам KDE и Gnome стоит переделать способы работы с конфиг файлами?
P.S.
Я бы изменил название новости на "Проблемы с потерей данных на Ubuntu 9.04 с дефолтными настройками".
| | |
| |
| 2.22, User294 (??), 18:17, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Да, все пи сы, а вот ext4 Д Артаньян А пардон, почему у ext3 таких граблей нет... большой текст свёрнут, показать | | |
| |
| 3.115, vitek (??), 15:51, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>P.S.
>>Я бы изменил название новости на "Проблемы с потерей данных на Ubuntu
>>9.04 с дефолтными настройками".
>А вы - кто такой чтобы за всех решать?И кстати, как я
>помню, в убунте EXT4 - не дефолтная ФС, но выбрать ее
>при инсталле тем не менее можно.И то что оно себя по
>дефолту (ext4 а не убунтов) так ведет не есть гуд.Так что
>давайте названия будет менять кто-то покомпетентнее в вопросе чем вы, ага?
если ext3 считается надёжной только потому, что додумались ставить по-умолчанию data=ordered, то новость именно так и должна звучать, т.к. с такими же настройками и ext4 не менее надёжна..... хоть и не проверена временем.
кстати, а что за барский вопрос:
>А вы - кто такой чтобы за всех решать?
давайте проголосуем! :-D
| | |
|
| 2.56, Аноним (56), 20:09, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>В третьих, "крах системы" - это не нормальное состояние.
>Это все равно что сказать: все современные ОС ненадежны - если тыкать
>в кнопку RESET в случаном порядке, есть шанс потерять данные.
микроядро - и заветную кнопку можно исключить из аппаратуры на...
| | |
| |
| 3.90, User294 (??), 23:28, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>микроядро - и заветную кнопку можно исключить из аппаратуры на...
А Чубайса ты куда денешь, умник?Или ты морально готов купить всем упсы за свой счет?Или может микроядро превратится при слете питания в дизель-генератор?Если вы не поняли - я кнопкой ресет и с обычным линуховым ядром не пользуюсь - в релизных версиях системы оно не падает, пардон, месяцами.Что не мешает например чубайсовской шараге срубать питалово.Ну и прочая.И микроядро ну вообще никак не поможет в этих случаях.А если вы считаете что в этом случае система имеет право подохнуть - пройдите на http://lleo.aha.ru/na - вас юзеры с такой системой которая при внеплановом рестарте херит данные отправят именно туда.
| | |
|
| 2.104, zzz (??), 12:07, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Во вторых, такой способ оптимизации (delayed allocation) есть не только в ext4.
>Вообще обнуление файлов при перезаписи, связанное с отложенно записью - это не такая уж новость.
>Это вполне логичное следствие возможных последствий отложенной записи (когда возникает сбой или когда компьютер резко выключается/перезагружается).
Ну вот на Reiser4 тоже использует отложенную запись, только почему-то подобных казусов с ней не происходит. Наверное из-та того, что Reiser4 это "неправильная" FS ? =D
| | |
| |
| 3.105, User294 (??), 12:40, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну вот на Reiser4 тоже использует отложенную запись, только почему-то подобных казусов
>с ней не происходит. Наверное из-та того, что Reiser4 это "неправильная"
>FS ? =D
К рейзерам у юзерей по жизни масса предъяв почему-то.Третий рейзер вообще зачотная штука.На сайте amule.org можно посмотреть на очередных юзерей^W админов радостно констатирующих тотальный дестрой фс у себя на серваке.Там очень колоритные коменты по части того что перец думает о рейзере :).В общем такое ощущение что в рейзере уделили маловато внимания утилитам починки фс.А юзеру как-то пофиг на плюсы фс если она может развалиться а родные утили спасуют.
| | |
| |
| 4.107, zzz (??), 13:34, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>На сайте amule.org можно посмотреть на очередных юзерей^W админов радостно констатирующих тотальный дестрой фс у себя на серваке.
amule.org -> "No DNS records" - как бы намекает на то, что это было давно или неправда
>А юзеру как-то пофиг на плюсы фс если она может развалиться а родные утили спасуют.
ну шансов развалиться у reiserfs (с учетом проверок в драйвере) куда меньше, чем у той же ext3
| | |
| |
| 5.120, vitek (??), 16:13, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
проверок у ext3 не меньше.
fresco подтвердит... :-)
его то мнению Вы доверяете? у него очень не плохие статьи по фс.
| | |
| |
| |
| |
| 8.134, vitek (??), 19:04, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | ну тогда и я ещё раз - оттуда же ext3 recovery For most detected errors, ex... большой текст свёрнут, показать | | |
| |
| 9.137, zzz (??), 01:14, 14/03/2009 [^] [^^] [^^^] [ответить] | +/– | там ещё четко написано относительно проверок на ошибки при записи, но кто-то поч... текст свёрнут, показать | | |
|
|
| 7.127, vitek (??), 17:28, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | да читал я эту статью уж и не помню сколько лет назад по-моему в 2005 вывод... большой текст свёрнут, показать | | |
| |
| 8.138, zzz (??), 01:26, 14/03/2009 [^] [^^] [^^^] [ответить] | +/– | часть идей из ixt3 перекочевала в ext4 на самом деле те же jounral checksums н... текст свёрнут, показать | | |
| |
| 9.142, vitek (??), 12:48, 14/03/2009 [^] [^^] [^^^] [ответить] | +/– | о чём и речь именно этого и ждут от ext4 и что интересно не ждут от ext3 ссыл... большой текст свёрнут, показать | | |
| |
| 10.144, zzz (??), 13:42, 16/03/2009 [^] [^^] [^^^] [ответить] | +/– | Это никому не нравится, но это политика reiserfs относительно сохранности данных... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 3.118, vitek (??), 16:10, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
особенно это не происходит на десктопах... с активно работающими гном и кде...
наверное потому, что процент таких машин с рейзером4 от машин с экст3 стремиться к нулю.
| | |
| |
| 4.122, zzz (??), 16:36, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>наверное потому, что процент таких машин с рейзером4 от машин с экст3 стремиться к нулю.
Тем не менее, ни я, ни кто другой и байта подобным образом не потерял за все время пользования reiser4 (ну если брать последний год-два). Хотя одно время даже старался, делал ресеты во время интенсивной работы fs. Наверное я что-то делаю не так =)
| | |
| |
| |
| 6.145, zzz (??), 13:43, 16/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>тоже самое с ext3.
>а если нет разницы, то... дося. :-D
В ext3 нет delayed allocation, да и reiser4 она не конкурент
| | |
|
|
|
|
|
| 1.11, Thorn (??), 16:53, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"? Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! Зачем ещё какие-то параноидальные "повышения надёжности"?
Крах системы - это какой-то нонсенс. Падать должны гномики, а дисковая система работать на ура. Проблему надумали?
| | |
| |
| 2.13, Анонимус (?), 17:08, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
ЧЕстно говоря, даже отвечать лень. Почитай вики про журнал, что ль...
У меня система действительно не падало ОЧЕНЬ давно... хотя убунту упала почти сразу после установки))) (вроде 8.10)
ПС. Это бета или альфа, так что крах для неё - это норма...
| | |
| |
| 3.34, vitek (??), 19:17, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ПС. Это бета или альфа, так что крах для неё - это норма...
во истину так.
| | |
|
| 2.15, Аноним (-), 17:13, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Проблема есть, была и будет. Суть ее в кэшировании. А что именно отвалится если кэш или часть кэша не сброшена - все равно. Не хотите явно управлять современными сложнейшими устройствами, где надо делать fsync и прочее ? Хочется чтоб все "по волшебству" работало, как будто данные из регистров процессора пишутся сразу на поверхность жесткого диска? Ну тогда не нойте, или надежно будет или быстро, выбирайте что лучше для вас.
| | |
| 2.20, Аноним (56), 17:43, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"?
>Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля!
Не понимаешь - читай книжки ))
«Системная инфа» это называется метаданные, и они обновляются не атомарно. Надо писать в нескольких местах (поменять директорию, пометить блок как занятый). Если сбой происходит в момент обновления, (например блоки данных помечены как занятые, а в директорию изменения не записаны), то файловая система в противоречивом положении.
Без журнала надо проверять всю файловую систему, а журнал позволяет БЫСТРО найти то место где была работа во время сбоя и исправить его.
| | |
| 2.25, User294 (??), 18:39, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>работать на ура. Проблему надумали?
На самом деле трабл в том что ФС печется о валидности метаданных а что по факту случится с файлом и юзерскими данными в нем ей как бы это помягче сказать, глубоко фиолетово.И это неизбежно ведет к потере данных.И не то чтобы это следует приветствовать, ОСОБЕННО если это ведет к вот такому откровенному просеру данных.
| | |
| |
| 3.32, _umka_ (ok), 19:02, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | можно еще вспомнить что в современных HDD а уж тем более в SCSI SAS контроле... большой текст свёрнут, показать | | |
| |
| 4.45, User294 (??), 19:42, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | Вообще, насколько я помню, нынче все порядочные жесткие диски и драйвера контро... большой текст свёрнут, показать | | |
| |
| 5.48, darkk (?), 19:51, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Некоторые ограничивают размер своего кэша на запись кстати - из 32 мегов
>на *запись* может юзаться и меньше чем 32 мега.
А зачем в самом винте буфер на чтение? С readahead вроде система неплохо справляется, нет?
| | |
| |
| 6.92, User294 (??), 23:36, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А зачем в самом винте буфер на чтение? С readahead вроде система
>неплохо справляется, нет?
Не у всех есть readahead, особенно пока система только грузится, etc.
Еще харду его истинная геометрия виднее.Может умудряются что-то оптимизнуть на основе этого знания?Система то видит это как линейный массив или совершенно левые CHS, особенности физики она не знает.А вот фирмвара контроллера в курсе истинной картины.
| | |
|
| 5.101, _umka_ (ok), 10:02, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Сделав то что вы говорите - вы убьете процентов 40 произ... большой текст свёрнут, показать | | |
|
|
| 3.40, Аноним (56), 19:26, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>На самом деле трабл в том что ФС печется о валидности метаданных
>а что по факту случится с файлом и юзерскими данными в
>нем ей как бы это помягче сказать, глубоко фиолетово.
Это не трабл. Это ОЖИДАЕМОЕ поведение операционной системы. О данных программы должна заботится сама программа. За подробностями смотри man 2 write, когда данные реально пишутся на диск, и как программа может этот процесс контролировать.
>И это неизбежно ведет к потере данных.
Неизбежно только для кривого софта. postgresql и на xfs данные не теряет при внезапном выключении, потому что делает всё правильно, как положено.
>И не то чтобы это следует приветствовать, ОСОБЕННО
>если это ведет к вот такому откровенному просеру данных.
Кривой софт должен быть исправлен или выброшен.
| | |
| |
| 4.113, User294 (??), 15:42, 13/03/2009 [^] [^^] [^^^] [ответить] | +/– | Если вы хотите юзать операционку которая норовит поднасрать - это ваше право А я... большой текст свёрнут, показать | | |
|
|
| 2.27, Tim (??), 18:49, 12/03/2009 [^] [^^] [^^^] [ответить] | +/– | IMHO во FreeBSD это называется SoftUpdate 1 технология журналирования уже расP... большой текст свёрнут, показать | | |
| |
| 3.39, _umka_ (ok), 19:25, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля!
>
>IMHO во FreeBSD это называется SoftUpdate.
>
только в extXXX - журнал на диске в специальной inode.
а в FreeBSD - это в памяти, а в остальном функциональность похожая.
Поэтому после падения - в ext можно что-то прочитать, а в freebsd - этого нету.
Но в FreeBSD добавили журналирование через GEOM (geom_journal) - насколько я понял это полное журналирование данных и лучше такое держать на внешнем девайсе.
| | |
| |
| 4.77, Tim (??), 22:42, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>> Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля!
>>
>>IMHO во FreeBSD это называется SoftUpdate.
>>
>
>только в extXXX - журнал на диске в специальной inode.
>а в FreeBSD - это в памяти, а в остальном функциональность похожая.
Работа extXXX классическая -
1) отметка в журнале "начало операции"
2) выполнение операции (обычно группируются в пакеты для производительности)
3) отметка в журнале "завершение операции"
При сбое: чтение журнала и откат до валидного состояния.
IMHO основная идея SoftUpdate выполнять изменения метаданных в таком _порядке_, чтобы состояние ФС на _диске_ всегда было валидным! Основной упор делается на _порядок_ изменений.
PS. Подробности реализации этого чуда во FreeBSD я незнаю (не интересовался),
по-этому судить о сильных/слабых сторонах не могу.
PPS. Вероятно я ошибаюсь, ушел искать FM по SU ;-)
| | |
| |
| 5.102, _umka_ (ok), 10:13, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>>
>>>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 которая искуственно подпитывается.
| | |
| |
| 6.108, Tim (??), 14:02, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>тут разное, бывает журналирование обновлений блоков метаданных, бывает всего.
>главная задача создать правильный порядок обновления - как вобщем-то и SU.
Нет, вы неправы.
В журналированных ФС порядок операций в составе одной транзакции практически неважен. (Транзакция атомарна по определению и может только выполнится или откатится.) По-этому реализация и главное отладка значительно проще.
>не откат а journal replay. операции из журнала применяются повторно - чем
>гарантирует что по концу журнала FS будет +/- не противоречиво.
Отложенная транзакция - более ресурсоемко, чем откат незавершенной транзакции.
И применяется только в работе с распределенной базой данных.
Использование механизма отложенной транзакции в ФС избыточно по функциональности и значительно снижает производительность подсистемы.
>что это тот же журнал - только в памяти. для ext
Нашел прекрасное описание SU написанное McKusick'ом. Если в кратце:
1) изменения метаданных записывается в кэш (как и в extXXX)
2) строится граф зависимостей этих изменений
3) сортируется (топологическая сортировка)
4) выполняется по порядку
McKusick указал на два основных недостатка:
1) это сложность реализации (и соответсвенно отладки)
2) возможность утечки свободного дискового пространства при сбоях
Второй пункт рекомендует лечить фоновым fsck
| | |
| |
| 7.154, nuclight (ok), 22:37, 21/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
 По сути, если смотреть максимально обще, то фревый SostUpdates - это действительно такой специфический журнал, только существующий исключительно в памяти. И при сбое он теряется, то есть всегда выполняется rollback транзакций.
>McKusick указал на два основных недостатка:
>1) это сложность реализации (и соответсвенно отладки)
>2) возможность утечки свободного дискового пространства при сбоях
>Второй пункт рекомендует лечить фоновым fsck
Да, именно сложность реализации и составляет основную проблему, а сама идея неплоха. Второй пункт появляется, поскольку на диске реального журнала нет, и если сбой случится в окно записи на диск, то будет ошибка. Однако SU построен таким образом, что класс таких ошибок очень ограничен (по большому счету пропажа места, ага), потому с введением бэкграундного fsck систему можно запускать сразу же на непроверенной fs, очень удобно, в отличие от форсированных проверок "180 дней на ext3 без fsck". Журнал не панацея, хехе.
В общем, идея, повторюсь, неплоха, и вполне конкурентоспособна с журналом. Вот только из-за сложности реализации имеются проблемы - например в NetBSD с кодом задолбались и будут SU выкидывать. Печальный пример, как плохая реализация может убить хорошую идею.
| | |
|
|
|
|
|
|
| 1.29, Султан (?), 18:58, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А почему этой проблеме подвержена в том числе и btrfs? Разве оно не copy-on-write?
| | |
| |
| 2.49, yalur (ok), 19:54, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Во-во, что то у меня на zfs такого никогда не наблюдается, хоть уже полтора года юзаю вместе с KDE.
| | |
| |
| 3.83, vitek (??), 23:07, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
оракле туда пихни... или постгрес... развлечения обеспечены.
при том, что она ещё и ресурсов жрать будет больше их вместе взятых (на нагрузке конечно)
| | |
|
|
| 1.53, Аноним (-), 20:00, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> при которой данные и мета-данные могут
>оставаться незаписанными до 60 секунд.
>
>Данная возможность является одним из главных факторов значительного повышения производительности ext4 по
>сравнению с ext3.
man /proc/sys/vm :E
| | |
| 1.59, Breg (??), 20:44, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Бок 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 для большого объемы данных, то оно само в этот момент не отвечает, да еще и другим не дает записать данные, из-за чего и они не отвечают.
| | |
| |
| 2.155, nuclight (ok), 12:42, 27/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Это опять таки проблемы реализации некоторых линуксовых fs, а не приложения. На нормальных fs будет fsync только конкретного файла, он не поставит всю систему раком в ожидании. В POSIX всё-таки 2 разных системных вызова - fsync() для одного файла и sync() для всей системы.
| | |
|
| 1.62, Аноним (-), 21:20, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Разбор ситуации показал, что при
>загрузке KDE и GMOME пересоздают большое число мелких файлов, и если
>системный крах произойдет через небольшое после загрузки время, эти файлы окажутся
>обнуленными (в журнал изменения вносятся сразу, но сами данные на диск
>записаться не успевают). ...
Собственно, а при чем здесь ФС. Или вы хотели и на диск не писать, и при отключении эл-ва чтобы все сохранялось? Покупайте ИБП.
>Тем не менее Ted пообещал выпустить патч, изменяющий поведение отложенной записи в ext4 при фиксировании фактов обнуления или переименования файлов.
Может быть полезно, главное, чтобы было опционально. Кому-то может оно и не нужно.
| | |
| 1.65, Аноним (-), 21:28, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Да, ребятки, что-то тут народ совсем жиденький. :( Хочу обратно на лор. Верните анонимуса!
По теме: проблема лишь одна - режим отложенной записи не доллжен быть включен по умолчанию. Вот и все.
| | |
| |
| 2.66, darkk (?), 21:30, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>По теме: проблема лишь одна - режим отложенной записи не доллжен быть
>включен по умолчанию. Вот и все.
А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-)
| | |
| |
| 3.67, Аноним (-), 21:49, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-)
5 секунд, на файлопомойке с большой дисковой активностью на запись ) - минута. А в чем проблема, буферизация нах. Можно и sync на каждый чих делать. Еще проще применять аппаратные решения. О чем разговор то? Хотите абсолютной надежности? Дык какого-хрена ЭВМ типа "домашний" пользуете, для этого есть специализированные решения.
| | |
| |
| 4.85, vitek (??), 23:10, 12/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>А чему у вас равно $(sysctl vm.dirty_writeback_centisecs) ? ;-)
>
>5 секунд, на файлопомойке с большой дисковой активностью на запись ) -
>минута. А в чем проблема, буферизация нах. Можно и sync на
>каждый чих делать. Еще проще применять аппаратные решения. О чем разговор
>то? Хотите абсолютной надежности? Дык какого-хрена ЭВМ типа "домашний" пользуете, для
>этого есть специализированные решения.
не пользуем, а рассуждаем.... интересно.
где ты ещё увидишь такое бурое обсуждение беты убунты? :-D
| | |
|
|
|
| 1.93, Дмитрий Ю. Карпов (?), 23:57, 12/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я так и не понял, зачем при старте (даже не при окончании работы, а при старте) надо создавать много мелких файлов (когда можно создать один большой), да ещё и перезаписывать конфиг! Интересно, как эта система может работать с LiveCD?
| | |
| 1.97, Андрей (??), 06:02, 13/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Что-то мутное - эти системы конфигурации KDE и gnome. Из-за них я не пользуюсь ни KDE, ни gnome'ом.
Пусть они Elekta'у попробуют для конфигов - тогда не будет таких проблем.
| | |
| 1.100, fresco (??), 09:50, 13/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
ну накинулись на файловиков.
любая файловая система, располагающая механизмом delayed allocation, при сбое в момент интенсивной записи получит сходные проблемы. в той или иной мере это справедливо для XFS, JFS, ZFS, btrfs, ext4. решением тут может стать монтирование с -o sync, использование режима data=ordered в ext4 и btrfs, или применение vfat/ext2 -- словом, отказ от серьезного повышения производительности.
понятно даже и ежу -- корень проблемы не в реализации конкретной ФС, в самом механизме отложенного размещения. любому, кто сделал над собой усилие и разобрался в алгоритмах работы современных файловых систем, это совершенно ясно уже много лет. критична надежность -- покупайте UPS, используйте простые ФС или синхронные режимы работы диском.
а в данной ситуации, ИМХО, виноваты исключительно кодеры KDE/GNOME, не корректно обрабатывающих конфиги. можно понять ubuntu-юзеров, которые не хотят разбираться, а хотят работать. но программистов, прекрасно понимающх последствия такой беспечности, я оправдать не могу.
| | |
| |
| 2.103, XoRe (ok), 11:21, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>понятно даже и ежу -- корень проблемы не в реализации конкретной ФС,
>в самом механизме отложенного размещения. любому, кто сделал над собой усилие
>и разобрался в алгоритмах работы современных файловых систем, это совершенно ясно
>уже много лет. критична надежность -- покупайте UPS, используйте простые ФС
>или синхронные режимы работы диском.
>
>а в данной ситуации, ИМХО, виноваты исключительно кодеры KDE/GNOME, не корректно обрабатывающих
>конфиги. можно понять ubuntu-юзеров, которые не хотят разбираться, а хотят работать.
>но программистов, прекрасно понимающх последствия такой беспечности, я оправдать не могу.
>
+1
Рад вашему ходу мыслей.
2 User294:
Я понял, что вам не нравится ext4.
А вообще, этой новости, как и обсуждения не случилось бы при любом из 2 условий:
1. В KDE/Gnome лучше бы относились к своим конфигам.
2. В Ubuntu 9.04 по дефолту в ext4 было бы отключено delayed allocation.
Первое желательнее, второе реальнее.
| | |
| 2.106, uldus (ok), 12:47, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>понятно даже и ежу -- корень проблемы не в реализации конкретной ФС,
Разница в реализации огромная - в одном случае получим после сбоя пустые файлы, а в другом файлы со старым содержанием.
| | |
| 2.109, zzz (??), 14:27, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>любая файловая система, располагающая механизмом delayed allocation, при сбое в момент интенсивной записи получит сходные проблемы. в той или иной мере это справедливо для XFS, JFS, ZFS, btrfs, ext4. решением тут может стать монтирование с -o sync, использование режима data=ordered в ext4 и btrfs, или применение vfat/ext2 -- словом, отказ от серьезного повышения производительности.
Решение этой проблемы - атомарность, когда несколько действий с файлом объединяются в один атом. Задача драйвера fs в данном случае - максимально корректно строить эти атомы, чтобы эффективно минимизировать число записей в журнал, и минимизировать потерю данных.
| | |
| |
| 3.123, vitek (??), 16:50, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
есть только один вопрос - как эту атомарность обеспечить? по каким критериям?
в транзакциях понятно. известно её начало, контрольные точки и завершение.
не говоря о том, что все эти процессы длятся во времени:
1. 15:00 - открыл файл
2. 15:10 - обнулил
3. 16:00 - записал новые данные
будем хранить данные 50 минут?
ладно. проверку на 0 встроят. но это не панацея.
в конце концов фс - это не субд... может быть пока не субд.
| | |
| |
| 4.126, Thorn (??), 17:11, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>есть только один вопрос - как эту атомарность обеспечить?
Никак. Долго открытый файл - это проблема приложения, ставящего под риск свои данные.
| | |
| |
| 5.133, vitek (??), 18:33, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
в том то и дело - как долго? сейчас - 60 секунд. всё остальное - долго.
если свести к 0. то получим ordered как в ext3. :-)
конечно, мой пример мягко говоря экзотичен,... но не невозможен. и просто для иллюстрации.
| | |
|
| 4.128, zzz (??), 17:45, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>1. 15:00 - открыл файл
>2. 15:10 - обнулил
>3. 16:00 - записал новые данные
>будем хранить данные 50 минут?
Корень текущей обсуждаемой проблемы - открытие на запись непустого файла с флагом O_TRUNC. Т.е. до форсированной записи данных (по таймауту, давлению, принудительно - как угодно) или закрытия файла можно было бы вообще ничего не делать, а держать изменения в пямяти. А дальше записать транзакцию, результат которой - старый файл или новый. Но не промежуточное состояние, которым является открытие файла с любым флагом. И в нашем случае интервалы не десятиминутные.
| | |
| |
| 5.131, vitek (??), 18:18, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Корень текущей обсуждаемой проблемы - открытие на запись непустого файла с флагом O_TRUNC.
вот именно. объединяем 1-й и 2-ой пункты. получаем 1 час :-D
дальше программа готовит данные (время окончания в общем случае не известно) или порционно скидывает на диск (что ещё хуже).
>Т.е. до форсированной записи данных (по таймауту, давлению, принудительно - как угодно) или закрытия файла можно было бы вообще ничего не делать, а держать изменения в пямяти.
ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение?
а программистам из гном, кде,.. выслать инструкции о правильной форсированной записи данных? :-DDDDDD и опять полагаемся на их добросовестность?
а результат - критериев нет, множества контрольных точек нет, факта окончания транзакции нет. время окончания транзакции в общем случае не известно. объём необходимой памяти для хранения изменений не известен (а хранить надо все, что пытаются удалить... а если записали только 1-ю порцию? удаляем?.. но ведь пустой конфиг не многим хуже, чем наполовину заполненный - хрен будет работать после сбоя... значит храним до close?... а тогда и часом не отделаешься!!!)
описываемые Вами требования решают различные СУБД. и то! с переменным успехом. а мы говорим о фс, которая предположительно будет устанавливаться от смартфонов с нетбуками до самых экзотичных устройств.
| | |
| |
| 6.136, zzz (??), 01:07, 14/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>вот именно. объединяем 1-й и 2-ой пункты. получаем 1 час :-D
нет, есть ведь т.н. время жизни транзакции
>ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение?
ядро
>а программистам из гном, кде,.. выслать инструкции о правильной форсированной записи данных? :-DDDDDD и опять полагаемся на их добросовестность?
fsync достаточно, иначе система будет кешировать все, что только можно и как можно дольше, к примеру
>а результат - критериев нет, множества контрольных точек нет, факта окончания транзакции
>нет. время окончания транзакции в общем случае не известно. объём необходимой
>памяти для хранения изменений не известен
кешировать все, пока не закончится дисковый кеш или не превысим некоторый утановленный лимит dirty-буферов
>(а хранить надо все, что пытаются удалить...
с wandering logs и это не проблема
>а если записали только 1-ю порцию? удаляем?.. но ведь
>пустой конфиг не многим хуже, чем наполовину заполненный - хрен будет
>работать после сбоя... значит храним до close?... а тогда и часом
>не отделаешься!!!)
если запишется только часть данных - это нормально, а вот обнулять кучи файлов - ненормально.
>описываемые Вами требования решают различные СУБД. и то! с переменным успехом.
в т.ч. reiser4, с постоянным успехом =)
>а мы говорим о фс, которая предположительно будет устанавливаться от смартфонов с нетбуками до самых экзотичных устройств.
редко кто ext3 ставит на подобную экзотику, не говоря уже о ext4, которую еще пилить и пилить годами
| | |
| |
| 7.143, vitek (??), 16:48, 14/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>нет, есть ведь т.н. время жизни транзакции
это уже не транзакция, а извиняюсь порнография. основное достоинство oracle - время жизни транзакции определяется исключительно бизнес-требованиями.
>>ну и кто должен держать изменения в памяти? фс (читай ядро)? приложение?
>ядро
э-э-э нет. такой хоккей нам не нужен.
>если запишется только часть данных - это нормально, а вот обнулять кучи файлов - ненормально.
вот этого мне уж ТОЧНО не надо. ситуация будет ещё хуже и ещё менее диагностируема.
пусть это будет в рейзере или ещё где.... так сказать для любителей.
| | |
| |
| 8.146, zzz (??), 13:56, 16/03/2009 [^] [^^] [^^^] [ответить] | +/– | смотри те же исходники jbd, reiserfs там это понятие определено как commit_timeo... текст свёрнут, показать | | |
| |
| 9.149, vitek (??), 15:01, 16/03/2009 [^] [^^] [^^^] [ответить] | +/– | а я где то писал, что в восторге от текущего положения во всех журналируемых фс ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.125, Thorn (??), 17:09, 13/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ребят, а нельзя ли взять лучшее от обоих миров? Скажем, есть некий архив-сетап. Если он распаковывает файлы, нам ПОФИК что и как там распакуется, т.к. его всегда можно распаковать заново. Тогда разархиватор даёт команду системе: запиши эти файлы, но они не очень важны - можешь держать в кэше. А если это, скажем, СУБД - она так строго и говорит: "запиши немедленно!". Т.е. драйвер ФС будет иметь несколько типов записи, какой хочешь - такой и выбирай.
| | |
| |
| 2.132, vitek (??), 18:28, 13/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
в том то и проблема.
есть определённые системные вызовы по работе с файлами... они работают годами... и есть куча приложений, которые именно так (и только так) работают.
грубо выражаясь они все как в приведённом Вами примере - СУБД... и все так строго и говорят - "запиши немедленно!"... а потом подтверждают ещё по делу и без - flush...
а ещё есть асинхронный ввод-вывод...
| | |
|
| 1.139, Аноним (-), 01:42, 14/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
кто знает при data=journal delayed allocation?
мне скорость понравилась как у ext3 data=ordered и этого глюка нет.
| | |
| |
| 2.140, Аноним (-), 01:42, 14/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>кто знает при data=journal delayed allocation?
>мне скорость понравилась как у ext3 data=ordered и этого глюка нет.
работает delayed allocation?
| | |
|
| 1.150, XoRe (ok), 17:45, 16/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ребят, чего париться - отключаем delayed allocation и все, что может привести к обнулению и радуемся)
| | |
|
