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

Проблемы с потерей данных на Ext4 разделах в тестовой версии..., opennews (??), 12-Мрт-09, (0) [смотреть все] Вот И это, в частности, плохо , Ivan (??), 16:06 , 12-Мрт-09, (1) // А я в упор не понимаю, в чём проблема, освещенная в новости Кого-то удивляет, чт, darkk (?), 19:28 , 12-Мрт-09, (41) // ну хоть один вразумительный коммент , vitek (??), 19:50 , 12-Мрт-09, (47) // Если сходить по ссылке дважды 8212 можно найти ответ на глупый вопрос 171 а, darkk (?), 19:59 , 12-Мрт-09, (52) можно пока по ссылке не ходил, но с ним многое не так начиная от фрагментаци, vitek (??), 22:13 , 12-Мрт-09, (71) У Юниксовой проги вообще не должно быть конфига Это от врагов, из M ДОС и OS , pavlinux (ok), 03:18 , 13-Мрт-09, (95) Да, давайте еще у init стартовые скрипты отнимем , User294 (??), 14:48 , 13-Мрт-09, (110) init-скрипты не конфиги и уж точно не перезаписываются во время загрузки аминь, vitek (??), 19:07 , 13-Мрт-09, (135) Это смотря с какой стороны посмотреть Зато перезаписываются при установке удал, User294 (??), 19:01 , 16-Мрт-09, (151) нагрузка на фс при установке ни в какое сравнение не идёт с загрузкой это перв, vitek (??), 22:13 , 16-Мрт-09, (153) ,,,хм молодец, сразу нашел отговорку - виноват пользователь,,,,,, - ужас чело, друг pavlinux (?), 16:17 , 12-Мрт-09, (2) // А че вы так, собственно, бурно реагируете Не нравится - не пользуйтесь , Аноним2 (?), 16:45 , 12-Мрт-09, (8) // Ага, круто Сначала у юзеров нутся данные а потом - они и не будут использовать, User294 (??), 17:10 , 12-Мрт-09, (14) // операционка и не дохнет вернее дохнет, но не от этого дохнут файлы и то тольк, vitek (??), 18:58 , 12-Мрт-09, (30) Ну, с точки зрения юзера - система сыграла в ящик от слета питания Надежность Ха, User294 (??), 19:20 , 12-Мрт-09, (35) именно вот это и надо обсуждать читаем внимательно новость и видим слово ordered, vitek (??), 19:32 , 12-Мрт-09, (42) Моя имха если в старой ФС что-то работало без потерь данных а в новой - данные , User294 (??), 19:50 , 12-Мрт-09, (46) Эм Это не журналирование на уровне приложений, это правильный метод работы В, darkk (?), 19:56 , 12-Мрт-09, (51) это неправильный метод работы для приложения запись файла можно считать почти ат, . (?), 20:21 , 12-Мрт-09, (57) Эмм Ну а как вы предлагаете решать ту самую задачу с нехваткой диска А ведь , darkk (?), 20:23 , 12-Мрт-09, (58) По нормальному - проверив сколько места на ФС есть _до_ начала записи файла Если, User294 (??), 20:57 , 12-Мрт-09, (60) Да, с точки зрения пользовательского интерфейса, не писать, если нет места - чуд, darkk (?), 21:12 , 12-Мрт-09, (61) Все так, но вероятность нарваться на эту ситуацию очень мала К тому же можно про, User294 (??), 21:54 , 12-Мрт-09, (69) Аккуратно и вдумчиво прочел баг и ответ Теодора Я, конечно, извиняюсь но вот так, User294 (??), 22:12 , 12-Мрт-09, (70) Во-первых, config registry Во-вторых, БД отличается от ФС задачами довольно с, darkk (?), 22:25 , 12-Мрт-09, (73) 100на время жизни программы приложение запущенное на выполнение это величина , vitek (??), 22:42 , 12-Мрт-09, (76) Что вы этим хотели сказать Я хотел сказать что сбагривать проблему с похеривание, User294 (??), 22:56 , 12-Мрт-09, (80) Только то, что конфиг 8212 ведь постоянная, а база 8212 изменчивая Люд, darkk (?), 06:44 , 13-Мрт-09, (99) Есть конфиги которые часто меняются И есть неизменчивые базы Скажем CDB - вообще, User294 (??), 15:23 , 13-Мрт-09, (111) Конечно, вероятность аппаратного сбоя и повреждения структур ФС тоже невелика К, darkk (?), 22:17 , 12-Мрт-09, (72) блин ребята речь не о методах обновления файлов эта херь почему-то встречается, vitek (??), 22:34 , 12-Мрт-09, (74) Да Например, есть вероятность что все молекулы воздуха резко улетят в другую ком, User294 (??), 23:09 , 12-Мрт-09, (84) ну наедь на бздишников с софтапдейтом вон, ниже тусуются не правда патч то б, vitek (??), 23:17 , 12-Мрт-09, (87) Это работает _только_ в однозадачной системе Hint свободное место _до_, _вовре, Tim (??), 21:50 , 12-Мрт-09, (68) fsyncВот я делаю creat file tmp write fsync close rename file tmp , fil, const86 (ok), 22:48 , 12-Мрт-09, (78) точно , vitek (??), 22:52 , 12-Мрт-09, (79) POSIX позволяет пустую реализацию fsync Пример MacOSX Если у вас SSD или ноу, Volodymyr Lisivka (?), 02:10 , 14-Мрт-09, (141) Я сердечно поздравляю юзеров макоси с этим фактом Не думаю что он их напрягает Е, User294 (??), 19:19 , 16-Мрт-09, (152) Так точно - darkk уже указал мне на этот ляп И вы добавить хотите Признаю недосм, User294 (??), 23:14 , 12-Мрт-09, (86) а ведь придется -DDDDDDDDDDDDDDDDDDDDDdда и удивляться не чему чем сложнее си, vitek (??), 20:03 , 12-Мрт-09, (54) вертя перед монитором фигой это вы сами как-нить, без меня А я лучше ext3 поюз, User294 (??), 21:22 , 12-Мрт-09, (63) этим всякие Оффисы активно занимаюьтся потихоньку распложая свои темпы, а апосл, Filosof (?), 17:50 , 13-Мрт-09, (129) Ну не знаю, по ссылке чувак пишет Also some of my MySQL databases were killed , yalur (ok), 20:03 , 12-Мрт-09, (55) MyISAM , const86 (ok), 22:41 , 12-Мрт-09, (75) пипец ну и кем она килед читайте новость там система ПАДАЕТ то что патч добав, vitek (??), 22:58 , 12-Мрт-09, (81) Ну вот журналы и транзакции изначально и были нужны чтобы это не создавало пробл, User294 (??), 23:21 , 12-Мрт-09, (88) после транзакции всегда идёт commit или rollback здесь же нет ни начала тразакци, vitek (??), 15:33 , 13-Мрт-09, (112) Да, я и не спорил - большей части ФС глубоко положить на состояние файла после к, User294 (??), 15:51 , 13-Мрт-09, (114) на самом деле важно не это важный вопрос, как всегда за кадром по теме - поч, vitek (??), 16:03 , 13-Мрт-09, (117) Что за дурь, твое приложение передало в ОС данные для записи в файл с помощью вы, анонимус (?), 19:20 , 12-Мрт-09, (36) ещё раз повторяю падает не приложение, а система она же ОС тот же эффект п, vitek (??), 19:25 , 12-Мрт-09, (38) Отлично А почему при этом должно что-то хериться Изначально журналы и транзакции, User294 (??), 23:23 , 12-Мрт-09, (89) А был момент, когда файл был нулевого размера и данных в нём не было Если был , darkk (?), 06:41 , 13-Мрт-09, (98) Все так, но было бы логично если бы ФС не особо торопилась с коммитом именно так, User294 (??), 15:58 , 13-Мрт-09, (116) Разве кто сказал, что виноваты пользователи Внимательней нужно читать Если не , xand (?), 18:31 , 12-Мрт-09, (23) но это не повод угробить систему , Аноним (-), 16:22 , 12-Мрт-09, (3) // Знаете, ФС не должна палить в пятки юзера по дефолту И я не думаю что убунтуйцы , User294 (??), 17:20 , 12-Мрт-09, (17) Это у экстов то трудноубиваемость Да даже Fat и тот надежней , Konstantin (??), 17:46 , 12-Мрт-09, (21) Да что вы говорите У меня на FAT при слете питания однажды нулось несколько бо, User294 (??), 18:57 , 12-Мрт-09, (28) ну это Вы точно загнули 2-е копии FAT имеется ввиду File Allocation Table, а не, vitek (??), 19:08 , 12-Мрт-09, (33) Намедни поймал такое на Debian unstable experimental Списал на глюк KDE4 , prapor (??), 16:42 , 12-Мрт-09, (7) // и правильно сделал но базовая фс всё равно должна быть не убиваемой может это , vitek (??), 17:20 , 12-Мрт-09, (16) // А по-моему не очень Понижение надежности работы ФС приветствовать имхо нельзя В , User294 (??), 17:29 , 12-Мрт-09, (19) // т е пишите глюкавые программы это позволяет отслеживать ошибки в фс и не тольк, vitek (??), 18:40 , 12-Мрт-09, (26) Как по мне так убунтуйцам надо спасибо сказать за ранний отлов грабель Данный тр, User294 (??), 19:23 , 12-Мрт-09, (37) именно , vitek (??), 19:35 , 12-Мрт-09, (43) это происходит только если есть прога, которая работает с ними через анальное от, vitek (??), 19:39 , 12-Мрт-09, (44) Боюсь что если такая ФС пойдет в массы - мы узнаем много нового о привычном софт, User294 (??), 19:56 , 12-Мрт-09, (50) ну я и так о нём не мало знаю одно кде чего стоит вот и палинух своему другу , vitek (??), 23:03 , 12-Мрт-09, (82) Но стоит себе на EXT3 в 8 10 и почему-то ничего не сыпется - , User294 (??), 23:30 , 12-Мрт-09, (91) Вот, собственно, 1 Думал на десктопе home перевести, но теперь передумал , prapor (??), 02:24 , 13-Мрт-09, (94) И наверное правильно сделал Потому что иначе рискуешь узнать много нового о прям, User294 (??), 16:11 , 13-Мрт-09, (119) Release early, release often , terminus (ok), 16:45 , 12-Мрт-09, (9) Имхо, это больше кирпич в огороды Ubuntu, Gnome и KDE, чем в огород ext4 Во перв, XoRe (ok), 16:48 , 12-Мрт-09, (10)   // Да, все пи сы, а вот ext4 Д Артаньян А пардон, почему у ext3 таких граблей нет, User294 (??), 18:17 , 12-Мрт-09, (22)   // 1 по всем пунктам, szh (ok), 03:44 , 13-Мрт-09, (96)   если ext3 считается надёжной только потому, что додумались ставить по-умолчанию , vitek (??), 15:51 , 13-Мрт-09, (115)   микроядро - и заветную кнопку можно исключить из аппаратуры на , Аноним (56), 20:09 , 12-Мрт-09, (56)   // А Чубайса ты куда денешь, умник Или ты морально готов купить всем упсы за свой с, User294 (??), 23:28 , 12-Мрт-09, (90)   Ну вот на Reiser4 тоже использует отложенную запись, только почему-то подобных к, zzz (??), 12:07 , 13-Мрт-09, (104)   // К рейзерам у юзерей по жизни масса предъяв почему-то Третий рейзер вообще зачотн, User294 (??), 12:40 , 13-Мрт-09, (105)   // amule org - No DNS records - как бы намекает на то, что это было давно или н, zzz (??), 13:34 , 13-Мрт-09, (107)   проверок у ext3 не меньше fresco подтвердит - его то мнению Вы доверяете у , vitek (??), 16:13 , 13-Мрт-09, (120)   Он в подобные детали не вникал, судя по его статьям А вот эти ребята вникали h, zzz (??), 16:30 , 13-Мрт-09, (121)   более развернутая версия http www cs wisc edu adsl Publications vijayan-thesis, zzz (??), 16:58 , 13-Мрт-09, (124)   ну тогда и я ещё раз - оттуда же ext3 recovery For most detected errors, ext3, vitek (??), 19:04 , 13-Мрт-09, (134)   там ещё четко написано относительно проверок на ошибки при записи, но кто-то поч, zzz (??), 01:14 , 14-Мрт-09, (137)   да читал я эту статью уж и не помню сколько лет назад по-моему в 2005 вывод , vitek (??), 17:28 , 13-Мрт-09, (127)   часть идей из ixt3 перекочевала в ext4 на самом деле те же jounral checksums ну, zzz (??), 01:26 , 14-Мрт-09, (138)   о чём и речь именно этого и ждут от ext4 и что интересно не ждут от ext3 ссылк, vitek (??), 12:48 , 14-Мрт-09, (142)   Это никому не нравится, но это политика reiserfs относительно сохранности данных, zzz (??), 13:42 , 16-Мрт-09, (144)   никто и не преподносит просто на все дополнительные возможности становится как-т, vitek (??), 14:48 , 16-Мрт-09, (148)   особенно это не происходит на десктопах с активно работающими гном и кде на, vitek (??), 16:10 , 13-Мрт-09, (118)   // Тем не менее, ни я, ни кто другой и байта подобным образом не потерял за все вре, zzz (??), 16:36 , 13-Мрт-09, (122)   тоже самое с ext3 а если нет разницы, то дося -D, vitek (??), 17:53 , 13-Мрт-09, (130)   В ext3 нет delayed allocation, да и reiser4 она не конкурент, zzz (??), 13:43 , 16-Мрт-09, (145)   да и хрен с ней кто ж спорит речь о надёжности и только , vitek (??), 14:46 , 16-Мрт-09, (147)   Я не совсем понимаю, а что за такие громадные преимущества даёт журнал Файл з, Thorn (??), 16:53 , 12-Мрт-09, (11) // ЧЕстно говоря, даже отвечать лень Почитай вики про журнал, что ль У меня сист, Анонимус (?), 17:08 , 12-Мрт-09, (13) // во истину так , vitek (??), 19:17 , 12-Мрт-09, (34) Проблема есть, была и будет Суть ее в кэшировании А что именно отвалится если , Аноним (-), 17:13 , 12-Мрт-09, (15) Не понимаешь - читай книжки 171 Системная инфа 187 это называется метаданн, Аноним (56), 17:43 , 12-Мрт-09, (20) На самом деле трабл в том что ФС печется о валидности метаданных а что по факту , User294 (??), 18:39 , 12-Мрт-09, (25) // можно еще вспомнить что в современных HDD а уж тем более в SCSI SAS контроле, _umka_ (ok), 19:02 , 12-Мрт-09, (32) // Вообще, насколько я помню, нынче все порядочные жесткие диски и драйвера контро, User294 (??), 19:42 , 12-Мрт-09, (45) А зачем в самом винте буфер на чтение С readahead вроде система неплохо справля, darkk (?), 19:51 , 12-Мрт-09, (48) Не у всех есть readahead, особенно пока система только грузится, etc Еще харду е, User294 (??), 23:36 , 12-Мрт-09, (92) gt оверквотинг удален Сделав то что вы говорите - вы убьете процентов 40 произ, _umka_ (ok), 10:02 , 13-Мрт-09, (101) Это не трабл Это ОЖИДАЕМОЕ поведение операционной системы О данных программы д, Аноним (56), 19:26 , 12-Мрт-09, (40) // Если вы хотите юзать операционку которая норовит поднасрать - это ваше право А я, User294 (??), 15:42 , 13-Мрт-09, (113) IMHO во FreeBSD это называется SoftUpdate 1 технология журналирования уже расPR, Tim (??), 18:49 , 12-Мрт-09, (27) // только в extXXX - журнал на диске в специальной inode а в FreeBSD - это в памяти, _umka_ (ok), 19:25 , 12-Мрт-09, (39) // Работа extXXX классическая - 1 отметка в журнале начало операции 2 выполнени, Tim (??), 22:42 , 12-Мрт-09, (77) gt оверквотинг удален тут разное, бывает журналирование обновлений блоков мета, _umka_ (ok), 10:13 , 13-Мрт-09, (102) Нет, вы неправы В журналированных ФС порядок операций в составе одной транзакци, Tim (??), 14:02 , 13-Мрт-09, (108) По сути, если смотреть максимально обще, то фревый SostUpdates - это действитель, nuclight (ok), 22:37 , 21-Мрт-09, (154) А почему этой проблеме подвержена в том числе и btrfs Разве оно не copy-on-writ, Султан (?), 18:58 , 12-Мрт-09, (29) // Во-во, что то у меня на zfs такого никогда не наблюдается, хоть уже полтора года, yalur (ok), 19:54 , 12-Мрт-09, (49) // оракле туда пихни или постгрес развлечения обеспечены при том, что она ещё, vitek (??), 23:07 , 12-Мрт-09, (83) man proc sys vm E, Аноним (-), 20:00 , 12-Мрт-09, (53) Бок ext4 только в том, что она сразу делает truncate точнее в журнале записывае, Breg (??), 20:44 , 12-Мрт-09, (59) // Это опять таки проблемы реализации некоторых линуксовых fs, а не приложения На , nuclight (ok), 12:42 , 27-Мрт-09, (155) Собственно, а при чем здесь ФС Или вы хотели и на диск не писать, и при отключе, Аноним (-), 21:20 , 12-Мрт-09, (62) Да, ребятки, что-то тут народ совсем жиденький Хочу обратно на лор Верните , Аноним (-), 21:28 , 12-Мрт-09, (65) // А чему у вас равно sysctl vm dirty_writeback_centisecs - , darkk (?), 21:30 , 12-Мрт-09, (66) // 5 секунд, на файлопомойке с большой дисковой активностью на запись - минута А, Аноним (-), 21:49 , 12-Мрт-09, (67) // не пользуем, а рассуждаем интересно где ты ещё увидишь такое бурое обсуждени, vitek (??), 23:10 , 12-Мрт-09, (85) Я так и не понял, зачем при старте даже не при окончании работы, а при старте , Дмитрий Ю. Карпов (?), 23:57 , 12-Мрт-09, (93) Что-то мутное - эти системы конфигурации KDE и gnome Из-за них я не пользуюсь н, Андрей (??), 06:02 , 13-Мрт-09, (97) ну накинулись на файловиков любая файловая система, располагающая механизмом del, fresco (??), 09:50 , 13-Мрт-09, (100) // gt оверквотинг удален 1Рад вашему ходу мыслей 2 User294 Я понял, что вам не н, XoRe (ok), 11:21 , 13-Мрт-09, (103) Разница в реализации огромная - в одном случае получим после сбоя пустые файлы, , uldus (ok), 12:47 , 13-Мрт-09, (106) Решение этой проблемы - атомарность, когда несколько действий с файлом объединяю, zzz (??), 14:27 , 13-Мрт-09, (109) // есть только один вопрос - как эту атомарность обеспечить по каким критериям в т, vitek (??), 16:50 , 13-Мрт-09, (123) // Никак Долго открытый файл - это проблема приложения, ставящего под риск свои да, Thorn (??), 17:11 , 13-Мрт-09, (126) в том то и дело - как долго сейчас - 60 секунд всё остальное - долго если свес, vitek (??), 18:33 , 13-Мрт-09, (133) Корень текущей обсуждаемой проблемы - открытие на запись непустого файла с флаго, zzz (??), 17:45 , 13-Мрт-09, (128) вот именно объединяем 1-й и 2-ой пункты получаем 1 час -Dдальше программа гот, vitek (??), 18:18 , 13-Мрт-09, (131) нет, есть ведь т н время жизни транзакцииядроfsync достаточно, иначе система бу, zzz (??), 01:07 , 14-Мрт-09, (136) это уже не транзакция, а извиняюсь порнография основное достоинство oracle - вр, vitek (??), 16:48 , 14-Мрт-09, (143) смотри те же исходники jbd, reiserfs там это понятие определено как commit_timeo, zzz (??), 13:56 , 16-Мрт-09, (146) а я где то писал, что в восторге от текущего положения во всех журналируемых фс , vitek (??), 15:01 , 16-Мрт-09, (149) Ребят, а нельзя ли взять лучшее от обоих миров Скажем, есть некий архив-сетап , Thorn (??), 17:09 , 13-Мрт-09, (125) // в том то и проблема есть определённые системные вызовы по работе с файлами он, vitek (??), 18:28 , 13-Мрт-09, (132) кто знает при data journal delayed allocation мне скорость понравилась как у ex, Аноним (-), 01:42 , 14-Мрт-09, (139) // работает delayed allocation , Аноним (-), 01:42 , 14-Мрт-09, (140) Ребят, чего париться - отключаем delayed allocation и все, что может привести к , XoRe (ok), 17:45 , 16-Мрт-09, (150) 1,2,3,7,9,10,11,29,53,59,62,65,93,97,100,125,139,150

Сообщения

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

10. "Проблемы с потерей данных на Ext4 разделах в тестовой версии Ubuntu 9.04"	+/–
Сообщение от XoRe (ok), 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 (??), 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), 13-Мрт-09, 03:44
	+1 по всем пунктам
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	134. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
	Сообщение от vitek (??), 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 (??), 14-Мрт-09, 01:14
	там ещё четко написано относительно проверок на ошибки при записи, но кто-то почему-то это не процитировал... :)
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
	Сообщение от vitek (??), 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. заявить о возможностях - это одно. реализовать - другое. да и сравнивать красное с мягким - мне не интересно.
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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