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

Очередная порция улучшений в Btrfs, opennews (??), 18-Дек-12, (0) [смотреть все] С переизбытком мета-данных на мелких файлах что-нибудь решили , Аноним (-), 20:34 , 18-Дек-12, (1) // А что с ним надо решать Создаете нулевые файлы и у вас на ФС кончается место хо, Аноним (-), 21:02 , 18-Дек-12, (2) +4 А что можно решить против простой арифметики Файл - это не только его содержи, Аноним (-), 21:50 , 18-Дек-12, (11) +2 // имя в юинксах не является метаданным файла, all_glory_to_the_hypnotoad (ok), 22:23 , 18-Дек-12, (18) –1 // Кто вам это сказал Дайте ему в бубен за вранье Метаданные на файловой системе , Аноним (-), 23:05 , 18-Дек-12, (26) +4 _в_ файловой системе заканчивай давай со совоим обывательским учением о , all_glory_to_the_hypnotoad (ok), 23:34 , 18-Дек-12, (30) а чем ссылка от инода отличается ссылка и инод хранятся где-то в разных местах , Аноним (-), 06:33 , 19-Дек-12, (44) –1 Более того, тот же posix вообще IIRC никак не регламентирует как именно ФС должн, Аноним (-), 17:33 , 19-Дек-12, (84) +1 а причем тут posix и ответов на вопросы как не было так и нет , Аноним (-), 05:32 , 20-Дек-12, (119) При том что апломб относительно а вот так расово верно, а остальные - пи сы , Аноним (-), 17:02 , 20-Дек-12, (142) а ну да, все верно , Аноним (-), 19:49 , 21-Дек-12, (167) Внезапно да На один inode может быть несколько жёстких ссылок Подробнее тут ht, Гентушник (ok), 13:02 , 20-Дек-12, (137) +1 Ну это пусть граммар-наци докапываются Вас они вообще просто обязаны расстрелят, Аноним (-), 16:41 , 19-Дек-12, (72) +5 Что, правда Значит, имя файла - это просто данные , Аноним (-), 01:34 , 19-Дек-12, (35) +3 Да, это так Фактически папка - это файл со списком ссылочных структур, где соде, Valentine (??), 10:30 , 19-Дек-12, (58) –3 Фактически, никто не обязывает файловую систему хранить папку в именно указанн, Аноним (-), 16:46 , 19-Дек-12, (73) +3 И сразу закономерный вопрос размер такого файла учитывается в столбце used вы, Аноним (-), 18:10 , 19-Дек-12, (88) Как посмотреть размер ls -lhd vardrwxr-xr-x 25 root root 4 0K Dec 26 02 43 , Valentine (??), 10:37 , 28-Дек-12, (180) Только в данном случае речь не об этом, а о горе внутренних структур , Crazy Alex (ok), 22:35 , 18-Дек-12, (20) –4 // Об этом, об этом , Аноним (-), 22:54 , 18-Дек-12, (25) Насколько я помню, там было две проблемы 1 служебных данных очень много в силу, Crazy Alex (ok), 01:06 , 19-Дек-12, (34) –3 нет таких проблем дерево портежей спокойно в 620mb вмещается К слову, на ext4 е, runoverheads (ok), 06:11 , 19-Дек-12, (43) +2 // сжатие на бтр-е стоит , Аноним (-), 06:37 , 19-Дек-12, (45) // да, zlib и nodesize 16kвсего влезло 830mb на раздел в 1024mb df -h usr por, runoverheads (ok), 06:45 , 19-Дек-12, (47) –1 на свежую голову понял что чтото не так оказалось опция nodatacow отключает сжа, runoverheads (ok), 13:38 , 19-Дек-12, (62) К 3 9 можно будет попробовать Дожить бы , Аноним2 (?), 21:07 , 18-Дек-12, (3) –1 // В опенсоурсе, раньше чем через 10 лет после анонса фичи, ничего нельзя юзать О, pavlinux (ok), 21:21 , 18-Дек-12, (4) // КЭП же БОЛЬШИМИ БУКОВАМИ , closet_source (ok), 21:38 , 18-Дек-12, (9) –1 // FAIL , Аноним (-), 22:16 , 18-Дек-12, (14) при условии что ты МакЛауд и живешь вечно - замечательный вариант , Аноним (-), 21:44 , 18-Дек-12, (10) +2 // Ну а чё, Linux ушёл в массы с версии 2 6 9, вроде 2004 год StarOffice OpenOffice, pavlinux (ok), 01:35 , 19-Дек-12, (36) –3 Ага а теперь посмотри на историю компьютерной техники и ты поймешь, что копошени, rshadow (ok), 03:04 , 19-Дек-12, (40) Дык, об этом и речь Кстати, экспонента может быть и в другую сторону см Open, pavlinux (ok), 03:51 , 19-Дек-12, (42) Гм, даже я видел 2 4 кернелы Хоть я и весьма поздно обратил внимание на линь Ну, Аноним (-), 17:39 , 19-Дек-12, (85) –1 Я с версии 1 2, заменил полностью вянду с 2 0 33 и чё Драйверов вааще не было , pavlinux (ok), 19:03 , 19-Дек-12, (98) К 4 0, Аноним (-), 21:35 , 18-Дек-12, (6) –1 Что-то вы пессимист прямо Вас там что, гопы с битами ждут, чтоли - каждый день , Аноним (-), 21:36 , 18-Дек-12, (7) +1 // конец света же , Mike Lee (?), 11:10 , 19-Дек-12, (61) +2 А некоторые гопы - даже с байтами , sdfsfsf (?), 16:53 , 19-Дек-12, (74) // Гоповский байт тоже состоит из восьми бит , Аноним (-), 20:12 , 19-Дек-12, (104) Это смотря сколько а если найдут , kurokaze (ok), 00:59 , 21-Дек-12, (162) Шестирукая Шива завистливо смотрит на столь удачливых гопов , Аноним (-), 17:09 , 20-Дек-12, (143) Хм, я бы ещё как минимум версию-другую подождал Судя по эпичности бага с коллиз, Crazy Alex (ok), 22:37 , 18-Дек-12, (21) –3 // Такой баг практически нереально выловить при тестировании Только аудит Именно , Аноним (-), 01:37 , 19-Дек-12, (37) +1 // И вообще недеструктивную запись Хотя от этого очень помогает пару раз пришибить, Аноним (-), 17:09 , 19-Дек-12, (75) Вот Еще один, не делающий ежедневных инкрементальных бэкапов , AlexAT (ok), 18:11 , 19-Дек-12, (89) +2 Снапшоты дают возможность делать бэкапы гораздо реже С высоты пользователя ФС, у, Аноним (-), 18:15 , 19-Дек-12, (91) Снапшоты не заменяют бэкапы, ибо если там в середине выпадет блок - оно как кост, Аноним (-), 18:47 , 19-Дек-12, (94) Снапшот заменяет ежедневный бэкап, но не заменяет ежемесячного Потому что вероят, Аноним (-), 19:20 , 19-Дек-12, (99) Терять в худшем случае данные за месяц Увольте сразу Нет уж, нет уж Снапшот у, AlexAT (ok), 19:25 , 19-Дек-12, (100) +1 Учитывая ничтожную вероятность такого исхода - не страшно Ок, вы уволены За пер, Аноним (-), 20:14 , 19-Дек-12, (105) –1 Да легко Я из одной такой конторы ушёл сам, потому что подходы задрали Зато по, AlexAT (ok), 20:38 , 19-Дек-12, (109) +1 Да, если строить архитектуру кривыми руками - оно непременно рухнет И отсутствие, Аноним (-), 20:53 , 19-Дек-12, (110) –1 Оно рухнуло потому, что подход сменился на минимум затрат Соответственно, пер, AlexAT (ok), 20:54 , 19-Дек-12, (112) +1 Устройся в администрацию президента - от народа потом благодарность будет, kurokaze (ok), 01:02 , 21-Дек-12, (163) +2 Можно еще в госдуму Тоже неплохой вариант , Аноним (-), 22:29 , 27-Дек-12, (174) о, а теперь расскажите мне как, сколько и куда вы будете 100ТБ данных бекапить, Аноним (-), 06:50 , 20-Дек-12, (123) –1 100Тб А что как мало-то Инкрементальных бэкапов никто какбэ не отменял , AlexAT (ok), 07:14 , 20-Дек-12, (124) +1 ты просто не видел как бекап делается неделю да не полный бекап, а инкременталь, Аноним (-), 18:56 , 21-Дек-12, (164) Можно поинтересоваться - чем вы так систему добили , AlexAT (ok), 20:53 , 21-Дек-12, (170) +1 какую систему и причем тут какая-то система , Аноним (-), 05:43 , 23-Дек-12, (172) –1 LMAO, спалился , AlexAT (ok), 09:41 , 23-Дек-12, (173) +1 Если у вас бэкап делается b неделю b , у меня для вас плохие новости you are , Аноним (-), 22:30 , 27-Дек-12, (175) Кхм, вообще-то я разок про л данные как раз раскатав старый бэкап сгоряча И о, Аноним (-), 18:46 , 19-Дек-12, (93) +1 Как правильно говорил один из моих школьных преподавателей в бородатом 95 году -, AlexAT (ok), 19:26 , 19-Дек-12, (102) Воот И с бэкапами торопиться не следует Это же не блохи Хватит с них и раза в, Аноним (-), 20:54 , 19-Дек-12, (111) –2 Ну да, однако это не отменяет того факта что наличие нескольких разных инкарнаци, Аноним (-), 17:11 , 20-Дек-12, (144) Баг с колизиями похоже так и не справили , linux must _RIP_ (?), 21:31 , 18-Дек-12, (5) –2 // Взвис - исправили Сам алгоритм пока не меняли, да , Аноним (-), 21:37 , 18-Дек-12, (8) констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4трыц, SergMarkov (ok), 22:40 , 18-Дек-12, (22) –1 // Видимо Крис добрел до фороникса , Аноним (-), 23:10 , 18-Дек-12, (29) // Я это чудо ставил для пробы, причем сделал по умолчанию настройки как ext4 так и, SergMarkov (ok), 15:00 , 19-Дек-12, (67) –1 // Скорость - это замечательно, хорошо и правильно Но все-таки это не единственное, Аноним (-), 17:16 , 19-Дек-12, (76) Да нет, я не спорю, что у него есть масса преимуществ для серверов, но мне то он, SergMarkov (ok), 17:19 , 19-Дек-12, (80) –1 Как бы это сказать Я и на десктопе не против иметь возможность отмотать назад , Аноним (-), 17:44 , 19-Дек-12, (86) +2 Ну, для этого есть бэкапы и не только на другой диск Причем при их использовани, SergMarkov (ok), 17:49 , 19-Дек-12, (87) –1 Сравнили ж с пальцем Вот вы будете бэкапаться каждые 30 секунд Ну и я тоже , Аноним (-), 18:56 , 19-Дек-12, (95) Вот Реальное удобство снапшота именно в этом делаем снапшот, выполняем критичн, AlexAT (ok), 19:29 , 19-Дек-12, (103) +1 заменяем снапшот на бэкап, получаем тоже самое и без потери производительности , SergMarkov (ok), 20:18 , 19-Дек-12, (107) –1 То же самое - вы не получите уже в силу завязанности процедуры на расписание бэк, myhand (ok), 21:41 , 19-Дек-12, (113) +1 выполняем критичную операцию бэкап, SergMarkov (ok), 21:44 , 19-Дек-12, (114) –1 А вам объяснили, как вместо этого можно использовать снапшот , myhand (ok), 21:58 , 19-Дек-12, (115) +1 C потерей производительности основных операций Можно грибок съем, он такой кра, SergMarkov (ok), 00:59 , 20-Дек-12, (116) –1 А бэкап, значицца на ентой производительности никак не сказывается Ну-ну Зав, myhand (ok), 01:13 , 20-Дек-12, (117) +2 Вариант, но как я уже сказал, бэкапаться раз в 30 секунд вы не будете А вот бтр, Аноним (-), 18:11 , 20-Дек-12, (155) Резервные копии делаются по расписанию или по требованию пользователя и их созда, Tav (ok), 03:43 , 20-Дек-12, (118) +1 Не замена в том плане, что за удобство платят снижением производительности Чуде, SergMarkov (ok), 08:06 , 20-Дек-12, (131) –2 Вам уже заметили бэкап тоже влияет на производительность Да нет, бывает Нау, myhand (ok), 12:51 , 20-Дек-12, (133) +1 Пока что получается ровно напротив - удобство снапшотов приводит к снижению прои, SergMarkov (ok), 12:54 , 20-Дек-12, (134) –1 Что в лоб - что по лбу Вы вообще - читаете что вам пишут , myhand (ok), 16:43 , 20-Дек-12, (139) –1 В начало треда и в саму новость Курить до просветления 9786 , SergMarkov (ok), 16:45 , 20-Дек-12, (140) –1 Тогда зачем вы отвечаете, если коменты не читали , Аноним (-), 17:13 , 20-Дек-12, (145) +1 Кто ж виноват, что именно вы забыли с чего вообще начиналась полемика 9786 , SergMarkov (ok), 17:17 , 20-Дек-12, (146) –1 Для качественных усилков, как ни удивительно - лучше радиолампы Всем транзистор, AlexAT (ok), 16:47 , 20-Дек-12, (141) Подложили Но в современных экспонатах с правильно рассчитанными режимами нелине, Аноним (-), 17:20 , 20-Дек-12, (147) +2 Сигнал - улучшает, звучание - на 0, за пределами слуха , AlexAT (ok), 17:22 , 20-Дек-12, (148) только цифровым технологиям это улучшение сильно пофиг Сигнал эзернета или п, Аноним (-), 18:18 , 20-Дек-12, (157) +1 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что не иметь постоян, SergMarkov (ok), 20:17 , 19-Дек-12, (106) –1 ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в сутки побекапить и храни, Аноним (-), 06:26 , 20-Дек-12, (122) +2 Это широко рапространенная задача Нет, сдуру можно и кое что пониже пояса слом, SergMarkov (ok), 08:05 , 20-Дек-12, (128) –2 как бы вам объяснить, вот у меня очень мало серверов, где инкрементный бекап укл, Аноним (-), 19:25 , 21-Дек-12, (166) +1 ionice отменили , AlexAT (ok), 20:53 , 21-Дек-12, (171) +1 И да, гугель как то вообще обходится даже без журналирования, при этом цветет и , SergMarkov (ok), 13:02 , 20-Дек-12, (136) –1 Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля чт, Аноним (-), 17:22 , 20-Дек-12, (149) да тут вопрос собственно в приоритетах, если чоловику первичны эти снапшоты чере, SergMarkov (ok), 17:28 , 20-Дек-12, (152) –1 Да, у гугля надежность совершенно не в приоритете благодаря устройству их распр, Аноним (-), 18:24 , 20-Дек-12, (158) +1 Тьфу ты Ё, как по бенгазильски пишу Читай в самой новости уступает в производи, SergMarkov (ok), 18:35 , 20-Дек-12, (159) –1 Запорожес с горы Арарат легко обгонит какой-нибудь Феррари Будешь водителем зап, Аноним (-), 22:35 , 20-Дек-12, (160) +1 Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах, iZEN (ok), 20:26 , 21-Дек-12, (169) –1 Да, там путем черной магии обманывают физику и логику, ну конечно же Особенн, Аноним (-), 22:39 , 27-Дек-12, (176) Прямо клуб анонимных разработчиков Здравствуйте, меня зовут Джозеф, и я уже три , Аноним (-), 23:41 , 18-Дек-12, (31) +1 // Это чтобы использующие это уже сейчас в продакшн по совету суседелов не отлови, Аноним (-), 01:39 , 19-Дек-12, (38) –2 // А что, при более медленной синхронной записи выше вероятность их потери , Аноним (-), 10:35 , 19-Дек-12, (59) // Чем больше время операции тем выше вероятность сбоя во время операции , К.О. (?), 16:04 , 19-Дек-12, (69) По такой логике ядерные реакторы вообще взрываться не должны , Аноним (-), 17:17 , 19-Дек-12, (77) Очередная порция исправлений и улучшений Видать 14 февраля наступит таки не , Anonus (?), 02:51 , 19-Дек-12, (39) –3 // PulseAudio был готов с 1 версии и оллично работал, в том чисте и у меня Не его , Аноним (-), 03:29 , 19-Дек-12, (41) +3 // Пользоваться функциями ALSA, в которой баг на баге Да, до такой херни мог додум, Аноним (-), 14:55 , 19-Дек-12, (66) // Ой, оказывается в софте бывают баги Надо же, открытие века , Аноним (-), 17:17 , 19-Дек-12, (79) добавивший возможность замены диска в процессе эксплуатации в btrfs небыло гор, Аноним (-), 06:44 , 19-Дек-12, (46) –1 // А оно, простите, нужно При наличии md HW RAID Ну, кроме как для извращений , AlexAT (ok), 07:22 , 19-Дек-12, (48) +2 // Когда конфигурация дискового пула стабильна, то, в большинстве случаев, оно без , dalco (ok), 07:52 , 19-Дек-12, (50)   // - самое время решить админа премии, а то и уволить, за открытую дестабилизацию с, AlexAT (ok), 09:33 , 19-Дек-12, (53) +1   а что критичного в этой операции уже давно вытащил винты из пула, поставил бол, Аноним (-), 10:00 , 19-Дек-12, (54)   Вероятность того, что что-то пойдёт не так в процессе Как минимум оперативный б, AlexAT (ok), 10:05 , 19-Дек-12, (55) +4   Не так пойдет - если вы с пьяного глаза, выдерните винт из соседнего сервера, а , Аноним (-), 10:49 , 19-Дек-12, (60)   Наивняк, верящий в 100 надежность железа во время критичных операций с ним, обы, AlexAT (ok), 14:04 , 19-Дек-12, (64)   Ну в raid5 IIRC обычная XORка Это быстро А верную копию можно вычислить посмот, Аноним (-), 17:20 , 19-Дек-12, (81)   Так речь про Z2 Z3 или все-таки про R5 Z , AlexAT (ok), 18:12 , 19-Дек-12, (90)   Про сабжа и raid 5 , Аноним (-), 18:57 , 19-Дек-12, (96)   Да, переучился быстро, после того, как 3варе умирая забрала с собой и данные Те, Аноним (-), 06:03 , 20-Дек-12, (120) –1   А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector , Аноним (-), 17:56 , 20-Дек-12, (154) +1   Помнится, у него был пул в состояние FAULTED уже не DEGRADED и не было на тот , iZEN (ok), 18:11 , 20-Дек-12, (156) –1   Проблема на самом деле не в том А в том что средств для починки или хотя-бы выт, Аноним (-), 22:39 , 20-Дек-12, (161)   Видишь ли, сам принцип CoW не может позволить навернуться существующим данным и , iZEN (ok), 20:19 , 21-Дек-12, (168) –1   Зато может помочь сбой в фирмвари накопителя, логики контроллера, драйверов устр, Аноним (-), 23:09 , 27-Дек-12, (177) +1   Плюсую Всегда приятно видеть человека, разбирающегося в работе системы глубоко , AlexAT (ok), 09:37 , 28-Дек-12, (179)   zdb 8212 штатная утилита отладки ZFS Ну, напиши бывшим разработчикам Sun, соз, iZEN (ok), 17:07 , 29-Дек-12, (181)   Проще задать вопрос а собственно, где ныне Sun со своими мега-разработками , AlexAT (ok), 22:13 , 29-Дек-12, (182)   Я уважаю ваше мнение и оно вполне справедливо для идеального случая К сожалению, dalco (ok), 10:09 , 19-Дек-12, (56) –1   Оно справедливо для случая, когда и админ, и руководство - вменяемы В России эт, AlexAT (ok), 10:15 , 19-Дек-12, (57) +1   Да Так как классические решения не обеспечивают сквозную целостность данных и д, iZEN (ok), 08:27 , 19-Дек-12, (51) –1 // Твоя СЦД - это миф Правда, не понимая принципов работы железа, этого не понять , AlexAT (ok), 09:32 , 19-Дек-12, (52) Она не моя, а ваша 8212 сквозная целостность в Btrfs, за которую я не поручус, iZEN (ok), 13:55 , 19-Дек-12, (63) –1 Например здесь https groups google com forum fromgroups topic comp unix so, AlexAT (ok), 14:17 , 19-Дек-12, (65) +1 Там массив просто не импортируется Что делал до этого 8212 х з , может он по, iZEN (ok), 16:14 , 19-Дек-12, (70) –1 Просто спроси этого клоуна у него оперативка с ECC хотя-бы есть Я думаю что зн, Аноним (-), 17:21 , 19-Дек-12, (82) Обеспечит одно 8212 прекращение работы с пулом , iZEN (ok), 18:25 , 19-Дек-12, (92) А как ты узнаешь когда тебе уже прекращать работать с пулом , Аноним (-), 19:02 , 19-Дек-12, (97) Пул перейдёт в состояние STOPPED Файловые системы в пуле, соответственно, не бу, iZEN (ok), 07:33 , 20-Дек-12, (125) –1 Пул о повреждении памяти узнает очень и очень поздно , AlexAT (ok), 08:05 , 20-Дек-12, (129) +2 Пардон, пул в это состояние перейдет когда там получится настолько крутая вермиш, Аноним (-), 17:25 , 20-Дек-12, (150) А система об этом не узнает долго-долго, пока вновь не попытается считать повреж, AlexAT (ok), 19:25 , 19-Дек-12, (101) Думаешь, у таких монстров Btrfs и ZFS нет обратной связи с дисками во время за, iZEN (ok), 07:36 , 20-Дек-12, (126) –3 Бугага 100 незнание предмета детектед Запись-то корректно пройдёт Вот только, AlexAT (ok), 08:06 , 20-Дек-12, (130) +3 я лучше спрошу тебя, клоуна ты можете предложить что-то другое, лучше , Аноним (-), 06:19 , 20-Дек-12, (121) –1 Мы можете предположить что если уж понтоваться надежностью - то наверное на н, Аноним (-), 17:27 , 20-Дек-12, (151) +1 а ну т е ECC доверять можно 100 , хорошо про процессор мне еще расскажи , Аноним (-), 18:59 , 21-Дек-12, (165) –2 На 100 во всех случаяю - нельзя, но как минимум если проблема, особенно на уров, Аноним (-), 23:39 , 27-Дек-12, (178) А вы вообще Linux в глаза видели , myhand (ok), 20:24 , 19-Дек-12, (108) +1 Да недавно запускал Linux Mint Кинамон-какой-то Не понравилось то, что он не ру, iZEN (ok), 07:40 , 20-Дек-12, (127) –3 Ну да, я к тому - что в ваших комментариях только и читается обои не понравилис, myhand (ok), 12:46 , 20-Дек-12, (132) +1 Я слежу за новостями Вот тройка ссылок про md http www linux org ru jump-messa, iZEN (ok), 12:57 , 20-Дек-12, (135) –1 То, что вы процитировали - не новости , а срач на лоре Вы еще Московский Комсо, myhand (ok), 16:40 , 20-Дек-12, (138) –1 Менять можно было, но неудобно и долго Кажется, выглядело оно примерно так 1 Д, dalco (ok), 07:42 , 19-Дек-12, (49) Что они там курят колят в вену Любая хэш функция по определению имеет коллизи, CssfPZS (ok), 15:23 , 19-Дек-12, (68) // То что вы процитировали это какие-то эротические фантазии аффтара новости В pull, абыр (?), 16:24 , 19-Дек-12, (71) Речь про защиту от управляемого создание коллизий, как правило проблема решается, Аноним (-), 17:17 , 19-Дек-12, (78) Имелась в виду замена алгоритма CRC32 на иной, более устойчивый к b целенаправл, Аноним (-), 17:24 , 19-Дек-12, (83) 1,3,5,22,31,39,46,68

Сообщения

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

	50. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от dalco (ok), 19-Дек-12, 07:52
	> А оно, простите, нужно? При наличии md / HW RAID? Ну, кроме > как для извращений "а вот у меня рейд прямо в файловой > системе"? Когда конфигурация дискового пула стабильна, то, в большинстве случаев, оно без разницы - какими средствами raid организован (MD/HW/BTRFS/ZFS). А вот если количество и объем винтов постоянно гуляет, то FS, берущая на себя управление рейдом, оказывается выгоднее - тупо гораздо меньшее количество дисковых операций при изменении конфы дискового пула.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok), 19-Дек-12, 09:33
	> А вот если количество и объем винтов постоянно гуляет - самое время решить админа премии, а то и уволить, за открытую дестабилизацию системы. Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 10:00
	> Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо > расширение объёма - но эта операция, на чём бы RAID ни > был собран, является операцией критичной, и требует планирования работ. Кроме того, > правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления > винта каждый месяц можно поставить 12 винтов сразу, и забыть на > полгода. а что критичного в этой операции? уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп (хотсвоп) или просто доставил винты, подключил к пулу и пошел пиво пить. юзеры как работали, так и работают дальше ничего не замечая.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Очередная порция улучшений в Btrfs"	+4 +/–
	Сообщение от AlexAT (ok), 19-Дек-12, 10:05
	> а что критичного в этой операции? Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный бэкап перед операцией должен быть. Да, речь про рейды, а не про спаны. > уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот об этой критичности как раз и речь. Обязательно надо планировать возможность простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже если это кластер. Потому что выход кластера в нештатный режим - тоже проблема, и серьезная. > подключил к пулу и пошел пиво пить А в это время (с)... так и пивом можно подавиться в пессимистичном варианте.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 10:49
	>> а что критичного в этой операции? > Вероятность того, что что-то пойдёт не так в процессе. Как минимум оперативный > бэкап перед операцией должен быть. Да, речь про рейды, а не > про спаны. Не так пойдет - если вы с пьяного глаза, выдерните винт из соседнего сервера, а потом завалите стойку, запнувшись об свою ногу и в процессе падения умудритесь еще ухватить толстый жгут витой поры. >> уже давно: вытащил винты из пула, поставил более емкие в режиме нонстоп > Ага, разбили отказоустойчивость, вытащив винты. Пошли перестраивать массив. И до окончания > операции у вас [внезапно] отвалился один из винтов. Дальше что? Вот > об этой критичности как раз и речь. Обязательно надо планировать возможность > простоя, и заранее продумывать recovery operations в случае сбоя процесса. Даже > если это кластер. Потому что выход кластера в нештатный режим - > тоже проблема, и серьезная. А дальше ничего страшного, у нас же raidz2, а то и raidz3 на шибко больших массивах.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 19-Дек-12, 14:04
	> Не так пойдет - если вы с пьяного глаза, выдерните винт из Наивняк, верящий в 100% надежность железа во время критичных операций с ним, обычно либо быстро переучивается, либо его переучивают с вазелином после первого случая. > А дальше ничего страшного, у нас же raidz2, а то и raidz3 > на шибко больших массивах. Флаг в жо^W руки - считать на CPU RS-коды. http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai... Если у вас "шибко большие массивы" - то откуда у вас софтовые рейды, удел нищебродов? Ну и да - удачи вам в случае чего в forensic с разваленного RAID-Z :)
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 17:20
	> Флаг в жо^W руки - считать на CPU RS-коды. Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно вычислить посмотрев с какой из них чексуммы сходятся.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 19-Дек-12, 18:12
	> Ну в raid5 IIRC обычная XORка. Это быстро. А верную копию можно > вычислить посмотрев с какой из них чексуммы сходятся. Так речь про Z2/Z3 или все-таки про R5/Z?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 18:57
	> Так речь про Z2/Z3 или все-таки про R5/Z? Про сабжа и raid 5 :)
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 06:03
	> Наивняк, верящий в 100% надежность железа во время критичных операций с ним, > обычно либо быстро переучивается, либо его переучивают с вазелином после первого > случая. Да, переучился быстро, после того, как 3варе умирая забрала с собой и данные. Теперь сильно спецефичного железа, перед троганием которого нужно долго чесать левое ухо правой пяткой, не имею. > Флаг в жо^W руки - считать на CPU RS-коды. > http://blog.lexa.ru/2012/09/01/adaptec_5805_raid6_vs_zfs_rai... а мне не критична скорость, мне критична надежность и удобство, в том числе снапшоты, которых в ваших адаптеках сколько, напомните мне. > Если у вас "шибко большие массивы" - то откуда у вас софтовые > рейды, удел нищебродов? еще одна точка отказа, это видимо удел не нищебродов, с чем я вас и поздравляю. > Ну и да - удачи вам в случае чего в forensic с > разваленного RAID-Z :) как бы вам это донести... у меня зфс пережила то, что не пережили железные контроллеры... вижу вы уже поняли, что нельзя полагаться на железо, теперь вам пену у рта надо подтереть и подумать, если вы способны на это.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	154. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 17:56
	> как бы вам это донести... у меня зфс пережила то, А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok), 20-Дек-12, 18:11
	>> как бы вам это донести... у меня зфс пережила то, > А на лисяре перец красиво отскрeбал ZFS после всего лишь обычного bad sector. Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и не было на тот момент штатной команды "zpool import -F".
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 20-Дек-12, 22:39
	> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и > не было на тот момент штатной команды "zpool import -F". Проблема на самом деле не в том. А в том что средств для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула как я понимаю нет и не планируется. Такой подход невыгодно отличается от традиционного в случае когда что-то пошло не так, факап получился и авария вышла за те рамки которые предусматривали проектировщики ФС в своем сферическом вакууме.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok), 21-Дек-12, 20:19
	>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и >> не было на тот момент штатной команды "zpool import -F". > Проблема на самом деле не в том. А в том что средств > для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула > как я понимаю нет и не планируется. Видишь ли, сам принцип CoW не может позволить навернуться существующим данным и новым данным записаться "не туда". Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW). Это делается чаще автоматически при восстановлении после сбоев, но иногда случаются казусы при серьёзных сбоях, когда пул потерял избыточность и получить _непротиворечивые_ метаданные неоткуда. В последнем случае требуется ручной импорт пула командой "zpool import -F" с целью проанализировать потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться достать данные, которые уцелели. > Такой подход невыгодно отличается > от традиционного в случае когда что-то пошло не так, факап получился > и авария вышла за те рамки которые предусматривали проектировщики ФС в > своем сферическом вакууме. Классический подход с fsck связан с offline-проверкой и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте сами кашу из анонимных файлов. scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения вплоть до имён потерянных файлов с полными путями к ним.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 27-Дек-12, 23:09
	>> для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула >> как я понимаю нет и не планируется. > Видишь ли, сам принцип CoW не может позволить навернуться существующим данным Зато может помочь сбой в фирмвари накопителя, логики контроллера, драйверов устройств и ФС, различные глюки оборудования (RAM, CPU, каналов передачи) и даже просто элементарные внезапно вылездшие бэды. Да, ваша долбаная ZFS рассчитана только на аварии не крупнее проектного дизайна. А если у вас факап запроектного масштаба (т.е. не тот сферический факуум который предусмотрели разработчики) - ничего не знаем, разгребайте свое радиоактивное гэ сами, а мы не при чем, это не мы тот РБМК-1000 дизайнили и поставляли, наша хата вообще с краю, ничего не знаю: мы написали AS IS и все такое - попробуйте теперь с нас слупить чего-нибудь. А как вы там эти радиоактивные ошметки соберете - всем пофиг. Пускайте дескать парней с хэксэдитором, если там что-то ценное а нужного бэкапа вдруг нет. > и новым данным записаться "не туда". Так может думать только наивный чукотский юножа^W^W жабист, который просто не знает как и что сделано а потому очень хило представляет себе как это работает. Однако замечу что даже элементарнейшие бэд-сектора и любые глюки железа уже не вписываются в эту сферически-вакуумную концепцию. Что в реальном мире может являть проблему. > Поэтому для починки упавшей CoW-ФС достаточно отмотать её состояние на некоторое > время назад, где метаданные были целы (метаданные тоже подчиняются принципу CoW). Есть одно важное допущение: допускается что вся эта механика до точки отказа не пострадала и сможет корректно отработат. А какой-нибудь подлый бэд вылезший на (мета)данных записанных год назад может и не разделить оптимизм по этому поводу :). В такой ситуации попытка отмотать может делать даже хуже, потому что довольно сложная логика нарвется на редкое краевое ошибочное состояние. Из которого к тому же может не быть осмысленного (в плане продолжения корректной работы) выхода в хучшем случае. По нашему это называетсы "нащла коса на камень". Неплохо отражает смысл того что получается когда CoW пытается откатить снапшот и тут вдруг окжется что именно там половина данных/метаданных на наше несчастье дали дуба. Никакого рекавери из такого сценария CoW сам по себе не дает: это "запроектная" авария. Хотя пачка бэдов на винче - вполне себе наблюдаемое явление природы. > потери массива скрабингом (scrub работает только на импортированном пуле) и попытаться > достать данные, которые уцелели. Вот, до тебя начинает доходить почему fsck не настолько уж и маразм. >> и авария вышла за те рамки которые предусматривали проектировщики ФС в >> своем сферическом вакууме. > Классический подход с fsck связан с offline-проверкой Что является весьма умным вариантом - при эксклюзивном доступе к диску утиль может делать ряд допушений которые иначе делать не вышло бы. Это ж не для красоты придумали. А из соображения минимизации сложности, улучшения надежности и предсказуемости таковых операций. Например агрессивные попытки починить смонтированный диск к которому ведется активный доступ могут не вести к хорошим результатам. Просто потому что при этом надо разруливать одновременный доступ + деликатные операции + данные ФС потенциально разрушены. Поэтому онлайн обычно если и делают починку то в довольно лайтовой версии. > и сваливанием в кучу ошмётков данных в /.lost+found — разгребайте > сами кашу из анонимных файлов. А это только когда удалось понять что вон то возможно было неким файлом/дирой, но совершенно не удалось понять к чему оно относилось. Это конечно не идеальный способ починки, но единственной альтернативой в таком случае является разве что просто совсем очистить спорную территорию. > scrub же выполняется на примонтированном пуле online и даёт полную картину разрушения > вплоть до имён потерянных файлов с полными путями к ним. Как ты понимаешь, имена хранятся в метаданных. Чтобы их оттуда вынуть - эти метаданные должны для начала быть. А вот этого никто не обещал, между прочим. Частично такое лечится райд-уровнями и прочая - вероятность ситуации снижается. Зато если уж завалится, +10 к геморности разруливания вручную каждый лишний уровень абстракции даст. Дата рекавери лабы в курсе и за любой вид рэйда сразу накидывают изрядно бабла к стоимости процедуры.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	179. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 28-Дек-12, 09:37
	Плюсую. Всегда приятно видеть человека, разбирающегося в работе системы глубоко.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	181. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от iZEN (ok), 29-Дек-12, 17:07
	>> Помнится, у него был пул в состояние FAULTED (уже не DEGRADED) и >> не было на тот момент штатной команды "zpool import -F". > Проблема на самом деле не в том. А в том что средств > для починки или хотя-бы вытаскивания данных в случае серьезно факапнутого пула > как я понимаю нет и не планируется. zdb — штатная утилита отладки ZFS. > Такой подход невыгодно отличается > от традиционного в случае когда что-то пошло не так, факап получился > и авария вышла за те рамки которые предусматривали проектировщики ФС в > своем сферическом вакууме. Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 29-Дек-12, 22:13
	> Ну, напиши бывшим разработчикам Sun, создавшим ZFS, что они дураки и ничего > не смыслят в файловых системах. Заодно задай вопрос, почему нет fsck. Проще задать вопрос: а собственно, где ныне Sun со своими мега-разработками :)
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	56. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от dalco (ok), 19-Дек-12, 10:09
	>Количество дисков в стабильной системе НЕ ГУЛЯЕТ. Вполне возможно, что постоянно необходимо расширение объёма - но эта операция, на чём бы RAID ни был собран, является операцией критичной, и требует планирования работ. Кроме того, правильное планирование позволяет "гулять" пулы вверх достаточно редко - вместо добавления винта каждый месяц можно поставить 12 винтов сразу, и забыть на полгода. Я уважаю ваше мнение и оно вполне справедливо для идеального случая. К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых полках или свободных винтов, которые можно запихнуть туда "про запас" на пол-года вперед. И проблема не в админе, а в финансировании (начальство на спичках экономит). Или, что тоже часто бывает, всплывает задача, которую надо решить "здесь и сейчас" без оглядки на планы КПСС для третьей пятилетки. Так что лишняя гибкость в конфигурации дискового пула никому не помешает. Если оно _вам_ не нужно, то это еще не значит, что оно _никому_ не нужно ⓒ
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	57. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok), 19-Дек-12, 10:15
	> Я уважаю ваше мнение и оно вполне справедливо для идеального случая. Оно справедливо для случая, когда и админ, и руководство - вменяемы. В России это встречается не часто, угу. > К сожалению, в реальной жизни иногда тупо нет свободного места в дисковых > полках или свободных винтов, которые можно запихнуть туда "про запас" на > пол-года вперед. Это проблема планирования нагрузки, и решается она административно. > И проблема не в админе, а в финансировании (начальство на спичках экономит). Ну Россия, да, угу... > Если оно _вам_ не нужно, то это еще не значит, что оно > _никому_ не нужно ⓒ Оно не не нужно, оно неправильно и рискованно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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