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

Проблемы с потерей данных на 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]

2. "Проблемы с потерей данных на Ext4 разделах в тестовой версии Ubuntu 9.04"	+/–
Сообщение от друг pavlinux (?), 12-Мрт-09, 16:17
,,,хм молодец, сразу нашел отговорку -  виноват пользователь,,,,,, -  ужас! человек который пишет именно системное приложение так говорит!!!! Это подчеркивает о его некомпетенции!!!! Сам программировал микроконтроллеры, ни когда, человек, который пишет именно системные приложения, ни скажет такое!!! А уж тем более о том, что виновато именно пользовательское приложение,,,,,  -узость интеллекта, не более,,,,
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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