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

Очередная порция улучшений в 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]

	29. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 18-Дек-12, 23:10
	> констатирует, что для ряда нагрузок пока есть отставание Btrfs от XFS и EXT4 Видимо Крис добрел до фороникса :)
	Ответить | Правка | Наверх | Cообщить модератору

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

	76. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 17:16
	> проигрывал ext4 "ФС завтрашнего дня", эмм.., тогда меня вполне устраивают достижения > дня сегодняшнего :-) Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное свойство которое может хотеться от ФС. > Так что похороникс, как и что бы он там не мерял своим комбитестом таки прав Да в общем то по тестам форониксов вполне можно делать некие выводы. А бочку на них обычно катят те фанаты, чей фетиш проиграл в пузомерке. А само по себе бенчи как бенчи. Не хуже остальных. По крайней мере, конфига - описана, что померяно и что вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 19-Дек-12, 17:19
	> Скорость - это замечательно, хорошо и правильно. Но все-таки это не единственное > свойство которое может хотеться от ФС. Да нет, я не спорю, что у него есть масса преимуществ для серверов, но мне то они как то по барабану > Да в общем то по тестам форониксов вполне можно делать некие выводы. > А бочку на них обычно катят те фанаты, чей фетиш проиграл > в пузомерке. А само по себе бенчи как бенчи. Не хуже > остальных. По крайней мере, конфига - описана, что померяно и что > вышло - тоже. В случае больших разбросов погрешность отложена. Вполне съедобно. Вообще  то, да
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (-), 19-Дек-12, 17:44
	> Да нет, я не спорю, что у него есть масса преимуществ для серверов, Как бы это сказать? Я и на десктопе не против иметь возможность отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял данные. А так я смогу сгонять в прошлое и исправить свои (и не только свои) ощибки. Круто же :). Да и возможность подоткнуть при нехватке места +1 диск и ребаланс на него сделать - и на десктопе имхо вполне пригодится. > но мне то они как то по барабану Кому как, кому как. > Вообще  то, да Ну по крайней мере критики обычно демонстрируют еще более убогое нечто.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 19-Дек-12, 17:49
	> Как бы это сказать? Я и на десктопе не против иметь возможность > отмотать назад. Была парочка обидных прецедентов, когда я из-за промашки терял > данные. А так я смогу сгонять в прошлое и исправить свои > (и не только свои) ощибки. Ну, для этого есть бэкапы и не только на другой диск. Причем при их использовании нет потери в производительности, как в btrfs
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 19-Дек-12, 18:56
	> Ну, для этого есть бэкапы и не только на другой диск. Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну и я тоже. А btrfs так может, снапшоты вытекают из его устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 секунд. > Причем при их использовании нет потери в производительности, как в btrfs Потеря производительности - понятие относительное. Я в курсе кто такой CoW и как с ним мирно сосуществовать, пользуясь им на мое благо а не во вред. Я с удовольствием юзану его плюсы и не попаду под минусы. Я же не изен и нагуал все-таки, которые вообще не вдупляют как это работает.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok), 19-Дек-12, 19:29
	Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию (например массированное обновление софта или что-то масштабное над БД), в случае чего откатываемся единым куском. В случае успеха снапшот удаляем.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 19-Дек-12, 20:18
	> Вот. Реальное удобство снапшота именно в этом: делаем снапшот, выполняем критичную операцию > (например массированное обновление софта или что-то масштабное над БД), в случае > чего откатываемся единым куском. В случае успеха снапшот удаляем. заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-)
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok), 19-Дек-12, 21:41
	> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-) То же самое - вы не получите уже в силу завязанности процедуры на расписание бэкапа.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 19-Дек-12, 21:44
	>> заменяем снапшот на бэкап, получаем тоже самое и без потери производительности :-) > То же самое - вы не получите уже в силу завязанности процедуры > на расписание бэкапа. выполняем критичную операцию =бэкап
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok), 19-Дек-12, 21:58
	> выполняем критичную операцию =бэкап А вам объяснили, как вместо этого можно использовать снапшот.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 00:59
	>> выполняем критичную операцию =бэкап > А вам объяснили, как вместо этого можно использовать снапшот. C потерей производительности основных операций. "Можно грибок съем, он такой красивый ? Можно , только это бледная поганка" © :-)
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	117. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от myhand (ok), 20-Дек-12, 01:13
	>>> выполняем критичную операцию =бэкап >> А вам объяснили, как вместо этого можно использовать снапшот. > C потерей производительности основных операций. А бэкап, значицца на ентой производительности никак не сказывается?  Ну-ну... > Можно грибок съем, он такой красивый ? Завязывайте с грибками, сэр.  Они уже явно оказали негативное влияние на ваш мозг.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	155. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 20-Дек-12, 18:11
	> выполняем критичную операцию =бэкап Вариант, но как я уже сказал, бэкапаться раз в 30 секунд вы не будете. А вот бтрфс автоснапшоты сам лепит с такой регулярностью. Ну, как точки консистентности для отката на них при крахе. Конечно в идеале можно побухтеть про то что ощибаться не надо, но в реальном мире люди все-таки ошибаются. Иначе бы в софте не было багов :)
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Tav (ok), 20-Дек-12, 03:43
	Резервные копии делаются по расписанию или по требованию пользователя и их создание занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, одно другому не замена. Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	131. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 08:06
	> Резервные копии делаются по расписанию или по требованию пользователя и их создание > занимает время. Снимки могут автоматически создаваться системным ПО перед выполнением > потенциально опасных действий (обновление, например) и создаются моментально. Очевидно, > одно другому не замена. > Например, в OpenSolaris с ZFS так было: при обновлении автоматически создается снимок, > в меню загрузчика появляется пункт, позволяющий загрузиться в состояние до обновления. Не замена в том плане, что за удобство платят снижением производительности. Чудес на свете не бывает - если где то сделали гуд, то только за счет того, что в другом месте сделали каку
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от myhand (ok), 20-Дек-12, 12:51
	> Не замена в том плане, что за удобство платят снижением производительности. Вам уже заметили: бэкап тоже влияет на производительность. > Чудес на свете не бывает - если где то сделали гуд, то > только за счет того, что в другом месте сделали каку Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 12:54
	> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, > вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами? Пока что получается ровно напротив - удобство снапшотов приводит к снижению производительности
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	139. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от myhand (ok), 20-Дек-12, 16:43
	> удобство снапшотов приводит к снижению производительности Что в лоб - что по лбу.  Вы вообще - читаете что вам пишут?
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	140. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 16:45
	>> удобство снапшотов приводит к снижению производительности > Что в лоб - что по лбу.  Вы вообще - читаете > что вам пишут? В начало треда и в саму новость. Курить до просветления ☺
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	145. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 17:13
	> В начало треда и в саму новость. Тогда зачем вы отвечаете, если коменты не читали? :)
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	146. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 17:17
	>> В начало треда и в саму новость. > Тогда зачем вы отвечаете, если коменты не читали? :) Кто ж виноват, что именно вы забыли. с чего вообще начиналась полемика☺
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	141. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 20-Дек-12, 16:47
	> Да нет, "бывает".  Наука называется, технологии - все дела.  Надеюсь, > вы не собираетесь здесь отстаивать достоинства радиоламп перед транзисторами? Для качественных усилков, как ни удивительно - лучше радиолампы. Всем транзисторы хороши... но вот каку с нелинейностью всё-таки подложили :)
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	147. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (-), 20-Дек-12, 17:20
	> но вот каку с нелинейностью всё-таки подложили :) Подложили. Но в современных экспонатах с правильно рассчитанными режимами нелинейность столь незначительна что иные факторы ее перевесят без особых проблем. А цифровая обработка сигнала на большей части пути избавляет от накопления помех свойственных аналоговой технике к тому же. По поводу чего все это ламподр@черство - обычный фетишизм. Мало чем подкрепленный технологически. Хотя для фетищистов есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает звучание? :)
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	148. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от AlexAT (ok), 20-Дек-12, 17:22
	> есть и эзернет-шнурки из бескислородной меди, с золочеными разъемами. Всего по > килобаксу за кабель, чтоли :). Как ты думаешь, насколько оно улучшает > звучание? :) Сигнал - улучшает, звучание - на 0, за пределами слуха.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	157. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 18:18
	> Сигнал - улучшает, ...только цифровым технологиям это улучшение сильно пофиг. Сигнал эзернета или попал в валидный диапазон и пакет был декодирован верно, или уж не попал и пакет забракован и перепослан. Этот факт заинкрементирует соотв. счетчик, проблема с линком будет видна. А если этот счетчик все-время ноль, на кой буй чинить то что не сломано, улучшив линию на какой-то мизер, при том что сетевки и так не жаловались ни на что? В результате получается выкинутый на ветер килобакс: передача данных вообще не изменилась, а килобакс потрачен :) > звучание - на 0, за пределами слуха. В случае эзернета - пардон, изменений будет вообще ноль. В случае ламп - да там тоже смотреть надо. Например лампы довольно хлипкие и какая-нибудь вибрация на раз будет трясти электроды, вызывая паразитную модуляцию, например. Но ясен фиг ушибленные аудиофилы не замеряют суммарные искажения и улучшения от применения ламп. Их в индустрии просто методично доят, намного круче чем многих других :)
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	106. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 19-Дек-12, 20:17
	> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну > и я тоже. А btrfs так может, снапшоты вытекают из его > устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 > секунд. 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что не иметь постоянных лулзов с меньшей производительностью
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	122. "Очередная порция улучшений в Btrfs"	+2 +/–
	Сообщение от Аноним (-), 20-Дек-12, 06:26
	>> Сравнили ж.. с пальцем. Вот вы будете бэкапаться каждые 30 секунд? Ну >> и я тоже. А btrfs так может, снапшоты вытекают из его >> устройства. Поэтому ему не в облом автоматически чекпойнтиться раз в 30 >> секунд. > 2 раза в сутки, и, честно говоря, мне этого вполне хватает, что > не иметь постоянных лулзов с меньшей производительностью ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в сутки побекапить и хранить хотя бы 10-ок копий за разные периоды
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Очередная порция улучшений в Btrfs"	–2 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 08:05
	> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в > сутки побекапить и хранить хотя бы 10-ок копий за разные периоды Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже пояса сломать, нО обязательно ли это  делать ? ☺ Логика такая же
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 21-Дек-12, 19:25
	>> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в >> сутки побекапить и хранить хотя бы 10-ок копий за разные периоды > Это широко рапространенная задача ? Нет, сдуру можно и кое что пониже > пояса сломать, нО обязательно ли это  делать ? ☺ Логика > такая же как бы вам объяснить, вот у меня очень мало серверов, где инкрементный бекап укладывается в один час, как правило бекап делается от трех часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов (до 80%) и ЦПУ на 6-ть часов в сутки, либо же их устроит падение производительности постоянное, но не большое, скажем 10%?
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от AlexAT (ok), 21-Дек-12, 20:53
	> как бы вам объяснить, вот у меня очень мало серверов, где инкрементный > бекап укладывается в один час, как правило бекап делается от трех > часов. все сервера должны быть доступны 24*7*30 и нагрузка не очень > сильно меняется от времени суток. теперь внимание, вопрос. будут ли довольны > клиенты сервисом, у которого стоит ext4 и происходит проседание производительности винтов > (до 80%) и ЦПУ на 6-ть часов в сутки, либо же > их устроит падение производительности постоянное, но не большое, скажем 10%? ionice отменили?
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 13:02
	> ну ка попробуйте 50 млн инодов и 20ТБ данных два раза в > сутки побекапить и хранить хотя бы 10-ок копий за разные периоды И да, гугель как то вообще обходится даже без журналирования, при этом цветет и пахнет. Инженеры в нем какие то не те, наверное  ☺
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

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

	152. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 17:28
	>> И да, гугель как то вообще обходится даже без журналирования, > Дома как-то очень несподручно ставить столько же компов сколько есть у гугеля > чтобы развернуть там распределенную отказоустойчивую ФС. да тут вопрос собственно в приоритетах, если чоловику первичны эти снапшоты через 30 сек с потерей производительности, он выберет Btrfs; если первична нормальная производительность, и он не страдает что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 18:24
	> да тут вопрос собственно в приоритетах, Да, у гугля надежность совершенно не в приоритете: благодаря устройству их распределенных систем, они выдерживают выгорание сервака синим пламенем вообще без прерывания сервиса. Но для этого очевидно должно быть довольно много серверов хранящих блоки избыточных данных, да? :) > если чоловику первичны эти снапшоты через 30 сек с потерей производительности, С потерей производительности - это в LVM. А в бтрфс это просто часть дизайна. То-есть, фс по сути ничего нового вообще не делает, она лишь фиксирует что теперь вон тот набор данных и метаданных считается за снапшот. Тупить оно начнет если сделать кучу снапшотов, забыв о том что отличия между ними хранятся и жрут место, и потом долго фигарить на своей волне, нарастив огромный объем изменений относительно снапшота. Да, старые снапшоты надо иногда подтирать, иначе вообще кончится место - чудес не бывает. А в автомобили надо иногда заливать горючее и накачивать шины. Это не баг - это просто особенность технологии. > он выберет Btrfs; если первична нормальная производительность, и он не страдает > что по крону 2 раза в сутки фоном запускается бэкап, то он плюнет на Btrfs Бэкап 2 раза в сутки - это прекрасно, но есть некая разница между "2 раза в сутки" и "раз в 30 секунд".
	Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

	159. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от SergMarkov (ok), 20-Дек-12, 18:35
	Тьфу ты Ё, как по бенгазильски пишу. Читай в самой новости "уступает в производительности ext4". Почему оно уступает мне по глубокому барабану. И для меня первична производительность, а не снапшоты через 30 сек. В офисе, в котором работаю, есть плагин для сохранения в гугледоки, и мне совершенно не нужен этот снапшот через каждые 30 сек. Плюс бэкапы 2 разы в день
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	160. "Очередная порция улучшений в Btrfs"	+1 +/–
	Сообщение от Аноним (-), 20-Дек-12, 22:35
	> в производительности ext4". Почему оно уступает мне по глубокому барабану. Запорожес с горы Арарат легко обгонит какой-нибудь Феррари. Будешь водителем запорожца? :)
	Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

	169. "Очередная порция улучшений в Btrfs"	–1 +/–
	Сообщение от iZEN (ok), 21-Дек-12, 20:26
	> Тупить оно начнет если сделать кучу снапшотов, Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах начинает тупить? В ZFS "по барабану", сколько снапшотов. > забыв о том что отличия > между ними хранятся и жрут место, и потом долго фигарить на > своей волне, нарастив огромный объем изменений относительно снапшота. И что?
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	176. "Очередная порция улучшений в Btrfs"	+/–
	Сообщение от Аноним (-), 27-Дек-12, 22:39
	> Неужели такой бзмозглый дизайн CoW-ФС Btrfs, что она уже на нескольких снапшотах > начинает тупить? В ZFS "по барабану", сколько снапшотов. Да, там путем черной магии обманывают физику и логику, ну конечно же :). Особенно эпично подобные заявы смотрятся от эксперта по получению 6Мб/сек на шпиндель, который даже в такой позе и то не забывает верещать что дефрагер - лишний понт. Ну, знаешь, не у всех понятия о производительности дисковых ФС такие же как у тебя :) >> своей волне, нарастив огромный объем изменений относительно снапшота. > И что? И то - и фрагментация растет + оверхед на майнтенанс "лоскутного одеяла" выше. Чудес не бывает. И если б ты не был жабистом и понимал как работают компьютеры, ты бы понял почему лоскутное одеяло из кучи кусочков не сможет разогнаться до той же скорости что и большой непрерывный кусок, читаемый одним чихом.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

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

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