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

Хостинг-оператор Anchor протестировал Btrfs на готовность к ..., opennews (?), 26-Апр-13, (0) [смотреть все] это вам не похороникс сравнил убунту и федору , Анонимус_б6 (?), 23:34 , 26-Апр-13, (1) +26 // Превед от Шишкина , z (??), 23:39 , 26-Апр-13, (2) –2   // А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина , Аноним (-), 00:00 , 27-Апр-13, (5) +2   // Нет, разумеется Потому что у эксплуатационщиков в отличие от теоретиков хватает, Аноним (-), 00:27 , 27-Апр-13, (6) +3   Скорее, хватает ума понять, что метаданные - неотъемлемая часть ФС, и требовать , Аноним (-), 01:53 , 27-Апр-13, (9)   том на 600Мб -- 10 лет нвзад забитый мелкими файлами -- Maildirs, Deffic (?), 03:56 , 27-Апр-13, (14) +2   Во-первых, не 10, а 15 Во-вторых, с учетом скорости развития IT это звучит прим, angra (ok), 10:43 , 27-Апр-13, (23)   Что характерно, общая сложность задач возросла может быть в разы, но не на поряд, Аноним (-), 12:48 , 28-Апр-13, (72) +1   Маловероятно Одно дело - пригорание седалища у отдельно взятого разработчика, д, Аноним (-), 01:54 , 27-Апр-13, (10)   Критика Шишкина, напомню, касалась разноса ФС при определённых условиях, когда, z (??), 10:25 , 27-Апр-13, (21)   Шишкин, перелогиньтесь , quux (??), 12:16 , 27-Апр-13, (24)   Любую ФС можно загнать в ситуацию когда ее КПД равен нулю Создаем до упора файл, Аноним (-), 12:34 , 27-Апр-13, (26) +1   Приятно видеть человека, который пытается думать, даже несмотря на то, что у нег, z (??), 13:50 , 27-Апр-13, (33) +4   А подробности можно услышать Где именно вырождается, как это влияет на размер д, Bx (ok), 15:51 , 27-Апр-13, (36) –1   https lkml org lkml 2010 6 18 144, z (??), 15:54 , 27-Апр-13, (37) +2   Хорошо сказал, между прочим use the original ones from proper academic papers D, z (??), 16:07 , 27-Апр-13, (38) +3   Там другое, авто-проверки ругнулись на непонятные им данные, инициализцию и екну, Bx (ok), 17:35 , 27-Апр-13, (42) –1   Мде, пруф искать лень, что-то там про 640 килобайт тоже было, не 3 года, конечно, Bx (ok), 16:49 , 27-Апр-13, (39)   gt оверквотинг удален И что не нравится Трата места на метаданные Повторит, nagual (ok), 17:36 , 27-Апр-13, (43) –1   Я, как-бы, защитник btrfs Потрудитесь почитать линк, на который я отвечал , Bx (ok), 17:46 , 27-Апр-13, (44) –1   И чем это так уж отличается от иных вырожденных случаев, типа забития тома нулев, Аноним (-), 18:21 , 27-Апр-13, (45) –1   в дискуссии, вообще-то, ссылку приводили отличается это тем, что авторы btrfs п, arisu (ok), 18:36 , 27-Апр-13, (48)   А что тут такого нехорошего , Аноним (-), 22:24 , 27-Апр-13, (51) –2   просто никогда не пиши реализацию хэш-таблиц, хорошо воспользуйся готовой из ст, arisu (ok), 23:44 , 27-Апр-13, (56) +3   больше заискивающих смайликов, больше , arisu (ok), 00:59 , 28-Апр-13, (66)   Сдаётся мне, это опять демагог debugger Порешил , Michael Shigorin (ok), 18:01 , 29-Апр-13, (103) +1   Если уж на то пошло, у очень многих алгоритмов применяемых нынче в софте средни, Аноним (-), 01:36 , 28-Апр-13, (68) –1   В новостях пробегало - достаточно создать всего 64 файла что бы убить btrfs в, linux must _RIP_ (?), 19:29 , 29-Апр-13, (107) –1   Похороникс чуть раньше сравнил ZFS и EXT4 Результат был предсказуем , Аноним (-), 23:59 , 26-Апр-13, (4) +2 // Это что ли сравнение http www phoronix com scan php page news_item px MTM1ODk, iZEN (ok), 08:06 , 27-Апр-13, (15) –6 // Ты как-то очень изящно подтасовываешь результаты Я про http www phoronix com , Аноним (-), 12:38 , 27-Апр-13, (29) +1 Справедливости ради, ZFS тоже не любит многопоточного доступа Раньше были вилы , iZEN (ok), 23:52 , 26-Апр-13, (3) –4 // Почему не используешь EXT4 или NTFS , Аноним (-), 00:38 , 27-Апр-13, (7) // С чего вы взяли, что он не использует NTFS , Аноним (-), 01:52 , 27-Апр-13, (8) +12 EXT4 не собираюсь использовать 8212 слишком много костылей нагородили вокруг , iZEN (ok), 08:14 , 27-Апр-13, (17) –11 // Пруфлинк не прокатит, т к не ясно в чём было дело - в глюке оборудования, кривы, www2 (ok), 08:58 , 27-Апр-13, (19) +16 Я на DFBSD мигрирую на Hammer, бо после пары факапов UFS доверия уже нет Хотя H, Аноним (-), 17:42 , 28-Апр-13, (78) No silver bullet C Универсальной файловой системы на все случаи жизни нет и , Andrew Kolchoogin (?), 11:20 , 29-Апр-13, (95) +2 То начинать надо не с ZFS, да и заканчивать не ей Репликация и только репликаци, AlexAT (ok), 20:23 , 29-Апр-13, (119) +1 Скажи мне, человече, как ты планируешь это реализовать в RDBMS на задачах OLTP , Аноним (-), 16:15 , 30-Апр-13, (144) Вот куда-куда, а под rdbms и oltp, и dss кладут zfs только полные дауны , ананим (?), 17:43 , 30-Апр-13, (151) +1 Выше правильно ответили - положить ZFS да и вообще CoW под RDBMS может только ко, AlexAT (ok), 18:07 , 30-Апр-13, (152) +1 Маргиналы такие маргиналы , AlexAT (ok), 10:32 , 27-Апр-13, (22) +4 NTFS вполне себе работает, если дефрагментацию проводить хотябы раз в неделю , nagual (ok), 17:34 , 27-Апр-13, (41) –1 Фрибздшники палятся , Аноним (-), 18:32 , 27-Апр-13, (46) +1 ой если бы там дело в дефрагментации было , Карбофос (ok), 19:35 , 27-Апр-13, (49) –1 Слишком толсто , Аноним (-), 17:44 , 28-Апр-13, (79) –3 Это не шутка, если не делать дефрагментацию то тормоза можно почуствовать уже че, nagual (ok), 11:46 , 29-Апр-13, (98) –1 Мне трудно представить, что надо делать с томом, чтобы производительность деград, Аноним (-), 12:42 , 29-Апр-13, (99) –1 CoW , Аноним (-), 16:15 , 30-Апр-13, (145) Это было когда Solaris API пытались приладить к FreeBSD , Аноним (-), 02:06 , 27-Апр-13, (11) –1 Круто Впрочем там и веселее было - дедлок ядра при попытке вызвать sendfile А, Аноним (-), 02:49 , 27-Апр-13, (12) // А синюшника видно по чему Проблема явно где-то в zlib 3 , iZEN (ok), 08:08 , 27-Апр-13, (16) –6 // А как связаны архивы tbz и zlib , quux (??), 12:18 , 27-Апр-13, (25) Колбэками вызовов функций сжатия, очевидно , iZEN (ok), 12:34 , 27-Апр-13, (27) –10 Все бы ничего, но bzip не имеет к zlib у вообще никакого отношения Это вообще с, Аноним (-), 12:47 , 27-Апр-13, (30) +8 С точки зрения Изи, это одна программа - 7z exe , Аноним (-), 22:26 , 27-Апр-13, (52) +5 Шо, уже 14 февраля 2012 года таки наступило , Anonus (ok), 03:43 , 27-Апр-13, (13) –1 Как у BTRFS со стабильностью и производительностью Как, как Никак https pl, iZEN (ok), 08:57 , 27-Апр-13, (18) –6 // Что за выхлоп Обычный протухший бит на диске Да, и RAM сбоит, и шины данных сб, Аноним (-), 09:30 , 27-Апр-13, (20) // Вот здесь всё намного хуже http www youtube com watch v QGIwg6ye1gEНо ведь выж, iZEN (ok), 12:37 , 27-Апр-13, (28) –7 // RAID6 и любая фс тоже самое сделают Это как раз таки очень легкий случай полны, anonymous (??), 13:37 , 27-Апр-13, (32) +1 стабильность ext4 в 2 6 18 ну-ну в 2 4 с ext4 вообще полная жопа была trollface, ваноним (?), 13:26 , 27-Апр-13, (31) +1 // это ж фанобздоиды, у них такое считается 171 свежачком 187 , arisu (ok), 14:28 , 27-Апр-13, (34) +2 // Ну так их линукслятор как раз до 2 6 22 не добирает по фичам В 2 6 22 уже кус, Аноним (-), 18:36 , 27-Апр-13, (47) +1 пшшшшшш сейчас изя ещё багрепорты из 2 4 ветки принесёт , Карбофос (ok), 16:56 , 27-Апр-13, (40) +3 паника в ext4 это не модно А вот последний тред в linux-ext4 из-за того что о, linux must _RIP_ (?), 22:39 , 27-Апр-13, (54) –1 // А можно сцылочку , AlexAT (ok), 09:48 , 28-Апр-13, (71) +2 // а не важно, что это существо пишет это всегда ложь , arisu (ok), 14:00 , 28-Апр-13, (74) Не-а, порой есть сигнал , Michael Shigorin (ok), 18:07 , 29-Апр-13, (104) –2 при таком уровне зашумлености проще игнорировать полностью, нежели пытаться добы, arisu (ok), 18:15 , 29-Апр-13, (106) +1 Когда играют длинную симфонию, в тысячном зале чисто случайно, теоретически кто-, Led (ok), 01:33 , 30-Апр-13, (130) ну да, когда эта проблема стала темой обсуждения на FS Storage Summit в SF, в , linux must _RIP_ (?), 19:56 , 29-Апр-13, (113) –1 Обоим умерьте тон , Michael Shigorin (ok), 20:07 , 29-Апр-13, (116) –3 да ну то есть призывать к аборту это нормально Хм интересно как бы ты сдержа, linux must _RIP_ (?), 21:07 , 29-Апр-13, (120) http marc info l linux-ext4 m 136695619430425 w 2как-то так , linux must _RIP_ (?), 19:35 , 29-Апр-13, (108) –1 Не кривой уж тогда, а слегка быстро удаляет страницы в очень специфичном юзкейсе, AlexAT (ok), 21:38 , 29-Апр-13, (123) в сильно специфичном хм это теперь так называют полное игнорирование aging у , linux must _RIP_ (?), 23:15 , 29-Апр-13, (128) Пруф в студию Хотя бы прочитайте кейс - там всё расписано, что и как делается , AlexAT (ok), 07:35 , 30-Апр-13, (136) +1 Имею ничтожный с точки зрения продакшн-одминов опыт использования на домашнем де, Fracta1L (ok), 14:58 , 27-Апр-13, (35) // c ZFS очень хорошо помогает иметь отдельные устройства для zil log и L2ARC это , deadless (ok), 22:13 , 27-Апр-13, (50) –1 // Я думал ФС нужна для хранения данных необходимых для решения задач бизнеса А ва, 666некто (?), 22:30 , 27-Апр-13, (53) // а если это не бизнес, а just for fun , то фс не подходит как страшно жить бизн, Карбофос (ok), 23:00 , 27-Апр-13, (55) В данном случае для бизнеса можно заменить для использования , Аноним (-), 00:23 , 28-Апр-13, (58) А что вам мешает использовать ту же ZFS и на Линуксе , Fracta1L (ok), 07:25 , 28-Апр-13, (70) –1 // Линукс и так переусложнён, а тут ещё столько же строк кода, как у XFS Думаете, iZEN (ok), 17:19 , 28-Апр-13, (77) –1 Ядро не сильно засрано в отличие от юзерспейсов, гнома с их зависимостями , Аноним (-), 20:22 , 28-Апр-13, (87) ZFS орудие будущего, когда уже не будет механики и такого понятия как фрагмента, Аноним (-), 13:16 , 28-Апр-13, (73) –2 // Почему это орудие будущего тогда не поддерживает TRIM , AlexAT (ok), 16:19 , 28-Апр-13, (75) +1 // CoW ФС несовместимы с TRIM , iZEN (ok), 17:18 , 28-Апр-13, (76) –4 Бугага BTRFS прекрасно совместим Может быть, ZFS несовместима с TRIM Хотя TRI, AlexAT (ok), 18:47 , 28-Апр-13, (81) +1 CoW ФС распространяется на всё доступное пространство блочного устройства и зани, iZEN (ok), 15:56 , 29-Апр-13, (101) –1 hint blocksizePS в смысле тот, который устройство показывает наружу, а то ведь, Michael Shigorin (ok), 18:09 , 29-Апр-13, (105) Извини, бред про восстановления глубокие и неглубокие поскипан - не имеет отноше, AlexAT (ok), 19:42 , 29-Апр-13, (111) +2 Я говорил про CoW ФС вообще В вашем случае он решает В нашем случае TRIM ещё не, iZEN (ok), 01:36 , 30-Апр-13, (131) –2 CoW FS бывают разные Логично - ибо припёрт сравнительно недавно из нашего случая, AlexAT (ok), 07:44 , 30-Апр-13, (138) +1 Каким образом контроллер флэша начнёт процедуру GC, если не знает, какие конекре, iZEN (ok), 17:20 , 30-Апр-13, (148) –1 Бугага Ты не в курсе, что у левелера имеется невидимый ОС рабочий набор И конт, AlexAT (ok), 18:38 , 30-Апр-13, (156) +2 Нет, не в курсе Я не сомневаюсь в том, что в SSD есть определённый набор запасн, iZEN (ok), 19:56 , 30-Апр-13, (159) –2 Если бы ты хоть немножко вникал - было бы проще В левелерном наборе находятся в, AlexAT (ok), 20:42 , 30-Апр-13, (160) +2 gt оверквотинг удален Наш друг от маркетологии лишь тонко намекает что диски с, nagual (ok), 23:16 , 30-Апр-13, (162) –1 Подсовывайте в тестировании рандом, делов-то У меня стоит SSD на SandForce SF-2, AlexAT (ok), 23:51 , 30-Апр-13, (163) +1 О мой всегда говорящий правду и только правду друг, вы можете предоставить видео, nagual (ok), 00:13 , 02-Май-13, (164) –1 Видео вот специально ради тебя писать не буду, но вывод с консоли покажу SSD ст, AlexAT (ok), 09:32 , 02-Май-13, (166) +1 А помните рекомендацию оставлять 5-10 дискового пространства SSD неразмеченным , nagual (ok), 22:48 , 30-Апр-13, (161) –1 Естественно не зря В случае ФС без поддержки TRIM это делать просто необходимо , AlexAT (ok), 09:46 , 02-Май-13, (168) +1 AFAIK TRIM - медленная операция, так что не всё так радужно , edo (ok), 19:56 , 13-Июн-13, (173) Ее надо грамотно использовать просто А если ее не использовать - то ее медленн, AlexAT (ok), 20:11 , 13-Июн-13, (174) Ах, вот оно что А я-то думал, почему это поддержку TRIM со стороны файловых сис, iZEN (ok), 23:03 , 13-Июн-13, (175) Ты просто не понимаешь, как работает флеш с левелером Даже при том, что тебе уж, AlexAT (ok), 07:14 , 14-Июн-13, (176) sysctl -a 124 grep -i trimvfs zfs vdev trim_on_init 1vfs zfs vdev trim_max_, Аноним (-), 18:11 , 28-Апр-13, (80) Прошу прощения - почему не поддерживала до недавнего времени Совсем забыл, что , AlexAT (ok), 18:48 , 28-Апр-13, (82) +2 проблемы с GEOM, Аноним (-), 18:50 , 28-Апр-13, (83) И где тогда оно оружие будущего , если оно только-только научилось поддерживать, AlexAT (ok), 18:52 , 28-Апр-13, (84) Ну там не все так просто и логи нужно хранить на отдельном девайсе,Котлеты отдел, Аноним (-), 18:55 , 28-Апр-13, (85) Не золотая пуля, но, под нагрузкой не прогибаеться так сильно, Аноним (-), 18:57 , 28-Апр-13, (86) Разве кто-то кроме тебя говорил об отношении ZFS к устройствам на flash Сказано, Аноним (-), 20:23 , 28-Апр-13, (88) К моменту, когда это придумают, ZFS будет уже окаменевшим ГМ , AlexAT (ok), 22:37 , 28-Апр-13, (89) +1 Судя по всем линуксовским файловым системам она не умретДа и управление ZFS куда, Аноним (-), 22:41 , 28-Апр-13, (90) Точнее - не успеет даже ожить Юзкейсов слишком мало , AlexAT (ok), 22:44 , 28-Апр-13, (91) +1 В любом случае, она переживет поколение пепси, ярким представителем которого ты , Аноним (-), 07:08 , 29-Апр-13, (92) +1 точнее, клинского , Аноним (-), 07:10 , 29-Апр-13, (93) –1 Ути-пути Во-первых, телепатия не прокачана, двойка Во-вторых, FAT уже пережила, AlexAT (ok), 07:33 , 29-Апр-13, (94) ну и где твоя супер пупер линуксовая фс которая рвет ZFS в клочья Я как раз ищу, deadless (ok), 14:43 , 29-Апр-13, (100) –1 снапшоты ради снапшотов , 666некто (?), 17:39 , 29-Апр-13, (102) +1 ради быстрых бэкапов , linux must _RIP_ (?), 19:38 , 29-Апр-13, (110) –2 И чем снапшот конкретно убыстряет бэкап Для рядового бэкапа вполне достаточно с, AlexAT (ok), 20:10 , 29-Апр-13, (118) –1 Сразу видно кто не пробовал их делать на больших винтах , nagual (ok), 22:52 , 29-Апр-13, (124) Для больших винтов точнее - объемов данных выше 5-10 Тб есть несколько иные , AlexAT (ok), 07:16 , 30-Апр-13, (132) +1 Ага 8212 инкрементное бэкапирование А что это такое Что нам даст лог операци, iZEN (ok), 17:26 , 30-Апр-13, (150) –1 Заколебешься инкременты сверять А если изменяющийся файл в пару терабайт объёмо, AlexAT (ok), 18:39 , 30-Апр-13, (157) +1 Напомните как там в linux с поддержкой ntfs Писать можно или только читать , nagual (ok), 03:22 , 07-Май-13, (171) –1 Можно и читать и писать Модуль ntfs-3g , AlexAT (ok), 07:39 , 07-Май-13, (172) lvm snapshot не обеспечивает консистентности содержимого FS так как представляе, linux must _RIP_ (?), 23:01 , 29-Апр-13, (125) Ну, для бэкапа достаточно и одного Тут вопрос - что важнее - снапшоты, или всё-т, AlexAT (ok), 07:23 , 30-Апр-13, (135) +1 Юзкейс Требования высокая производительность при приличном заполнении диска, от, AlexAT (ok), 20:08 , 29-Апр-13, (117) после чего начинаем думать - а почему это для СУБД советуют использовать raw sto, linux must _RIP_ (?), 23:04 , 29-Апр-13, (126) –2 Это разные требования, однако в боевых случаях нужно как то, как и другое СУБД , AlexAT (ok), 07:19 , 30-Апр-13, (133) Системный кэш нужен только под метаданные ФС, в случае raw storage не нужен и он, Аноним (-), 07:39 , 30-Апр-13, (137) –1 Именно И тем более ей не уперся гвоздями прибитый сбоку ZFS ARC Который хочет , AlexAT (ok), 08:13 , 30-Апр-13, (141) +1 Слушай, ну не трындите уже, о том чего вы не знаете, а Не отключается Вафелы, Аноним (-), 16:21 , 30-Апр-13, (146) –1 И где там отключение zfs_arc_max 0 работать будет , AlexAT (ok), 18:08 , 30-Апр-13, (153) +1 да тут бы у Иксперта сначала кнопку для включения мозгов найти 8230 , arisu (ok), 18:34 , 30-Апр-13, (155) +1 Пока не закончиться оперативка , Аноним (-), 19:06 , 30-Апр-13, (158) zfs create tank mysqlzfs set atime off tank mysqlzfs set mountpoint var db mysq, Аноним (-), 01:18 , 30-Апр-13, (129) От гиперфрагментации ибо CoW это не избавит , AlexAT (ok), 07:21 , 30-Апр-13, (134) Так мы таке почитали вики что такое CoW Ну и как вам CoW TRIM Расскажите, ин, Аноним (-), 07:49 , 30-Апр-13, (140) –1 Почитали Ну идите еще почитайте Особенно по логике работы флеша , AlexAT (ok), 08:15 , 30-Апр-13, (143) +1 в zfs нету CoW, Аноним (-), 16:49 , 30-Апр-13, (147) –1 в raidz есть, Аноним (-), 17:24 , 30-Апр-13, (149) it s epic, bro, AlexAT (ok), 18:09 , 30-Апр-13, (154) +1 Нагромождение требований к дизайну ФС плюс дикий микс разных к этому дизайну плю, Аноним (-), 07:47 , 30-Апр-13, (139) –3 Так юзкейс для своего варианта уже приведёшь, или пустопорожнее , AlexAT (ok), 08:14 , 30-Апр-13, (142) вот как ограниченность файловых систем в линуксах не дает даже возможности предс, deadless (ok), 00:27 , 02-Май-13, (165) –3 Слив засчитан Пока, господа, для ваших академических поделок не будет _широкого, AlexAT (ok), 09:33 , 02-Май-13, (167) +1 http joyent com blog why-smartos-kvm-dtrace-zones-and-more, Аноним (-), 12:32 , 02-Май-13, (169) –1 Адовый гибрид Illumos QEMU KVM тонны маркетингового булшита Спасибо, изба, AlexAT (ok), 20:03 , 03-Май-13, (170) 1,3,13,18,35

Сообщения

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

	2. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–2 +/–
	Сообщение от z (??), 26-Апр-13, 23:39
	>Ещё одна серьёзная проблема связана с непредсказуемостью переполнения Btrfs-раздела и связанным с исчерпанием свободного места замедлением работы. Превед от Шишкина =)
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Аноним (-), 27-Апр-13, 00:00
	> Превед от Шишкина =) А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина?
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+3 +/–
	Сообщение от Аноним (-), 27-Апр-13, 00:27
	Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас в очках на аэроплане").
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (-), 27-Апр-13, 01:53
	> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума > не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас > в очках на аэроплане"). Скорее, хватает ума понять, что метаданные - неотъемлемая часть ФС, и требовать 100% использования места под данные бессмысленно.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от Deffic (?), 27-Апр-13, 03:56
	> Нет, разумеется. Потому что у эксплуатационщиков в отличие от теоретиков хватает ума > не заниматься извращениями типа "том на 600Мб, забитый мелкими файлами" ("фантомас > в очках на аэроплане"). "том на 600Мб" -- 10 лет нвзад "забитый мелкими файлами" -- Maildirs
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	23. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от angra (ok), 27-Апр-13, 10:43
	Во-первых, не 10, а 15. Во-вторых, с учетом скорости развития IT это звучит примерно как жалоба на то, что современный пулемет за минуту тратит патронов больше чем, чем полтора века назад батальон с винтовками за неделю.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (-), 28-Апр-13, 12:48
	Что характерно, общая сложность задач возросла может быть в разы, но не на порядки же.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Аноним (-), 27-Апр-13, 01:54
	> А что, разве хоть одна из выявленных проблем совпадает с критикой Шишкина? Маловероятно. Одно дело - пригорание седалища у отдельно взятого разработчика, другое дело - опыт практической эксплуатации.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	21. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от z (??), 27-Апр-13, 10:25
	Критика Шишкина, напомню, касалась 'разноса' ФС при определённых условиях, когда из-за непонимания 'практиками' выбранных ими алгоритмов происходила жуткая внутренняя фрагментация метеданных, съедающая ощутимую часть места на диске. И т.к. это дефект на уровне алгоритмов, значит в корне не лечится по определению, только костыли и подпорки. Вообщем, enjoy your practice, dear permanent beta-testers =)
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	24. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от quux (??), 27-Апр-13, 12:16
	Шишкин, перелогиньтесь.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+1 +/–
	Сообщение от Аноним (-), 27-Апр-13, 12:34
	> метеданных, съедающая ощутимую часть места на диске. Любую ФС можно загнать в ситуацию когда ее КПД равен нулю. Создаем до упора файлы нулевого размера - и все, вуаля: на томе 0 байтов данных и весь том забит до отказа метаданными. Катит на совершенно любой ФС. Приветы Шишкину и прочим идеалистам :).
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	33. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+4 +/–
	Сообщение от z (??), 27-Апр-13, 13:50
	>Создаем до упора файлы нулевого размера >Приветы Шишкину и прочим идеалистам Приятно видеть человека, который пытается думать, даже несмотря на то, что у него это довольно плохо получается Ещё раз повторюсь: речь не о том, что метаданные занимают какое-то место, т.к. предложенным выше способом можно 'повалить' любую ФС Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных узлов и само дерево соотв. аномально растёт. Т.е. место тратится не непосредственно полезными (мета)данными - место просто уходит В НИКУДА. Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым monkey-тестерам =)
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok), 27-Апр-13, 15:51
	> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда > балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных > узлов и само дерево соотв. аномально растёт. Т.е. место тратится не > непосредственно полезными (мета)данными - место просто уходит В НИКУДА. А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? > Превед двоченикам, прогуливавшим фундаментальные алгоритмы и структуры данных, ну и оболваненым > monkey-тестерам =) Ну, автор поста, похоже, не прогуливал? И сейчас даст всем прикурить.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+2 +/–
	Сообщение от z (??), 27-Апр-13, 15:54
	>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? https://lkml.org/lkml/2010/6/18/144
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+3 +/–
	Сообщение от z (??), 27-Апр-13, 16:07
	Хорошо сказал, между прочим: >If you decide to base your file system on some algorithms then please use the original ones from proper academic papers. DO NOT modify the algorithms in solitude: this is very fragile thing! All such modifications must be reviewed by specialists in the theory of algorithms. Such review can be done in various scientific magazines of proper level. Перевожу на русский: если вы решили создать вашу файловую систему на каких-то алгоритмах - тогда пожалуйста используйте оригинальные из соотв. научных работ. НЕ МОДИФИЦИРУЙТЕ алгоритмы самостоятельно: это очень хрупкая вещь! Все подобные модификации должны быть рассмотрены специалистами в теории алгоритмов. Подобные обзоры могут быть (уже) сделаны в различных научных журналах соотв. уровня Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное - не пытайся что-либо в этом менять, чтобы не было фейлов уровня дебиановского openssl
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok), 27-Апр-13, 17:35
	> Перевожу на понятный для школьников русский: не понимаешь, как работает что-то сложное > - не пытайся что-либо в этом менять, чтобы не было фейлов > уровня дебиановского openssl Там другое, авто-проверки ругнулись на непонятные им данные, инициализцию и екнули. Таки да, не двоечник и сам должен понять суть :) Вопрос-то теперь академический.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	+/–
	Сообщение от Bx (ok), 27-Апр-13, 16:49
	>>А подробности можно услышать? Где именно вырождается, как это влияет на размер дерева(в коэффициентах, абсолютных значениях или попугаях, плиз), при каких именно условиях. Воспроизводимость, шаблон? > https://lkml.org/lkml/2010/6/18/144 Мде, пруф искать лень, что-то там про 640 килобайт тоже было, не 3 года, конечно, но... :) >> # for i in $(seq 1000000); \ >> do dd if=/dev/zero of=/mnt/file_$i bs=2048 count=1; done >> (terminated after getting "No space left on device" reports). >> >> # ls /mnt | wc -l >> 59480 Воспроизвел, правда, 1М на 100К поменял for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; done Filesystem     1K-blocks   Used Available Use% Mounted on /dev/loop1        674816 450664    220064  68% /mnt/0 System: total=4.00MB, used=8.00KB Data+Metadata: total=655.00MB, used=440.09MB 691011584 Apr 27 16:33 btrfs.img Сорри, забыл ls /mnt/0/ | wc -l 100003
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	43. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от nagual (ok), 27-Апр-13, 17:36
	>[оверквотинг удален] >>> 59480 > Воспроизвел, правда, 1М на 100К поменял > for i in $(seq 100000); do dd if=/dev/zero of=/mnt/0/file_$i bs=2048 count=1; done > Filesystem     1K-blocks   Used Available Use% Mounted > on > /dev/loop1        674816 450664   >  220064  68% /mnt/0 > System: total=4.00MB, used=8.00KB > Data+Metadata: total=655.00MB, used=440.09MB > 691011584 Apr 27 16:33 btrfs.img И что не нравится ? Трата места на метаданные ? Повторите этот же тест с разделом в 100 раз больше и сравните результаты.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Bx (ok), 27-Апр-13, 17:46
	> И что не нравится ? Трата места на метаданные ? Повторите этот > же тест с разделом в 100 раз больше и сравните результаты. Я, как-бы, защитник btrfs :) Потрудитесь почитать линк, на который я отвечал.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."	–1 +/–
	Сообщение от Аноним (-), 27-Апр-13, 18:21
	> Речь о том, что при определённых условиях B-Tree в BTRFS _вырождается_, когда > балансировка уходит не в ту сторону, т.е. появляется множество неоптимально заполненных > узлов и само дерево соотв. аномально растёт. И чем это так уж отличается от иных вырожденных случаев, типа забития тома нулевыми файлами? Где оценки масштаба эффекта в реальных применениях? Том на 600 метров забитый мелочью - откровенная синтетика. Я даже предложил доразвитие идеи до логичного финала :)
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	48. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от arisu (ok), 27-Апр-13, 18:36
	в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда что попало разных размеров. этого с b-tree делать *нельзя*. от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл использования сей няшной структуры. и если бы это было единственное, что они решили «улучшить»… на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Хостинг-оператор Anchor протестировал Btrfs на..."	–2 +/–
	Сообщение от Аноним (-), 27-Апр-13, 22:24
	> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать. А что тут такого нехорошего?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Хостинг-оператор Anchor протестировал Btrfs на..."	+3 +/–
	Сообщение от arisu (ok), 27-Апр-13, 23:44
	>> на вскидку — использование crc как хэш-функции: это тоже очень круто. настолько круто, что просто обнять и плакать. > А что тут такого нехорошего? просто никогда не пиши реализацию хэш-таблиц, хорошо? воспользуйся готовой из стандартной библиотеки какого-нибудь языка: с вероятностью, близкой к 100%, она будет лучше того, что ты напишешь. потому что пользоваться гуглем — судя по этому вопросу — ты не способен.
	Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	66. "Хостинг-оператор Anchor протестировал Btrfs на..."	+/–
	Сообщение от arisu (ok), 28-Апр-13, 00:59
	больше заискивающих смайликов, больше.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Хостинг-оператор Anchor протестировал Btrfs на..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 29-Апр-13, 18:01
	> больше заискивающих смайликов, больше. Сдаётся мне, это опять демагог debugger.  Порешил.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	68. "Хостинг-оператор Anchor протестировал Btrfs на..."	–1 +/–
	Сообщение от Аноним (-), 28-Апр-13, 01:36
	> в дискуссии, вообще-то, ссылку приводили. отличается это тем, что авторы btrfs при > помощи кувалды и некоей матери напрочь поломали b-tree, начав пихать туда > что попало разных размеров. этого с b-tree делать *нельзя*. Если уж на то пошло, у очень многих алгоритмов применяемых нынче в софте "средний" случай и "наихучший" очень сильно варьируются. Можно вспомнить например волну атак на хэш таблицы где подбором данных можно выпасть далеко за пределы O(1) который они обеспечивают "в среднем" :). > от слова «вообще». b-tree от этого деградирует с дурной скоростью, напрочь убивая смысл > использования сей няшной структуры. Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки. > и если бы это было единственное, что они решили «улучшить»… на вскидку > — использование crc как хэш-функции: это тоже очень круто. настолько круто, > что просто обнять и плакать. Да вообще-то это обычная практика. А то что особо хитрый хакер может специальным образом файлы создавать - так я тебе твой же пример с хакером и солонками в столовой и приведу, хренли ты хотел? Прикольно же долбануть Кэпа его собственным вооружением в качестве легкого сарказма :)
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	107. "Хостинг-оператор Anchor протестировал Btrfs на..."	–1 +/–
	Сообщение от linux must _RIP_ (?), 29-Апр-13, 19:29
	> Ну и где анализ типового поведения их модифицированных деревьев? Шишкин лицо предвзятое и юзкейс выдернул крайне синтетический для показательной порки. В новостях пробегало - достаточно создать всего 64 файла что бы убить  btrfs.. вот так..
	Ответить | Правка | Наверх | Cообщить модератору

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

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