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

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

11. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
Сообщение от Thorn (??), 12-Мрт-09, 16:53
Я не совсем понимаю, а что за такие громадные преимущества даёт "журнал"? Файл записывается в сектора, ПОТОМ обновляется системная инфа (каталог) и вуаля! Зачем ещё какие-то параноидальные "повышения надёжности"? Крах системы - это какой-то нонсенс. Падать должны гномики, а дисковая система работать на ура. Проблему надумали?
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

	32. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
	Сообщение от _umka_ (ok), 12-Мрт-09, 19:02
	>>работать на ура. Проблему надумали? > >На самом деле трабл в том что ФС печется о валидности метаданных >а что по факту случится с файлом и юзерскими данными в >нем ей как бы это помягче сказать, глубоко фиолетово.И это неизбежно >ведет к потере данных.И не то чтобы это следует приветствовать, ОСОБЕННО >если это ведет к вот такому откровенному просеру данных. можно еще вспомнить что в современных HDD (а уж тем более в SCSI & SAS) контролерах есть свой кэш - часто на десятки мегабайт. Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся на поверхности (persistent storage). Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная, Даже и с fsync - не сильно лучше. Опишу ситуацию. создали очень много каталогов в нем сделали файл и туда записали. после чего вызвали fsync. Как вы думаете - закомитятся на диск все созданые каталоги? Да? не угадали. согластно man fsync - это не делается, согластно POSIX - остается на усмотрение разрабочиков FS и системы. >>>>>        Calling  fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk.  For that an explicit fsync() on        a file descriptor for the directory is also needed. >>>>>> Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает обновленя data + metadata для всех файлов. Но это скорее особенность FS чем требуемое по стандарту поведение.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
	Сообщение от User294 (??), 12-Мрт-09, 19:42
	>можно еще вспомнить что в современных HDD (а уж тем более в >SCSI & SAS) контролерах есть свой кэш - часто на десятки >мегабайт. Вообще, насколько я помню, нынче все порядочные жесткие диски (и драйвера контроллеров) способны рапортовать факт окончания именно *физической* записи на блин а не в кэш.Раньше натурально была такая проблема что харды врали о успехе факта записи всего лишь сложив данные в кэш но сейчас вроде за счет воплей юзерья до производителей хардов и дровописателей дошло и это крайне паскудное явление насколько я знаю вроде пролечили в массе своей.Поскольку оно больно уж сурово клещится с логикой любого журналирования (если железо врет о успехе записи - с этим ничего не сделать, на таком железе просто нельзя надежно работать).Еще кстати некоторые харды умеют юзать заряд конденсаторов и инерцию шпинделя чтобы завершить запись.Некоторые ограничивают размер своего кэша на запись кстати - из 32 мегов на *запись* может юзаться и меньше чем 32 мега. >Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся >на поверхности (persistent storage). Оно все так, но вроде современные диски и драйвера контроллеров все-таки научились совместно играть в эту игру правильно в массе своей?Потому что данное поведение сильно рушит логику любого журналинга вообще.Журнал не может работать коректно если железо врет о успехе записи а запись журнала потом взяла и просралась из-за слета питания. >Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная, См. выше, с правильным железом и драйверами которые не врут - вопрос нормальный и имеет право на жизнь.Надеюсь что не глючу на этот счет :) >согластно man fsync - это не делается, согластно POSIX - остается на >усмотрение разрабочиков FS и системы. Угу, все сделано для того чтобы можно было просрать данные как можно более изящно.Круто! >Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает >обновленя data + metadata для всех файлов. Но это скорее особенность >FS чем требуемое по стандарту поведение. Понимаете в чем проблема, мне если честно несколько насрать на стандарты когда вопрос идет о сохранности моих данных.Тот факт что мои данные по стандарту можно просрать для меня как-то довольно слабое утешение.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	101. "Проблемы с потерей данных на Ext4 разделах в тестовой версии..."	+/–
	Сообщение от _umka_ (ok), 13-Мрт-09, 10:02
	>[оверквотинг удален] > >Вообще, насколько я помню, нынче все порядочные жесткие диски (и драйвера контроллеров) >способны рапортовать факт окончания именно *физической* записи на блин а не >в кэш.Раньше натурально была такая проблема что харды врали о успехе >факта записи всего лишь сложив данные в кэш но сейчас вроде >за счет воплей юзерья до производителей хардов и дровописателей дошло и >это крайне паскудное явление насколько я знаю вроде пролечили в массе >своей.Поскольку оно больно уж сурово клещится с логикой любого журналирования (если >железо врет о успехе записи - с этим ничего не сделать, >на таком железе просто нельзя надежно работать). Сделав то что вы говорите - вы убьете процентов 40 производительности hdd, собственно по тому и есть контролеры с батарейками и подпитывание диска какое-то время и тп. > >>Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся >>на поверхности (persistent storage). > >Оно все так, но вроде современные диски и драйвера контроллеров все-таки научились >совместно играть в эту игру правильно в массе своей?Потому что данное >поведение сильно рушит логику любого журналинга вообще.Журнал не может работать коректно >если железо врет о успехе записи а запись журнала потом взяла >и просралась из-за слета питания. именно. собственно приводилось только для илюстрации что журнал нефига не панацея. > >>Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная, > >См. выше, с правильным железом и драйверами которые не врут - вопрос >нормальный и имеет право на жизнь.Надеюсь что не глючу на этот >счет :) как вы сами заметили далеко не со всеми девайсами и не со всеми дровами. > >>согластно man fsync - это не делается, согластно POSIX - остается на >>усмотрение разрабочиков FS и системы. > >Угу, все сделано для того чтобы можно было просрать данные как можно >более изящно.Круто! именно ;) тут звучали слова о fsync как панацеие от этого - вот разочарование. > >>Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает >>обновленя data + metadata для всех файлов. Но это скорее особенность >>FS чем требуемое по стандарту поведение. > >Понимаете в чем проблема, мне если честно несколько насрать на стандарты когда >вопрос идет о сохранности моих данных.Тот факт что мои данные по >стандарту можно просрать для меня как-то довольно слабое утешение. Включите sync и радуйтесь жизни :) любой async потенциально опасная вещь - и соблюдение всех стандартов не гарантирует что FS будет не противоречива. Я лиш это пытался донести. Это как весы - скорость vs надежность - обе вещи одновременно не бывает.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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