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

Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..., opennews (??), 19-Сен-12, (0) [смотреть все] Как оно на практике , Kroz (??), 13:02 , 19-Сен-12, (1) // Юзаю несколько месяцев на сервере который хранит бекапы бекапы бекапов фс все , redixin (ok), 14:00 , 19-Сен-12, (6) Больше года - на томе, лежащем на zfs, подключенном по iSCSI к Windows 2003 крут, iCat (ok), 15:08 , 19-Сен-12, (13) +4 // Круто А как такое делается , Хрен с горы (?), 15:15 , 19-Сен-12, (16) // Точно также как тут http help ubuntu ru wiki samba_shadow_copyтолько снапшоты, Elhana (ok), 15:34 , 19-Сен-12, (23) +1 Спасибо , Хрен с горы (?), 15:36 , 19-Сен-12, (25) кстати, оно не тормозит raidz из двух дисков , redixin (ok), 17:53 , 19-Сен-12, (46) // тормозит - понятие относительное С теми базами, которые лежат на iSCSI работа, iCat (ok), 01:48 , 20-Сен-12, (59) ну ещё бы Dпусть только попробуют , ананим (?), 13:55 , 20-Сен-12, (79) +1 У меня с ними хорошие взаимоотношения , iCat (ok), 14:56 , 22-Сен-12, (133) Достаточно стабильно для меня, чтобы не бояться держать на нём домашнюю директор, Andrew Kolchoogin (?), 10:51 , 20-Сен-12, (69) // С ноутами засада Если стукнуть диск заклинит и тогда и ZFS не поможет а если по, nagual (ok), 11:14 , 20-Сен-12, (72) +1 // Если именно _заклинит_ -- то есть, из-за гироскопического эффекта искривится ось, Andrew Kolchoogin (?), 12:50 , 20-Сен-12, (73) Аргон то нафига Хитачики вон еще только собираются делать диски с гелием А в с, Аноним (-), 02:51 , 21-Сен-12, (101) Сразу видно месье не в теме Прецендентов пока небыло , nagual (ok), 08:04 , 21-Сен-12, (112) –1 Мсье как раз мониторит состояние отрасли А как же тогда конторы по дата рекавери, Аноним (-), 12:30 , 23-Сен-12, (178) Месье мэнаджэр - Почуствуйте разницу между предлагают и достать Хотябы , nagual (ok), 17:08 , 23-Сен-12, (197) –1 Нет Мсье просто интересуется подобными вопросами Простите, с HDD в сложных случ, Аноним (-), 20:22 , 23-Сен-12, (224) Вы так говорите, как будто постоянно в 3 операционки винты перетыкаете , Клыкастый2 (?), 16:36 , 21-Сен-12, (126) Впрочем, на практике для больших оно тоже лучше, чем BtrFS Oracle, к сожалению, Andrew Kolchoogin (?), 11:09 , 20-Сен-12, (71) // однобокое суждение 1 вначале люстру санки насильно прогнули под zfs и не додела, ананим (?), 13:39 , 20-Сен-12, (75) // зыжА вообще прикольный пассаж Dсводится к такому в топ500 есть люстра, поэтом, ананим (?), 13:54 , 20-Сен-12, (78) +1 А как вы собираетесь сравнивать качество программного обеспечения, если не по ме, Andrew Kolchoogin (?), 15:58 , 20-Сен-12, (83) а я и сравниваю на своём ноуте Dа в топ500 их сравнение пока не предвидится, ананим (?), 16:02 , 20-Сен-12, (84) Ага Люстровы, Andrew Kolchoogin (?), 01:16 , 21-Сен-12, (95) Ага Люстровый кластер на виртуалках развёрнут, да Ну, админы localhost а -- бол, Andrew Kolchoogin (?), 01:19 , 21-Сен-12, (96) Не, млин, зетэфесный ЗыжБЕЗУСЛОВНО Как только вы докажите свою квалификацию По, ананим (?), 01:43 , 21-Сен-12, (98) А это у всех солярщиков и маркетоидов так Зато наш маркетолог не умеет чинить S, Аноним (-), 03:13 , 21-Сен-12, (102) gt оверквотинг удален Месье тонко манипулирует понятиями, сначала говорит про , nagual (ok), 08:06 , 21-Сен-12, (113) –1 Не понятно в каком месте манипуляция Обычный капитанинг Если вы припретесь в д, Аноним (-), 12:35 , 23-Сен-12, (180) Не не доделали , а не успели доделать до поглощения Ораклом Там -- это где , Andrew Kolchoogin (?), 15:52 , 20-Сен-12, (82) gt оверквотинг удален Кстати ОРАкля zfs v30 v31 под свободной лицензией не пус, nagual (ok), 16:06 , 20-Сен-12, (85) btrfs очень сильно развивается число коммитов и участников увеличилось если не, ананим (?), 16:18 , 20-Сен-12, (87) Ну так бсдшные оналитеги не пописаны на рассылки и список коммитов не смотрят З, Аноним (-), 12:36 , 23-Сен-12, (182) А чего там смотреть Всё и так ясно 8212 Btrfs не сертифицирована для продакш, iZEN (ok), 12:49 , 23-Сен-12, (187) –1 Бсда вообще никак не сертифицирована для оракла Ни с ZFS, ни без Так что причи, Аноним (-), 20:25 , 23-Сен-12, (227) Причина понтов с Btrfs тоже непонятна Ну объявили её якобы готовой к продакшену, iZEN (ok), 20:34 , 23-Сен-12, (235) Не надо поддержки RAID-5 на уровне ФС Только не это А в ZFS его не напишут нико, AlexAT (ok), 20:38 , 23-Сен-12, (239) Почему Что плохого в RAID-5 на уровне ФС Я вроде как опроверг твоё мнение на сч, iZEN (ok), 20:59 , 23-Сен-12, (247) Это читом с закешированным файлом Нет уж, давай либо на холодное кеширование, л, AlexAT (ok), 22:55 , 23-Сен-12, (265) Скажите а Reiser4 это продолжение развития reiserfs http habrahabr ru post 10, nagual (ok), 21:06 , 02-Окт-12, (513) Скорее тотальный rewrite по мотивам Да и фиг с ним - это совсем сырая ФС для , Аноним (-), 15:42 , 06-Окт-12, (532) Поддержку с ней объявили 2 конторы, ну и не более того На свой страх и риск, в , Аноним (-), 20:38 , 24-Сен-12, (327) У соседа корова сдохла, совсем чужой человек, мелочь, а как приятно - Неу, nagual (ok), 20:49 , 24-Сен-12, (328) Это вы о себе Потому что наперли на факт что ФС официально не поддерживается, а, Аноним (-), 18:58 , 25-Сен-12, (388) Отстали вы от жизни однако со своими тестами криокамеры http www opennet ru op, nagual (ok), 20:53 , 24-Сен-12, (329) Я что-то не понял - в чем проблема Оракл как раз одна из этих контор Они сами , Аноним (-), 19:01 , 25-Сен-12, (389) TRIM собираются спереть из ZFSoL, ибо припёрло Интересно, как обойдут GPL , AlexAT (ok), 20:55 , 24-Сен-12, (331) Никак 8212 все изменения под CDDL, чего требует оригинальная лицензия ZFS До, iZEN (ok), 21:47 , 24-Сен-12, (336) Интересно если все изменения в ZFS могут быть только под CDDL то каким местом zf, nagual (ok), 20:24 , 25-Сен-12, (396) CDDL - это пермиссив для юзеров У компании-автора, априори, неограниченная ли, AlexAT (ok), 22:16 , 25-Сен-12, (400) Неужели маркетинговый буллшит прокатывать перестал Какая досада Зато мы скоро , Аноним (-), 19:03 , 25-Сен-12, (390) TRIM практически увеличит скорость записи на флэш Зачем отказываться от такой ф, iZEN (ok), 19:06 , 25-Сен-12, (391) Ну, что я говорил Приятно чувствовать себя провидцем , Аноним (-), 19:20 , 30-Сен-12, (445) ZFSLoL fixed, Аноним (-), 15:16 , 01-Окт-12, (465) могу ещё раз повторить, если вы не поняли - есть мнение, что таки доделали но ре, ананим (?), 16:11 , 20-Сен-12, (86) Слуште, я спрашивал у ZFS ников уже после поглощения Sun а Oracle ом на последни, Andrew Kolchoogin (?), 01:14 , 21-Сен-12, (94) а я пробовал и участвовал , ананим (?), 01:50 , 21-Сен-12, (99) +1 ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не сн, nagual (ok), 14:09 , 19-Сен-12, (8) –3 // действительно, откуда у оракл деньги, Одмин (?), 15:01 , 19-Сен-12, (11) +10 Вот только btrfs в ядре, так что user base у него будет всяко много больше , Crazy Alex (ok), 15:03 , 19-Сен-12, (12) // Начиная с zfs-linux 0 0 6-rc10 модуль для ядра ставится при помощи dkms одной ко, Vadim (??), 15:33 , 19-Сен-12, (22) –1 // Полная фигня, по сравнению с btrfs, которая идет из коробки На нее даже систему, Аноним (-), 15:56 , 19-Сен-12, (27) –1 На zfs тоже можно систему ставить А btrfs у меня пол года назад падала с грохото, Elhana (ok), 16:55 , 19-Сен-12, (33) –1 Вот так прям взять и выбрать в инсталляторе Сказано же допилят лет через пять , Аноним (-), 17:15 , 19-Сен-12, (37) +2 Оракель и суся ее недавно в продакшновые ынтырпрайзные дистры засунули и объявил, Аноним (-), 03:15 , 21-Сен-12, (103) Там был один баг не закрытый всего и связанный с большой нагрузкой , nagual (ok), 08:07 , 21-Сен-12, (114) –1 Опять этот Ыксперт и его сферические кони в вакууме , Аноним (-), 12:40 , 23-Сен-12, (183) Не допилили - хотят выбросить https www opennet ru opennews art shtml num 469, iZEN (ok), 20:02 , 03-Авг-17, (535) можно но сложно и сконвертировать имеющийся ext2 3 4 нельзя, как в бтрфс не вер, ананим (?), 21:12 , 19-Сен-12, (56) Можно но ненужно - потому как без гига оперы под кеш оно так же прекрасно, nagual (ok), 18:00 , 19-Сен-12, (50) –2 Вот только у ZFS кеш плюсом к системному, а BTRFS нормально юзает системный ке, AlexAT (ok), 10:36 , 20-Сен-12, (68) Эксперименты показывают отсутствие разницы - ох уж этот маркетинг , nagual (ok), 11:08 , 20-Сен-12, (70) –1 Эксперименты где На локалхосте , AlexAT (ok), 13:02 , 20-Сен-12, (74) Я думаю что он вообще не экспериментировал Иначе он бы не втирал булшит про 1-2, Аноним (-), 12:41 , 23-Сен-12, (184) Сразу видно кто пробовал а кто книжки пишет - , nagual (ok), 17:15 , 23-Сен-12, (199) –1 Я то btrfs гоняю на регулярной основе Просто потому что он мне нужен и я заинте, Аноним (-), 20:27 , 23-Сен-12, (228) один раз вы уже вбрасывали эту дезу - http www opennet ru openforum vsluhforum, ананим (?), 13:47 , 20-Сен-12, (76) У правильных экспериментаторов бульдозер проигрывает core i5 хотя в некоторы, nagual (ok), 14:04 , 20-Сен-12, (80) –2 понятно вопросов больше не имею , ананим (?), 14:32 , 20-Сен-12, (81) +1 Чьи Ваши Опишите методику Не ваши Дайте ссылку И вообще, что значит гораздо, Andrew Kolchoogin (?), 01:31 , 21-Сен-12, (97) –1 методику Dизвольте - есть у меня вайфай-роутер, нетгир wndr3700 а тут вдруг я , ананим (?), 01:56 , 21-Сен-12, (100) Я по приколу запускал на железке с 64Мб рам на все про все Без свопа Даже дово, Аноним (-), 21:22 , 02-Окт-12, (514) Лучше, ибо экстентные аллокаторы - не такие слоупоки как блочные Плюс дефрагер , Аноним (-), 03:20 , 21-Сен-12, (104) И ничего, что этот модуль тоже собирать надо , BratSinot (?), 19:00 , 19-Сен-12, (54) ничего поддержка бтр из коробки уже почти во всех ядрах современных дистров и,, ананим (?), 21:14 , 19-Сен-12, (57) Самому его надо собирать только если вы гентушник В бинарных дистрах он как пра, Аноним (-), 03:21 , 21-Сен-12, (105) Это если исходник есть в репозиториях И где оно будет В дебиане и редхете - , Crazy Alex (ok), 18:36 , 19-Сен-12, (53) ну, с бтр можно начать играться и уже на готовой системе - сконвертнул из ext4 и, ананим (?), 21:16 , 19-Сен-12, (58) Кстати да, гибкость BTRFS в плане размещения данных и метаданных - доставляет Д, Аноним (-), 03:22 , 21-Сен-12, (106) Ага, два раза Особенно оракл, который создал btrfs с учетом ошибок, сделанных , Аноним (-), 15:14 , 19-Сен-12, (15) +2 // Неделю назад в рассылке zfs-discuss как раз была ссылка на позицию Oracle по пор, Vadim (??), 15:30 , 19-Сен-12, (20) Но коник не взлетел и не взлетит потому как рядом рухнул купленный коник MyS, nagual (ok), 17:54 , 19-Сен-12, (47) –1 // Да, комбикорма приготовили из полуразложившегося трупа ZFS , filosofem (ok), 19:06 , 19-Сен-12, (55) О, пипец доморощенные аналитики А чуваки из майнлайн ядра пилят его толпой и не, Аноним (-), 10:10 , 20-Сен-12, (62) То-то все хостинги по сей день юзают оный А если оракл будет слишком выпендрива, Аноним (-), 10:12 , 20-Сен-12, (63) Месье застрял в криокамере Безусловно ОРАкля не сломает мускуль за один день , nagual (ok), 10:29 , 20-Сен-12, (66) –1 C чего бы Мы наоборот вернулись с MariaDB на MySQL, потому, что в 5 5 много вку, AlexAT (ok), 10:35 , 20-Сен-12, (67) Наврядли Ну не конкурент мускуль их базе, просто потому что мускуль - просто го, Аноним (-), 04:19 , 21-Сен-12, (107) Вот кластер рампочты на мускуле если верить слонику а мог бы быть на оракле И, nagual (ok), 08:12 , 21-Сен-12, (115) Прогулочную яхту арендовать несколько дешевле чем круизный лайнер, знаете ли По, Аноним (-), 12:29 , 21-Сен-12, (120) Х се 1к серверов в кластере что то с круизным лайнером не то если 1к яхт , nagual (ok), 12:35 , 21-Сен-12, (123) 1К яхт обойдутся дешевле чем 1К круизных лайнеров Тем более Переделывать чтоб, Аноним (-), 12:46 , 23-Сен-12, (185) Много раз читаю про кластер рампочты и не понимаю, кто этот кластер нагружает В, анон (?), 12:52 , 23-Сен-12, (188) Btrfs в конфигурации для Oracle DB не поддерживается официально , iZEN (ok), 11:22 , 23-Сен-12, (161) –1 А bsd и тем более ZFS на оной и тем более с оракловой базой - вообще никак не п, Аноним (-), 12:46 , 23-Сен-12, (186) Так свободные системы для свободных людей, разве нет Какая же в Linux свобода, , iZEN (ok), 12:53 , 23-Сен-12, (189) Так я и не утверждал что мне нравится проприерасия от оракла и что я горю желани, Аноним (-), 20:31 , 23-Сен-12, (232) А бтр пилят разработчики майнлайнового ядра Не знаю считается ли это за финанси, Аноним (-), 10:00 , 20-Сен-12, (61) // Еще одна FS в коллекцию недофс линукса Скорее все чего касаются менеджеры и в, nagual (ok), 10:23 , 20-Сен-12, (64) –3   // Ну да, и только вы на белом коне Сферическом В вакууме А ничего что у всяких , Аноним (-), 05:59 , 21-Сен-12, (108)   Судя по этом бреду месье не часто инсталит ОС Вай вай да месье маркетолог , nagual (ok), 08:16 , 21-Сен-12, (116) –1   Иногда - инсталлит Но не слишком часто, ибо не является эникейщиком протирающим, Аноним (-), 12:17 , 21-Сен-12, (119)   Какой то месье не замечательный ни не замечет что лушим друзьям оракла п, nagual (ok), 12:30 , 21-Сен-12, (121)   У оракла есть друзья А я то думал что при капитализме человек человеку - волк и, Аноним (-), 12:55 , 21-Сен-12, (124)   Что то не везет вам в думании Неужели после всего вышенаписанного для месье , nagual (ok), 13:12 , 21-Сен-12, (125)   Да ладно вам, нормально вполне Кстати понимание работы этой механики еще не озн, Аноним (-), 07:06 , 22-Сен-12, (129)   Нет никакой необходимости записывать свои открытия в форуме Мы тут много обсужда, nagual (ok), 10:12 , 22-Сен-12, (131)   Бугыг Только хотел этому кексу написать а ты текущую из всех щелей лису на что, AlexAT (ok), 09:47 , 23-Сен-12, (142)   Ну я не виноват что вы не знаете элементарных вещей, приходится разъяснять и в р, Аноним (-), 17:58 , 23-Сен-12, (200)   И не делайте, тем более половина неверная Наверно поиск по Crtl F по маске sy, nagual (ok), 18:28 , 23-Сен-12, (202)   Не так уж плохо по сравнению с вашими сообщениями У вас КПД намного хуже, увы Н, Аноним (-), 21:01 , 23-Сен-12, (248)   Тест от 27 июня 2012 года For the 8GB IOzone write test, ZFS on the OCZ Solid 2, iZEN (ok), 22:04 , 23-Сен-12, (261)   На Threaded I O Write Test, особенно на HDD, ZFS можно сравнивать только с BTRFS, AlexAT (ok), 23:21 , 23-Сен-12, (272)   а про то что их в этих тестах на механике совершенно дико порвал btrfs - такт, Аноним (-), 19:25 , 30-Сен-12, (446)   Ох уж эти провалы в памяти С такими провалами в памяти да забесплатно Я бы , nagual (ok), 22:47 , 23-Сен-12, (263)   Так продолжите мыслю в нормальном виде Ну и замечательно, мне же меньше геморро, Аноним (-), 21:17 , 24-Сен-12, (332)   Ссылка на статью с описанием уже постилась Судя по всему получается плохо nag, nagual (ok), 22:15 , 24-Сен-12, (338)   root storage dd if data Anime Viewed Macross Frontier TV1 Coalgirls _M, AlexAT (ok), 22:35 , 24-Сен-12, (340)   Во первых диск ссд а не хдд, во вторых кеширование, в третих интересна только за, nagual (ok), 23:39 , 24-Сен-12, (345)   Seagate 7200 11, RAID 5Дык, она выше есть , AlexAT (ok), 23:51 , 24-Сен-12, (354)   3 диска в массиве Параллельно с этого же массива выполняются 7 виртуальных маши, AlexAT (ok), 23:55 , 24-Сен-12, (357)   Да нет там кеширования - Это виртуалка - Диск 30 гиг Файло за 1 раз зап, nagual (ok), 00:20 , 25-Сен-12, (362)   Вызывает небольшую погрешность измерений при записи, но не более того - не пр, AlexAT (ok), 07:34 , 25-Сен-12, (369)   Модератор опенета вполне может написать статью на тему Cклонномть к паталогичес, nagual (ok), 08:42 , 25-Сен-12, (375)   Один конкретный читатель оказался настолько туп, что увидев строчку с тестом кеш, AlexAT (ok), 09:17 , 25-Сен-12, (378) +1   И что Ну выпускаются они Массово Стало быть с ними надлежит нормально работат, Аноним (-), 19:28 , 30-Сен-12, (447)   Между ext3 и ext4 - огромная пропасть В ext4 запилен экстентный аллокатор , AlexAT (ok), 22:39 , 24-Сен-12, (342)   Скотч проволка клей и спички , nagual (ok), 23:45 , 24-Сен-12, (349) –1   Прямо описание процесса разработки UFS Надо же, к антикварному драндулету прикл, Аноним (-), 15:21 , 01-Окт-12, (466)   Хоть слезы девственницы, если оно работает и делает это быстро и хорошо , Аноним (-), 21:26 , 02-Окт-12, (515)   ZFSv29 8212 RAID-Z mirror hybrid allocatorЭто то, о чём вы думаете , iZEN (ok), 00:36 , 25-Сен-12, (365)   Иногда лучше читать, прежде чем говорить , AlexAT (ok), 08:04 , 25-Сен-12, (373)   Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей, nagual (ok), 08:50 , 25-Сен-12, (377) –2   И я о том же , AlexAT (ok), 09:17 , 25-Сен-12, (379) +1   Чтож вы не предупредили что запилено совсем недавно http forum ubuntu ru inde, nagual (ok), 11:00 , 02-Окт-12, (494)   А между тем, в продакшне ext4 работает, и работает абсолютно стабильно , AlexAT (ok), 12:42 , 02-Окт-12, (497) +1   Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько XFS, Аноним (-), 15:52 , 06-Окт-12, (533)   Кем заявлено ораклом А недавно микрософ заяволо о стабильности вин8 ага Ну п, nagual (ok), 18:06 , 06-Окт-12, (534)   Что - ссылка Если вы не можете кратенько, в двух словах изложить что вы имели в, Аноним (-), 20:02 , 25-Сен-12, (393)   ВЫ главное результаты своих изысканий никому не показывайте - А современные эт, nagual (ok), 20:19 , 25-Сен-12, (395)   Было http www opennet ru openforum vsluhforumID3 86368 html 433 --- dd if , iZEN (ok), 19:13 , 23-Сен-12, (212)   Косяк Надо скорость чтения файла, который клался на том под конец его захламлив, AlexAT (ok), 19:36 , 23-Сен-12, (218)   gt оверквотинг удален А оно изначально было набито без модификации, на новый, iZEN (ok), 20:14 , 23-Сен-12, (223)   Ключевое слово - дозапись А если там еще и удаления были - вот тут уже всё ин, AlexAT (ok), 20:27 , 23-Сен-12, (229)   А мне хватало 8212 видео Full HD 1080p MKV 14GB не тормозит при просмотре и л, iZEN (ok), 20:37 , 23-Сен-12, (238)   Ну я и говорю - 100 1 1 0 На серверы кроме долгосрочек CDN такое ставить жутк, AlexAT (ok), 20:40 , 23-Сен-12, (242)   Сейчас dd if store video Трон 1982 mkv of dev null bs 20M726 1 records , iZEN (ok), 20:42 , 23-Сен-12, (243)   Да-да, скорость хуже чем у самой засраной флешки По-моему, если ты возьмешь файл, Аноним (-), 21:05 , 23-Сен-12, (250)   Уже не различаешь скорость чистой записи в пул Так вот, после кэширования файла, iZEN (ok), 21:47 , 23-Сен-12, (258)   gt оверквотинг удален А сколько было в самом начале до заполнения на 100 , nagual (ok), 21:16 , 23-Сен-12, (252)   gt оверквотинг удален Где На том диске, с которого считывается тестовый файл,, iZEN (ok), 21:50 , 23-Сен-12, (259)   Бугага, лол Не заметил сначала эту фразу ЧИТ ЭПИК ЧИТ Ты показал скорость кэ, AlexAT (ok), 22:53 , 23-Сен-12, (264)   Из кэша памяти на пул записываются данные Что в этом не так , iZEN (ok), 00:01 , 24-Сен-12, (284)   Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд Если все так, дава, Аноним (-), 21:21 , 24-Сен-12, (333)   Давай воспроизведи с помощью dd 1 скорость копирования данных на DVD в районе 2, iZEN (ok), 21:56 , 24-Сен-12, (337)   Спасибо, повеселил dd if data Anime Viewed Macross Frontier TV1 Coalgirls , AlexAT (ok), 22:28 , 24-Сен-12, (339)   gt оверквотинг удален Я считаю, что таким образом ты сравниваешь скорость чтен, iZEN (ok), 00:29 , 25-Сен-12, (363)   gt оверквотинг удален Ох уж эта осень - Даже у thg ru результаты тестирова, nagual (ok), 00:35 , 25-Сен-12, (364)   gt оверквотинг удален Наверно потому, что для модификации полосы набора данных, iZEN (ok), 01:12 , 25-Сен-12, (366)   gt оверквотинг удален Vmware на диск пишет чествно и здравый смысл не обгоняет, nagual (ok), 01:44 , 25-Сен-12, (367)   Минус 165 Мб свободного места и 109 утилизации диска Это такая точность в BSD, AlexAT (ok), 08:03 , 25-Сен-12, (372)   Ух ты, отрицательное свободное место на диске Интересно, это как , Аноним (-), 15:26 , 01-Окт-12, (467)   Это когда на диск в 6гиг под btrfs пишешь 5 2 и вдруг нет не так ВДРУГ место кон, nagual (ok), 00:25 , 02-Окт-12, (478)   Ряд утилит с uint под показатель дискового места будут очень рады такому ответу , AlexAT (ok), 07:32 , 02-Окт-12, (489)   На хабре написали Удачи в вытаскивании , AlexAT (ok), 08:00 , 25-Сен-12, (371)   То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения - надо, AlexAT (ok), 07:59 , 25-Сен-12, (370)   Под freebsd на UFS не воспроизводится Наверно проблема в линуксе , nagual (ok), 08:45 , 25-Сен-12, (376)   У него FreeBSD, детка , AlexAT (ok), 07:33 , 02-Окт-12, (490)   Очень постараться 8212 это иметь дедупликацию ZFS на заполненном пуле Я , iZEN (ok), 12:44 , 25-Сен-12, (381)   gt оверквотинг удален А представьте нам скрипт тестирования в полном виде, не , nagual (ok), 12:54 , 25-Сен-12, (382)   Сейчас всё брошу и буду скрипт писать для вас , iZEN (ok), 13:13 , 25-Сен-12, (383)   Месье учил нас пользоваться гуглем, ну чтож zfs core dump Результатов примерно , nagual (ok), 13:31 , 25-Сен-12, (384)   Ну да У неуловимых Джо кейсов, естественно, близко к 0 - ибо никто не юзает и н, AlexAT (ok), 17:06 , 25-Сен-12, (386) +1   Неандерталец открыл для себя микроволновку , Аноним (-), 19:31 , 30-Сен-12, (448)   26Mb secСтрашно фрагментированный том, видимо , AlexAT (ok), 17:05 , 25-Сен-12, (385) +1   Да нет Просто на нём свободного места около 12 ГБ , iZEN (ok), 18:26 , 25-Сен-12, (387)   Итак давайте обсудим оптимальные для тестов bs и count - , nagual (ok), 19:09 , 25-Сен-12, (392)   Скорость записи не зависит от количества свободного места А вот от его фрагмент, AlexAT (ok), 22:11 , 25-Сен-12, (399)   Да вон тебе перец показал уже скорость в 3Гб сек Тебе мало , Аноним (-), 20:03 , 25-Сен-12, (394)   Наверно потому что в продажу пошли первые SSD диски Это отлично что вы рассказа, nagual (ok), 23:36 , 22-Сен-12, (137)   Снова садись, снова два Без TRIM они не то, что не друзья, а вообще не совмести, AlexAT (ok), 09:55 , 23-Сен-12, (147)   Месье неасилил смысл COW Печально В таком случае поведайте нам что вы пони, nagual (ok), 11:13 , 23-Сен-12, (155)   Бугага TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, ко, AlexAT (ok), 11:23 , 23-Сен-12, (162)   Боюсь это принципиально невозможно потому что ZFS в принципе не сможет адре, nagual (ok), 11:33 , 23-Сен-12, (166)   Перечитай написанное мной еще раз - ты ниасилил , AlexAT (ok), 12:08 , 23-Сен-12, (171) +1   Зачем читать я на память помню - спецально для месье неасилившего мой предыдущ, nagual (ok), 16:56 , 23-Сен-12, (191)   Чукча не читатель Ага, вот только контроллеру SSD совершенно неведомо, что там Z, AlexAT (ok), 18:35 , 23-Сен-12, (203)   Как же туго с логикой Вот если на SSD все блоки уже заняты и идет запись занято, nagual (ok), 20:28 , 23-Сен-12, (230)   В свободный Предвосхищая вопрос на SSD не бывает ситуации все блоки заняты Б, AlexAT (ok), 20:33 , 23-Сен-12, (233)   Как же туго с логикой 2 LOLЕсли ОС может адресовать только видимые ей то как мог, nagual (ok), 22:27 , 23-Сен-12, (262)   Да, LOL Полнейшее, лютое, вопиющее незнание логики работы накопителей на флеше , AlexAT (ok), 23:28 , 23-Сен-12, (273)   Элементарно, Ватсон Левелер их уже заюзал, а стирания еще не произошло - оно фо, AlexAT (ok), 23:36 , 23-Сен-12, (279)   И что device timeout Бред , nagual (ok), 00:00 , 24-Сен-12, (283)   При чем тут device timeout Нет, всего лишь задержка в несколько МС на стирание , AlexAT (ok), 00:07 , 24-Сен-12, (286)   Пипец, хардкорные разработчики бсды должны сгореть со стыдухи за своих коллег , Аноним (-), 21:24 , 24-Сен-12, (334)   Он вообще какой-то деревянный Еще один изен прямо , Аноним (-), 21:05 , 23-Сен-12, (251)   Ой, а что же будет, если размер блока ФС случайно или по незнанию пользователя с, iZEN (ok), 11:45 , 23-Сен-12, (169)   Ничего не будет Флешка как не знала о том, что блок логически высвобожден, так , AlexAT (ok), 12:13 , 23-Сен-12, (173)   Для CoW аппаратный левелинг неактуален 8212 он делается на программном уровне, iZEN (ok), 12:33 , 23-Сен-12, (179) –1   Ага, щаззз Ну то-есть оно бы может и размазывало записи, не будь там контроллер, Аноним (-), 18:45 , 23-Сен-12, (208)   Абсолютно согласен Чем меньше пространства у левелера под маневры, и чем чаще п, AlexAT (ok), 18:50 , 23-Сен-12, (209)   Я не понимаю почему они в такое не въезжают Тупые какие-то - не могут массивы б, Аноним (-), 21:32 , 24-Сен-12, (335)   Откуда ты знаешь Без TRIM контроллер не запускает механизм очистки, а значит не, iZEN (ok), 20:05 , 23-Сен-12, (222)   О боже В этом и проблема Очистка блока по меркам CPU шины - операция длиною в , AlexAT (ok), 20:24 , 23-Сен-12, (225)   Два чая этому гражданину Ну это же изен Я думаю что даташиты на микросхемы ф, Аноним (-), 06:39 , 24-Сен-12, (300)   Интересовался устройством FTL flash translation layer и наблюдал как это вообщ, Аноним (-), 06:15 , 24-Сен-12, (297) +1   О, хоть кто-то Я в свое время реверсил FTL TFS на Samsung ах X100 X600 E700, AlexAT (ok), 07:35 , 24-Сен-12, (309)   Вот для этого существует дедуплекация Если там будет контроллер SF2 там все , nagual (ok), 11:28 , 24-Сен-12, (316)   При чем тут дедупликация, вообще А если бы еще и во рту грибы росли , AlexAT (ok), 12:19 , 24-Сен-12, (320)   Месье поял насколько он неправ Ну не расстраивайтесь так из-за ерунды Вот поз, nagual (ok), 12:23 , 24-Сен-12, (321) –1   Пойми - ошибка конкретной фирмвари конкретного контроллера будет исправлена, есл, AlexAT (ok), 12:24 , 24-Сен-12, (322)   Сименсы, сэр Все что на 166-м проце Поскольку сименсу копание в некоторых б, Аноним (-), 22:37 , 24-Сен-12, (341)   Ох как, значит коллеги Почти то же самое Загрузчики только юзали самсунговски, AlexAT (ok), 22:51 , 24-Сен-12, (343)   Получается что так А в этом случае свои были, сделанные на основе изучения сим, Аноним (-), 21:08 , 25-Сен-12, (397)   LAWL 100500, AlexAT (ok), 22:18 , 25-Сен-12, (401)   Ой ЧСВ пробило потолок - , nagual (ok), 23:44 , 24-Сен-12, (348)   Как то раз один дурак ляпнул и теперь все заучили как молитву Это из раздела - п, nagual (ok), 11:09 , 24-Сен-12, (312)   http www datasheetcatalog org datasheet SamsungElectronic mXxqwqy pdfСтраница , AlexAT (ok), 12:17 , 24-Сен-12, (318)   При том даже на английской википедии доступно разжевано каког оно именно так С, Аноним (-), 18:59 , 26-Сен-12, (423)   Этот дурак назывался между прочим даташитами на чипы От производителей чипов , Аноним (-), 23:38 , 24-Сен-12, (344)   Как правило инженеры которые делают и инженеры которые пишут это не одни и те же, nagual (ok), 00:11 , 25-Сен-12, (359)   И только nagual знает всё лучше вендоров Вместе с братьями-акробатами на хабре , AlexAT (ok), 07:32 , 25-Сен-12, (368)   Понимаете, как я написал выше, я когда-то делал специфичный софт и там был специ, Аноним (-), 21:33 , 25-Сен-12, (398)   Месье что то очень часто вспоминает бурную молодость Иногда к месту, иногда нео, nagual (ok), 23:06 , 25-Сен-12, (402)   Думаю что в данном случае мсье припомнил это кстати Устройство флеша в целом ма, Аноним (-), 19:25 , 26-Сен-12, (424)   Ну чтовы - вы просто неправильно поняли написанное - Несмотря на на все намё, nagual (ok), 21:05 , 26-Сен-12, (429)   Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме, AlexAT (ok), 21:46 , 26-Сен-12, (432)   Это вы про тех самых инженеров которые немогут bc и count на пальцах показать , nagual (ok), 23:14 , 26-Сен-12, (433)   bc - это вообще программа-калькулятор такая А вы наверное про bs , Аноним (-), 17:30 , 27-Сен-12, (436)   Наверное дело в том кто объясняет Вот были бы вы супермозгом, типа резерфорда, , Аноним (-), 20:56 , 30-Сен-12, (451)   Учитывая что все последующие инсинуации основаны всего на одном предположении из, nagual (ok), 20:44 , 23-Сен-12, (245)   ДостАверные тесты - это круто, да , Аноним (-), 06:26 , 24-Сен-12, (298)   Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера , nagual (ok), 17:01 , 23-Сен-12, (192) –1   http www anandtech com show 2829 9http www bit-tech net hardware storage 201, AlexAT (ok), 18:41 , 23-Сен-12, (204)   Очень порадовали результаты тестов по первой ссылке одни производители SSD дали, nagual (ok), 20:33 , 23-Сен-12, (234)   Есть Самый достоверный тест - это произведенный собственными руками Поэтому - , AlexAT (ok), 20:36 , 23-Сен-12, (237)   Да любого - как будто, эта логика у всех сильно отличается Детали реализации мо, Аноним (-), 06:29 , 24-Сен-12, (299)   Да не любого http habrahabr ru post 143659 читать до просветвленья - , nagual (ok), 11:10 , 24-Сен-12, (313)   После скриншотика с гламурного макбука блеванул, и читать перестал , AlexAT (ok), 12:18 , 24-Сен-12, (319)   А TRIM то там и нету А в btrfs - опять же, есть Ха , Аноним (-), 17:58 , 23-Сен-12, (201)   Смотри-ка, что pjd вчера закоммитил в head http svnweb freebsd org base view , iZEN (ok), 19:45 , 24-Сен-12, (323)   А мнение iZEN и nagual о фиче теперь поменяется на противоположное , Аноним (-), 13:39 , 26-Сен-12, (403)   Неизбежно , AlexAT (ok), 13:40 , 26-Сен-12, (404)   Смешно будет смотреться когда им придется обсирать свою же предыдущую точку зрен, Аноним (-), 19:26 , 26-Сен-12, (425)   Без TRIM Да, друзья Примерно как волк зайцу -o ssd при монтировании, AlexAT (ok), 07:36 , 02-Окт-12, (491)   Интересно для кого вы пишите этот бред Вот теореме Пифагора более 2000 лет и н, nagual (ok), 10:12 , 04-Окт-12, (522)   Ну да - всё те же тормоза Не ошибается тот, кто ничего не делает , AlexAT (ok), 11:37 , 05-Окт-12, (528)   gt оверквотинг удален Для того чтоб хорошие проекты могли хорошо работать, пло, nagual (ok), 10:25 , 20-Сен-12, (65) –2 // спасибо так и делаю D, ананим (?), 13:49 , 20-Сен-12, (77) А знаете, пока бсдшники злобно шипят, слоник как менеджер в общем то вполне норм, Аноним (-), 06:02 , 21-Сен-12, (109) Вы просто не в курсе событий сначала он раскрутил спонов на никому ненужный , nagual (ok), 08:19 , 21-Сен-12, (117) У, тогда почте рамблера имхо капец Если б не вджоб этого руководилы, оно бы так, Аноним (-), 11:58 , 21-Сен-12, (118) Вот когда сможет хотя бы RAID-5, тогда приходите Вот когда будет годный btrfsck,, iZEN (ok), 17:07 , 20-Сен-12, (88) // для моего ноута не критично использую бтр и не жалуюсь во-первых - уже во-вторых, ананим (?), 18:35 , 20-Сен-12, (89) А для моего десктопа критично pВы хотите сказать Не так давно, хоть что-то п, iZEN (ok), 19:36 , 20-Сен-12, (90) наслышен, наслышен DХа http www lissyara su articles freebsd file_system zfs, ананим (?), 20:43 , 20-Сен-12, (91) Это уже баян, который давно порвали на кусочки В ZFSv28 с 6 июня 2011 года во , iZEN (ok), 22:32 , 20-Сен-12, (92) угу Так кто ж спорил бы Dи боянист из тебя плохой - 0 19 даже уже в википедии , ананим (?), 00:20 , 21-Сен-12, (93) Да ты слушай больше этого Ыксперта, у тебя тоже диски будут работать как у него , Аноним (-), 06:04 , 21-Сен-12, (111) –1 http www linux org ru forum talks 8255499 cid 8255518, iZEN (ok), 21:47 , 22-Сен-12, (134) data journal, drive cache off, fsyncа чтобы не извращаться - надо ставить ИБП, AlexAT (ok), 09:52 , 23-Сен-12, (144) Ну вот оказываеся ext4 без журнала гробит данные И что же это она во всех теста, nagual (ok), 11:10 , 23-Сен-12, (153) Да нет, просто журналирование ДАННЫХ не метаданных - удел нищебродов, неспособ, AlexAT (ok), 11:17 , 23-Сен-12, (158) Сие следует понимать так - нетаскать упс за ноутом удел нищебродов - Ага и ч, nagual (ok), 11:21 , 23-Сен-12, (160) Сие следует понимать так Работать с критичными данными на ноуте с разряженной ба, AlexAT (ok), 11:27 , 23-Сен-12, (164) Ну и да - если уж нельзя оторваться от производства по пути - только нищеброды, AlexAT (ok), 11:28 , 23-Сен-12, (165) А как вы смените батарею не выключая бук и не закрывая все приложения - Гиб, nagual (ok), 11:38 , 23-Сен-12, (168) У кого в критичной среде оное не работает - милости прошу об стену или в окно , AlexAT (ok), 12:14 , 23-Сен-12, (175) И как помогает - , nagual (ok), 17:03 , 23-Сен-12, (194) Не знаю Первый раз человека с подобной проблемой увидел по приведенной выше ссы, AlexAT (ok), 18:43 , 23-Сен-12, (206) Проверьте Вы же любите требовать тесты Теперь наша очередь , Аноним (-), 13:40 , 26-Сен-12, (405) Человек вообще не открывал те файлы, что у него обнулились, но случайно оказалис, iZEN (ok), 12:18 , 23-Сен-12, (177) Когда при запуске fsck в фоне обнуляются открытые файлы это херово но не ново, н, nagual (ok), 17:05 , 23-Сен-12, (196) Я бы сказал, если руки из задницы - может и весь диск обнулиться Потому, что есл, AlexAT (ok), 18:43 , 23-Сен-12, (207) А случай с улетевшим разделом Этого не может быть потому что быть не может М, nagual (ok), 20:40 , 23-Сен-12, (241) За два года юза ext4 в продакшне не было ни одного случая отказа FS Был случай , AlexAT (ok), 20:43 , 23-Сен-12, (244) Он написал про какой-то фон Уж не пнул ли этот баклан fsck на смонтированном ра, Аноним (-), 15:32 , 01-Окт-12, (468) Очередной высер из серии - не читал но осуждаю fsck запускался из хост систем, nagual (ok), 00:29 , 02-Окт-12, (479) А, вот оно что А при чем тут фон Самокритичненько , Аноним (-), 21:40 , 02-Окт-12, (516) Не верю с либо руки, AlexAT (ok), 13:41 , 26-Сен-12, (406) Либо фс - , nagual (ok), 13:49 , 26-Сен-12, (408) Многолетней практикой не подтверждено - значит руки , AlexAT (ok), 14:04 , 26-Сен-12, (410) Какая у вас интересная практика, неужели за все эти годы нельзя было научиться х, nagual (ok), 00:30 , 02-Окт-12, (480) Моя практика стабильно работает годами на множестве серверов, поэтому заявления , AlexAT (ok), 07:22 , 02-Окт-12, (485) Массовых воплей не видно при том что оно дефолтное в 100500 дистрах, стало быть , Аноним (-), 20:30 , 26-Сен-12, (428) Вот действительно у бсд до пследнего времени была всего одна UFS и никакой паник, nagual (ok), 21:11 , 26-Сен-12, (431) –1 Стало вместо 1 тормознутой ФС две Вторая - тормознутая и переросточная Ассорти, Аноним (-), 20:58 , 30-Сен-12, (452) Да там так и есть всего одна UFS , ZFS реально эксплуатабельной считать нельзя , AlexAT (ok), 07:23 , 02-Окт-12, (486) Это статистика по твоей больнице что ли Оно и понятно http forum ixbt com , iZEN (ok), 13:44 , 02-Окт-12, (499) 88 человек - это МЕГА репрезентативная выборка, имя которой - ни о чём Тем бол, AlexAT (ok), 15:38 , 02-Окт-12, (500) Вот гораздо более вменяемый юзкейс http www dlink ru ru products 120 1477 html, AlexAT (ok), 15:52 , 02-Окт-12, (501) Длинк гавно - проверено на wi-fi роутерах и адсл мопедах , nagual (ok), 16:04 , 02-Окт-12, (503) Чем именно , AlexAT (ok), 16:50 , 02-Окт-12, (504) Длинк - это тайванокитайцы Поэтому у них есть все От супершита до вполне норма, Аноним (-), 21:44 , 02-Окт-12, (517) Тулчейн по изменению прошивки прилагается бесплатно или нужно подписывать специа, iZEN (ok), 22:54 , 03-Окт-12, (518) Обновил скрипты http actika livejournal com 619 html, nagual (ok), 23:02 , 03-Окт-12, (519) Простите, что такое iXSystems D-Link, WD, Synology - их знает весь мир А iXSys, AlexAT (ok), 23:34 , 03-Окт-12, (520) А, сам себе отвечу Это чудесники, которые купили и похоронили PC-BSD , AlexAT (ok), 23:34 , 03-Окт-12, (521) Обновил тестыhttp actika livejournal com 619 htmlext4 сошел с дистанции , nagual (ok), 16:31 , 04-Окт-12, (523) Ржали над высером про фрагментацию на рамдиске всей командой Потом на перекуре д, AlexAT (ok), 21:44 , 04-Окт-12, (524) Вместе с доктором или опять соло Если дефрагментатор запускуается наверно он , nagual (ok), 22:45 , 04-Окт-12, (525) пруф, или клиника , AlexAT (ok), 22:47 , 04-Окт-12, (526) пруф жж если неасилили - клинака , nagual (ok), 22:53 , 04-Окт-12, (527) ваш жж - это не пруф, а набор отборного бредаза исключением таблички, которая че, AlexAT (ok), 11:38 , 05-Окт-12, (529) Месье потрудится опровергнуть хотябы одно утверждение из жж а то слив не защит, nagual (ok), 14:08 , 05-Окт-12, (530) Бугага, тебе и там разъяснили, что ты чушь порешь по большей мере Удачи в жеван, AlexAT (ok), 14:16 , 05-Окт-12, (531) У ноута и так ups встроен , Аноним (-), 23:41 , 24-Сен-12, (347) Десктоп изена, тот что с голубыми кристаллами W W дисками выдающими 6Мб сек , Аноним (-), 12:34 , 21-Сен-12, (122) Хватит уже дурь свою показывать Освободится место 8212 скорость увеличится , iZEN (ok), 01:48 , 23-Сен-12, (139) Не увеличится, дефраггера-то нетуть , AlexAT (ok), 09:57 , 23-Сен-12, (149) Освободил 30 ГБ 8212 скорость возросла в разы Что я сделал неправильно , iZEN (ok), 11:59 , 23-Сен-12, (170) Скорость чего Перемещения руки вверх-вниз при просмотре содержимого В какой-то, AlexAT (ok), 12:15 , 23-Сен-12, (176) Скорость всего 8212 чтения, записи, просмотра данных Вот и я говорю спорить , iZEN (ok), 12:36 , 23-Сен-12, (181) Чего бы это ради Файлы которые разложились неудачно и читаются медленно - так и, Аноним (-), 06:50 , 24-Сен-12, (301) Гениально На основании того что у кого-то разбился тестовый прототип самолета м, Аноним (-), 18:57 , 23-Сен-12, (210) Правильным выводом было бы приостановить эксплуатацию этой модели самолета btrf, nagual (ok), 20:48 , 23-Сен-12, (246) Сложно приостановить эксплуатацию для штуки явно позиционируемой как тестовый , Аноним (-), 06:54 , 24-Сен-12, (302) Ну вот каких то два дня обсуждений и выясняется что btrfs неимеет того функциона, nagual (ok), 18:26 , 21-Сен-12, (128) Не с глаголами пишется раздельно P Да, пока еще не абсолютно все фичи реализова, Аноним (-), 09:12 , 22-Сен-12, (130) О да как жежить под zfs и без дефрагментатора - Обожаю дефрагментацию Вы, nagual (ok), 10:19 , 22-Сен-12, (132) Простите, а зачем Или ставить BSD ради поставить и настроить - это тренд такой , AlexAT (ok), 09:49 , 23-Сен-12, (143) В одном из двух случаев не явно лишнее - , nagual (ok), 11:08 , 23-Сен-12, (152) В случае с BSD - вероятно, да , AlexAT (ok), 11:16 , 23-Сен-12, (157) +1 Не знаю как вы там жежите Это наверное тут оффтопик А изен вон обожает 6Мб се, Аноним (-), 19:12 , 23-Сен-12, (211) Безусловно btrfs отличное решение для десктопа или ноута, правда на лоре пишут ч, nagual (ok), 21:02 , 23-Сен-12, (249) Да, целый один перец, с странными параметрами и отказавшийся от расследования Т, Аноним (-), 07:03 , 24-Сен-12, (303) Всего пару раз - зачет - дебиан о такой дебиан - Это 100 был релиз , nagual (ok), 11:22 , 24-Сен-12, (314) У дебиана есть свои проблемы А у bsd - свои Если уж о дебиане вспомнили то че, Аноним (-), 23:45 , 24-Сен-12, (350) Теперь известно , nagual (ok), 00:13 , 25-Сен-12, (360) Сферические прецеденты в вакууме - ну это круто, да Извините, я когда-то имел д, Аноним (-), 13:45 , 26-Сен-12, (407) Почему я не удивляюсь твоей глупости На, посмотри на Java в BSD http www fres, iZEN (ok), 01:53 , 23-Сен-12, (140) Я знаю что java отлично работает под bsd как и многое другое Но сановская java , nagual (ok), 11:00 , 23-Сен-12, (151) gt оверквотинг удален Картина маслом Опять двойка Сановская Java 5 0 и 6 0 б, iZEN (ok), 12:11 , 23-Сен-12, (172) Месье не использует java но знает лучше людей использующий java Это уже диаг, nagual (ok), 16:49 , 23-Сен-12, (190) Опять ты облажался, двоешник pkg_info -R openjdk6-b25_2Information for openjdk, iZEN (ok), 17:04 , 23-Сен-12, (195) Писец, вы умудрились обламерить даже друг друга , Аноним (-), 19:13 , 23-Сен-12, (213) За такие рекомендации надо отрывать руки Я бы посмотрел, как любимая некоторыми, AlexAT (ok), 09:40 , 23-Сен-12, (141) Дорогой контроллер рейда куча дисков и сервр на сдачу Месье стал жертвой марке, nagual (ok), 10:57 , 23-Сен-12, (150) Дорогой контроллер рейда С разморозкой, дорогой друг А тем временем даже дома у, AlexAT (ok), 11:14 , 23-Сен-12, (156) Месье таки стал жертвой рекламы интела, 20к собаке в сраку - а жена в курсе , nagual (ok), 11:18 , 23-Сен-12, (159) Зачем оно мне У меня есть своя специфика - виртуалки, dev test среда Поэтому в, AlexAT (ok), 11:25 , 23-Сен-12, (163) Совершенно с вами сгласен связка lvm ext4 явно не для сервера , nagual (ok), 11:35 , 23-Сен-12, (167) Только UFS, только хардкор , AlexAT (ok), 12:13 , 23-Сен-12, (174) +1 Если бы месье вылез из криокамеры он бы написал UFS J или хотябы UFS S на вскидк, nagual (ok), 17:02 , 23-Сен-12, (193) –1 Все равно до уровня ext4 этим ископаемым прилично далеко , AlexAT (ok), 18:42 , 23-Сен-12, (205) Ископаемое UFS2 в 2006 имело возможность работы со снапшотами, ACL, квотами, ф, iZEN (ok), 19:27 , 23-Сен-12, (216) Квотирование было еще в бородатом ext2 -http www linux org ru books HOWTO Quot, AlexAT (ok), 19:40 , 23-Сен-12, (219) После сбоя питания в дц виртуалка грузится в ридонли и них а не работает Выкл, nagual (ok), 21:33 , 23-Сен-12, (256) Расскажи, как тебе это удаётся Открою тебе маленький секрет какое-то время на м, AlexAT (ok), 23:15 , 23-Сен-12, (269) - Как тебе это удаётся Баримор- Хецнер сер , nagual (ok), 23:36 , 23-Сен-12, (278) Видимо, ярый бсдшник не смог найти хостера где хостом был бы бсд и предлагали бы, Аноним (-), 19:31 , 26-Сен-12, (426) Интересно подтверждение целостности файлов раз всё работает и не улетело, значи, iZEN (ok), 00:25 , 24-Сен-12, (290) А вот для этого очень могут пригодиться снапшеты - , nagual (ok), 00:30 , 24-Сен-12, (291) Сравнивалось один раз Непонятно, правда, зачем Все, кроме СУБД - выживает БД , AlexAT (ok), 00:30 , 24-Сен-12, (292) Опять же - упрежу тонну треша про непротиворечивость ZFS Непротиворечивость , AlexAT (ok), 00:34 , 24-Сен-12, (293) До сих пор думал, что у ZFS непротиворечивость записи базируется на логике CoW , iZEN (ok), 01:42 , 24-Сен-12, (295) Угу Вот только без write barrier порядка записи никто не гарантирует, и любой б, AlexAT (ok), 07:22 , 24-Сен-12, (307) Так запишется или нет Если запишется, то, очевидно, вся транзакционная группа D, iZEN (ok), 20:13 , 24-Сен-12, (325) Может быть запишется, а может быть нет А может быть и не всё Не факт Реордерин, AlexAT (ok), 20:53 , 24-Сен-12, (330) Умеете вы людей обрадовать , nagual (ok), 00:42 , 24-Сен-12, (294) Ну я же спецом написал Сразу говорю - не стоит в здравом уме делать то, что сд, AlexAT (ok), 07:24 , 24-Сен-12, (308) Наброски в продолжение темы http actika livejournal com 619 html, nagual (ok), 00:24 , 01-Окт-12, (458) Ещё проверь ZFS с checksum off , iZEN (ok), 09:31 , 01-Окт-12, (460) Несмотря на то, что тест - сферический и в вакууме ну идиотизм тестировать FS н, AlexAT (ok), 14:42 , 01-Окт-12, (463) Бедненькие бздунишки 8212 мучаются со всеми этими допотопными FS и горя не зн, iZEN (ok), 14:51 , 01-Окт-12, (464) А чего еще остается Только пожалеть людей, желающих добровольно грызть кактусы , AlexAT (ok), 15:45 , 01-Окт-12, (469) Если уж быть совсем честным - в Linux ничего, кстати, не включается Потому, что, AlexAT (ok), 16:23 , 01-Окт-12, (470) Что, уже и тесты есть для сравнения производительности фришных md 4 -девайсов и , iZEN (ok), 11:50 , 02-Окт-12, (495) http www linuxforums org forum installation 11239-what-does-grub-ramdisk-do ht, nagual (ok), 11:52 , 02-Окт-12, (496) 1 А что, мы сравниваем FS при перелезании в свап, или, может быть, просто FS на, AlexAT (ok), 12:48 , 02-Окт-12, (498) Обновил тесты в жж , nagual (ok), 15:56 , 02-Окт-12, (502) В общем-то, ничего не изменилось BSD все так же сливает по загрузке системы п, AlexAT (ok), 16:57 , 02-Окт-12, (505) Месье вообще куда смотрит Эксклюзивные галюцинации В данном тесте zfs единств, nagual (ok), 17:10 , 02-Окт-12, (506) Набросы Унылые при том Не в обиду тому кто делал бенчи, 1 Я не вижу тестов btr, Аноним (-), 16:42 , 01-Окт-12, (471) Нечитал но осуждаю Месье ниасилил пояснения к тестам Итак на диске с btrfs в, nagual (ok), 16:58 , 01-Окт-12, (473) Мотоцикл не мой, я только разместил объяву , AlexAT (ok), 07:19 , 02-Окт-12, (484) posix ACL тоже были в ext2 как минимум в 2003так что, увы, археологи археологами, AlexAT (ok), 19:41 , 23-Сен-12, (220) ДА было дело при запущенном fsck в фоне открытый на запись файл обнуляло в UFS S, nagual (ok), 20:35 , 23-Сен-12, (236) Дык Тут нужен специальный угол рук и необычное местоположение их начала , AlexAT (ok), 20:39 , 23-Сен-12, (240) Достаточно быть осьминогом Когда руки, голова и задница совмещены в одном месте, Аноним (-), 14:02 , 26-Сен-12, (409) А какая разница КрЮтые разработчики BSD заявили что на капитальную переделку эт, Аноним (-), 19:21 , 23-Сен-12, (214) Может и пруфлинки на тестирование Ext4 и UFS2 SJ предоставите Не стесняйтесь О, iZEN (ok), 19:31 , 23-Сен-12, (217) http www phoronix com scan php page article item zfs_ext4_btrfs num 1Похороник, AlexAT (ok), 19:48 , 23-Сен-12, (221) Пруфлинк не годен Там UFS J журнал на уровне GEOM и UFS S это просто Soft-up, iZEN (ok), 20:24 , 23-Сен-12, (226) Тестов UFS2 практически нет, что означает только одно Неуловимый Джо Если пригл, AlexAT (ok), 20:30 , 23-Сен-12, (231) На форониксе бывали, но увидев непотребный результат бздуны как обычно орут что , Аноним (-), 17:15 , 26-Сен-12, (420) Так с тех пор никто не переделывал основные дисковые структуры ФС А тормоза име, Аноним (-), 15:29 , 27-Сен-12, (434) –1 Правда что ли Тебе надо покопаться в истории изменений UFS FFS за последний год, iZEN (ok), 12:28 , 28-Сен-12, (437) Ну вот неправда же там все переделали на спичках - , nagual (ok), 15:20 , 28-Сен-12, (440) А еще загладывая в будущее разработчики ext4 прицепили инвалидную каляску вместо, nagual (ok), 15:21 , 28-Сен-12, (441) Хотел потестить ext4 и оказалось что в линуксе диск в памяти нельзя отформатиров, nagual (ok), 19:09 , 30-Сен-12, (442) Сферический тест в вакууме без реальной составляющей Ну давай, успехов , AlexAT (ok), 19:12 , 30-Сен-12, (443) У разработчиков фс в линуксе даже нет возможности потестить свою фс на быстром м, nagual (ok), 20:00 , 30-Сен-12, (449) Ну и да - способ создать ext4 на рамдиске прост, как бревно таким же способом м, AlexAT (ok), 19:16 , 30-Сен-12, (444) gt оверквотинг удален Фс на файл лежащий на фс в памяти - какой тонкий юмор, nagual (ok), 20:13 , 30-Сен-12, (450) gt оверквотинг удален mount -t ramfs -omasxsize 4G ramdisk ramdiskdd if dev , nagual (ok), 21:06 , 30-Сен-12, (453) Еще один высер, подобный тому, что выше о том, что в Linux ext4 на рамдиске не , AlexAT (ok), 22:00 , 30-Сен-12, (455) Кто бы мог подумать что в линуксе фс через файл Ну и как его так задать чтоб , nagual (ok), 22:24 , 30-Сен-12, (456) Есть две электрощитовых на одной написано опасность поражения током , на друго, AlexAT (ok), 07:23 , 01-Окт-12, (459) Месье работает електриком в жеке Судя по квалификации и лексикону очень может б, nagual (ok), 10:43 , 01-Окт-12, (461) Месье работает в операторе связи, так что и тут мимо тазика Вообще плохо у вас , AlexAT (ok), 13:50 , 01-Окт-12, (462) +1 Помнится кто то жаловался на точность df да уж dev loop0 6,5G 58k 5,8G , nagual (ok), 22:33 , 30-Сен-12, (457) А в чем пойнт такого тестирвоания У вас много рамдисков в реальном использовани, Аноним (-), 16:48 , 01-Окт-12, (472) Понт - отладка скриптов для тестирования Несмотря на то чо электрики из жека бо, nagual (ok), 17:10 , 01-Окт-12, (474) Выше написан настолько эпический бред, что мой мозг отказывается нормально это в, AlexAT (ok), 17:38 , 01-Окт-12, (475) +1 Понимаю для электрика из жека это трудно Месье не читает лора Какой эпичес, nagual (ok), 17:41 , 01-Окт-12, (476) –1 Я не нанимался в древнем булшите копаться Не, это UFS всякие Марафет вроде как-, Аноним (-), 21:31 , 30-Сен-12, (454) А номальные тесты есть фороникс нафигс , nagual (ok), 21:34 , 23-Сен-12, (257) Делай сам, публикуй, а мы на методику посмотрим, и оценим , AlexAT (ok), 23:18 , 23-Сен-12, (270) Сделайте лучше, если кишка не тонка А мы будем рассуждать о том кого нафигс p s, Аноним (-), 23:49 , 24-Сен-12, (351) Так потому и не ставят Ну, все кроме совсем уж ушибленных фанатов , Аноним (-), 19:33 , 26-Сен-12, (427) Тихо сам с собою левою рукою - , nagual (ok), 21:08 , 26-Сен-12, (430) Надо бы потестировать, только сначала стоит обсудить методику например диск в п, nagual (ok), 21:26 , 23-Сен-12, (255) Вполне , iZEN (ok), 21:51 , 23-Сен-12, (260) Что то мне подсказывает что не все так просто Если в системе 2-4 гига оперы под, nagual (ok), 22:59 , 23-Сен-12, (267) Вы собрались кэшировать рамдиск Прелестно xD, AlexAT (ok), 23:41 , 23-Сен-12, (282) Машина виртуалка под варей, диск в памяти обычный виртуальный диск на диске хост, nagual (ok), 00:04 , 24-Сен-12, (285) Стоп-стоп-стоп О какой варе речь ESXi Она не кеширует Надо чтобы объем диска, AlexAT (ok), 00:10 , 24-Сен-12, (287) Это Workstation 9 под вин Что то мне подсказывает что дисковые операции кеширую, nagual (ok), 00:14 , 24-Сен-12, (288) Вау, это самый сферический конь в наиболее чистом вакууме из того что я видел , Аноним (-), 23:50 , 24-Сен-12, (352) в случае если вы - iZEN , Аноним (-), 17:16 , 26-Сен-12, (421) Предлагаю обычный SATA HDD, раздел гигов на 50-60, объем памяти на тестовой маши, AlexAT (ok), 23:19 , 23-Сен-12, (271) Это будут тесты диска а не фс и расхождения между фс уложатся в погрешность , nagual (ok), 23:38 , 23-Сен-12, (280) Да нет - это как раз и будет реальный тест, а не сферические кони в вакууме Зад, AlexAT (ok), 23:40 , 23-Сен-12, (281) И чем все ваши тесты на рамдиске будут лучше фороникса, которые ZFS сравнивают с, Elhana (ok), 03:07 , 24-Сен-12, (296) Мы же обсуждаем методику тестирования или нет 5 дисков по 1 гигу хватит , nagual (ok), 10:21 , 24-Сен-12, (311) Фороникс и то более реалистичные конфигурации берет Вот скажите, сколько у вас , Аноним (-), 23:51 , 24-Сен-12, (353) К сожелению нету дисков для проверки хотябы raidz есть 2 по 320 , nagual (ok), 00:16 , 25-Сен-12, (361) Это будет реальный тест реальной ФС на реальном диске В погрешность не уложатся, Аноним (-), 14:21 , 26-Сен-12, (411) gt оверквотинг удален Если разница тестирования дисковых операций с двумя разл, nagual (ok), 15:24 , 26-Сен-12, (412) А она будет местами отличаться не на 1-2 а в пару раз А то и поболее Просто п, Аноним (-), 17:04 , 26-Сен-12, (417) Медицина бессильна, клиент недоступен Месье потрудится назвать такую фс которая , nagual (ok), 17:18 , 26-Сен-12, (422) Я в этом не виноват Да, файловые системы не очень простая штука, мозг может вын, Аноним (-), 15:54 , 27-Сен-12, (435) Зачем пустопорожние разговоры вести 8212 возьми и затести У UFS2 новый твик, iZEN (ok), 12:35 , 28-Сен-12, (438) На рандомной записи сольют - CoW линеаризует запись Но зато читать потом будет с, AlexAT (ok), 13:06 , 28-Сен-12, (439) Да вон какой-нибудь фороникс регулярно делают А бздунишки регулярно вопят что в, Аноним (-), 07:09 , 24-Сен-12, (304) А давайте сначала исключим из тестирования фс которые приводят к эпик фейлам - н, nagual (ok), 21:20 , 23-Сен-12, (253) –1 У кого, простите, приводят У криворучек Два года боевой эксплуатации БЕЗ каких, AlexAT (ok), 22:59 , 23-Сен-12, (266) Давайте лучше исключим из тестов ж поруких экспериментаторов А то юзаю EXT4 со , Аноним (-), 07:11 , 24-Сен-12, (305) +1 Да, легко В ESXi с этим порядок, тьфу-тьфу, и write barrier работает, как надо , AlexAT (ok), 07:51 , 24-Сен-12, (310) То был KVM , nagual (ok), 11:29 , 24-Сен-12, (317) Ну так я потому и уточняю что не уверен что квалификация оппонента позволяет отл, Аноним (-), 17:07 , 26-Сен-12, (418) Так вы поэтому тесты не делаете , nagual (ok), 11:24 , 24-Сен-12, (315) Скорее, потому что1 Дико лень копаться с bsd в связи с бессмысленностью этого , Аноним (-), 16:38 , 26-Сен-12, (414) Сделайте хотябы для своего горяче любимого linux-а Найдем уж как нибудь - , nagual (ok), 17:09 , 26-Сен-12, (419) Судя по тому как вы нехотите ничего тестироваь себя вы вычеркнули первым , nagual (ok), 15:34 , 26-Сен-12, (413) Эк вас ж порукость то зацепила, аж 2 раза откоментили Вы уж извините но на осно, Аноним (-), 16:41 , 26-Сен-12, (416) Он уже есть Не полный, но - есть А в zfs его попросту нет как класса И не над, Аноним (-), 06:02 , 21-Сен-12, (110) Не понимаю, чем так убог zpool scrub при работающей отмотке пула zpool import -, iZEN (ok), 22:01 , 22-Сен-12, (135) В связи с этим нулячие диски перед форматированием имеет смысл забить нулями - , nagual (ok), 23:28 , 22-Сен-12, (136) Удалённые нормальным образом файлы сводят на нет предварительное забитие нулями , iZEN (ok), 01:46 , 23-Сен-12, (138) И вот это - хуже всего Непредсказуемые фоновые процессы на, допустим, database , AlexAT (ok), 09:56 , 23-Сен-12, (148) На коровах бесполезно , AlexAT (ok), 09:54 , 23-Сен-12, (146) --- если том не смонтировался или упал в корку при монтировании - про лечит и , AlexAT (ok), 09:53 , 23-Сен-12, (145) Потрудитесь ссылку , nagual (ok), 11:11 , 23-Сен-12, (154) Ссылку на что На здравый смысл Это пять , Аноним (-), 19:23 , 23-Сен-12, (215) Сыылку на корку , nagual (ok), 21:21 , 23-Сен-12, (254) В гугле забанили http forums freenas org showthread php 7684-ZFS-Kernel-Panic , AlexAT (ok), 23:11 , 23-Сен-12, (268) gt оверквотинг удален Ссылки старые, в большинстве случаев не v28 в одном, nagual (ok), 23:33 , 23-Сен-12, (274) Да, пусть идёт Мне-то чего Я это в продакшне не юзаю, и не планирую , AlexAT (ok), 23:34 , 23-Сен-12, (275) Что то мне присутсвие fsck в ext4 не сильно помогло , nagual (ok), 23:34 , 23-Сен-12, (276) Руки, уважаемый, руки У меня даже в fsck необходимость возникала всего пару раз, AlexAT (ok), 23:35 , 23-Сен-12, (277) Судя по упоминанию виртуалок - там могла быть читерская реализация синхронной за, Аноним (-), 07:14 , 24-Сен-12, (306) Зато помогло мне, когда я отколупал с битого диска реально осыпающегося, с бэда, Аноним (-), 23:53 , 24-Сен-12, (355) zpool import -f HubZ2 8212 насильное импортирование пула Узнай сам, чем эт, iZEN (ok), 00:21 , 24-Сен-12, (289) Ага, так и запишем 1 признак п-ца с фрагментацией , Аноним (-), 23:54 , 24-Сен-12, (356) Для пущей эротичности предлагается сразу после такого rm чего-нибудь на диск поп, AlexAT (ok), 00:02 , 25-Сен-12, (358) В список рассылки nginx суньтесь - там этого есть , Аноним (-), 16:39 , 26-Сен-12, (415) 1,8

Сообщения

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

	64. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–3 +/–
	Сообщение от nagual (ok), 20-Сен-12, 10:23
	>> ZFS под линь пилят две комерческие конторы, бэтээру такое финансирование и не снилось. > А бтр пилят разработчики майнлайнового ядра. Не знаю считается ли это за > финансирование, но пилят его довольно интенсивно и в майнлайне. А не > где-то сбоку под левой лицензией. За чем будущее - несложно догадаться. Еще одна FS в коллекцию недофс линукса ... > Проект ФС вне майнлайна обречен быть маргинальной хренотенью нужной немногим, с > невнятными перспективами всего этого начинания. Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно становится маргинальной хренотенью ... > ...просто потому что BTRFS сможет то что и ZFS. И даже больше. > И лучше. Чем будут после этого зарабатывать указанные коммерческие конторы - > вопрос интересный. И что случится с этой кодовой базой - тоже > интересно, да. Поскольку если 2 коммерческие конторы окажутся без дохода от > этого начинания и выбросят его на свалку - тогда чего? Как > с опенсолярой и ораклем, да? :) Ну не летают кони у Оракла ... корма не те :-)))
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 21-Сен-12, 05:59
	> Еще одна FS в коллекцию недофс линукса ... Ну да, и только вы на белом коне. Сферическом. В вакууме. А ничего что у всяких соляр и бздей на выбор полторы ФС, при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы, но там тоже ничего интересного. Совсем античный FAT да тормозной и старинный NTFS. Ну и все. Еще есть UDF (правда толку то с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых. Ну в общем покажите ФС которые не "недо" по вашему мнению тогда. > Скорее все чего касаются менеджеры и все что удается монетизировать неизбежно > становится маргинальной хренотенью ... Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация BTRFS? То что она нужна толпе народа, в том числе и для всевозможных дел приносящих бабки - так это нормально вполне. Не верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как вам оно. Тогда глядишь и других за зарабатывание денег само по себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие методы, а есть не очень. >> этого начинания и выбросят его на свалку - тогда чего? Как >> с опенсолярой и ораклем, да? :) > Ну не летают кони у Оракла ... корма не те :-))) Да, сферические кони в вакууме - это прерогатива адептов *BSD :)
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok), 21-Сен-12, 08:16
	> Ну да, и только вы на белом коне. Сферическом. В вакууме. А > ничего что у всяких соляр и бздей на выбор полторы ФС, > при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - > ископаемое с архитектурой каменноугольного периода UFS. Еще есть всякие там шиндошсы, > но там тоже ничего интересного. Совсем античный FAT да тормозной и > старинный NTFS. Ну и все. Еще есть UDF (правда толку то > с него?) и странная хрень exfat. Смесь ископаемых и совсем ископаемых. > Ну в общем покажите ФС которые не "недо" по вашему мнению > тогда. Судя по этом бреду месье не часто инсталит ОС ... > Где вы такую дурь берете? И кстати просветите, в чем состоит монетизация > BTRFS? То что она нужна толпе народа, в том числе и > для всевозможных дел приносящих бабки - так это нормально вполне. Не > верите? Попробуйте поработать на регулярной основе без зарплаты и расскажите как > вам оно. Тогда глядишь и других за зарабатывание денег само по > себе осуждать не захочется. Просто зарабатывать можно по разному. Есть хорошие > методы, а есть не очень. Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз планирует загубить бтр. > Да, сферические кони в вакууме - это прерогатива адептов *BSD :) У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 21-Сен-12, 12:17
	>> Ну в общем покажите ФС которые не "недо" по вашему мнению тогда. > Судя по этом бреду месье не часто инсталит ОС ... Иногда - инсталлит. Но не слишком часто, ибо не является эникейщиком протирающим мышки. > Вай вай да месье маркетолог :)) внимательнее нужно быть оракля как раз > планирует загубить бтр. Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как в подстилке для своих БД. >> Да, сферические кони в вакууме - это прерогатива адептов *BSD :) > У вандовс самая быстрая ФС потому что операция линейного чтения всегда быстрее :)) кстати. Ваши данные протухли. Не, если сравнивать только с архаичным UFS и тормозным ZFS - вы даже может быть и правы. А если вспомнить о "недо-ФС" Linux и взять например, XFS то на больших файлах он обставит NTFS как делать нефиг. К тому же он намного меньше фрагментируется, там с фрагментацией борятся очень здорово. А если еще и более чем 1 диск в хранилище, XFS просто эпически рвет всех. Просто потому что ориентирован на параллельный доступ с его группами аллокации и поэтому почти всегда юзает диски параллельно, независимо от того как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских битовых карт на каждый пшик. Стоит ли говорить что работает сие не в пример шустрее в ряде случаев? Вообще, очень позитивная и резвая ФС вышла. По сути это лучшее что можно выжать из заюзанных технологий. А btrfs мало того что не особо то и тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12... - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей) так еще и фич предлагает много. Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о том как там все плохо, я с удовольствием послушаю о том как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается еще и кормят плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 21-Сен-12, 12:30
	> Зачем бы это ораклу? Когда нечто происходит, всегда есть вопрос: кому это > выгодно и кто в этом заинтересован. Оракл заинтересован в BTRFS как > в подстилке для своих БД. Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент. >[оверквотинг удален] > как именно это хранилище сделано. EXT4 тоже спуску как-то никому давать > не намерен, как миниимум на 1-дисковых конфигурациях. Будучи в отличие от > древней битмап-ориентированной NTFS-ины экстентным, он не нуждается в педалинге гигантских > битовых карт на каждый пшик. Стоит ли говорить что работает сие > не в пример шустрее в ряде случаев? Вообще, очень позитивная и > резвая ФС вышла. По сути это лучшее что можно выжать из > заюзанных технологий. А btrfs мало того что не особо то и > тормознут и вполне меряется с ext4 и xfs (пруфлинк: http://www.phoronix.com/scan.php?page=article&item=ubuntu_12... > - небольшой недавний бенчик, вполне обычный вроде, без каких либо особенностей) > так еще и фич предлагает много. Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет выше чем с любой фс, не ? Месье неисилил школьный курс физики? И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь. > Но вы мне и моим тестовым BTRFSным томам можете конечно рассказать о > том как там все плохо, я с удовольствием послушаю о том > как очередной бсдшник лечит про сферических коней в вакууме. Которых оказывается > еще и кормят плохо. Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки не ставьте свой линукс на btrfs и вы сэкономите время на переустановку.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 21-Сен-12, 12:55
	> Какой то месье не замечательный ... ни ... не замечет что лушим друзьям оракла У оракла есть друзья? А я то думал что при капитализме человек человеку - волк и конкурент. И если можно набить карман лишний раз - это следует сделать. А тут прямо какие-то новые открытия. > производителям рейд массивов ну на... ненужен бесплатный софтварный конкурент. Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше у них баз купят, тем лучше. И чем проще, быстрее и дешвле все остальное и чем проще оно админится и лучше работает - тем по идее выше спрос на БД. Так что в принципе btrfs вполне хорошо вписывается в их желание продавать их БД. Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто хотел аппаратный RAID - пойдет да купит его. А btrfs - просто полезняшка для админов этакая. > Я думал очевидно что скорость считывания файла после дефрагментации с NTFS будет > выше чем с любой фс, не ? Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит идеально непрерывно, одним фрагментом - практически любая ФС будет читать со скоростью примерно равной RAW доступу к диску. Стормозить при этом - это еще суметь надо. Не на чем тормозить :). Так что я ставлю на то что большинство ФС в этом случае дружно покажут результат крайне близкий к физическим пределам накопителя при чтении этих блоков просто так, не в рамках разбора ФС. Алсо, бывает такая вещь как SSD. Там важнее сколько операций делает ФС и какой от этого оверхед. Потому что seek time накопителя близок к нулю, скорости выше, так что начинает сильно влиять то сколько лишних операций проделает ФС. И bitmap-based ФС в этом плане опять оказываются в полной опе. Потому что педалить большие битовые карты - не очень то и быстро. Основная проблема с указанным случаем - это сферический случай в вакууме, который почти никогда не случается в реальности и потому малоинтересен на практике. > Месье неисилил школьный курс физики? Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня физике, особенно как раз разделам механики и электричества. Удачи в этом начинании :). Вот только я то как раз обычно достаточно отчетливо представляю себе во что именно физически и логически трансформируется то или иное  действо в цифровых девайсах. > И при чем тут райды? xfs быстрее и чем железные решения ? Несомневаюсь. А железные решения ничего такого фантастического не делают. Кроме того у них есть недостаток: они оперируют проприетарным форматом метаданных, так что если не дай боже железка вылетела а запасной такой же у вас нет - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно. Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно. Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей планет. Ы? :) > Для того чтоб раз и навсегда развеять бред красноглазых линуксаторов о пльзе > btrfs в часности и linux вообще могу сказать - если у вас меньше чем 2GB оперативки > не ставьте свой линукс на btrfs и вы сэкономите время на переустановку. Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет, в отличие от. Это у саней полностью отдельный кэш, живущий отдельно от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и BTRFS нет ни одной из этих проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 21-Сен-12, 13:12
	> У оракла есть друзья? А я то думал что при капитализме человек > человеку - волк и конкурент. И если можно набить карман лишний > раз - это следует сделать. А тут прямо какие-то новые открытия. Что то не везет вам в думании ... > Как бы интересы оракла слабо пересекаются с производителями массивов. Им чем больше > у них баз купят, тем лучше. Неужели после всего вышенаписанного для месье открытие что весь капитализм как явление природы принадлежит узкой группе сильно ограничсенных людей? Месье так и не заметил в силу своей природной незамечательности что иногда интересы очень разных корпараций вдруг удивительно сочетаются? > И чем проще, быстрее и > дешвле все остальное и чем проще оно админится и лучше работает > - тем по идее выше спрос на БД. Так что в > принципе btrfs вполне хорошо вписывается в их желание продавать их БД. > Более того, желающие вполне могут покупать и аппаратные рэйд массивы, поверх > которых раскладывать уютненький btrfs. Ничему не противоречит особо. Так что кто > хотел аппаратный RAID - пойдет да купит его. А btrfs - > просто полезняшка для админов этакая. Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ... > Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит > идеально непрерывно, одним фрагментом - практически любая ФС ... Дальше можно не читать. Странно что при всей своей эрудиции месье не понимает что файл идеально непрерывно может лежать только после дефрагментации и только в ntfs или fat :))) а для других фс даже дефрагментаторов нет :))) > Мсье осилил институтский, далеко за пределами ваших самых смелых ожиданий. Поучите меня > физике, особенно как раз разделам механики и электричества. Удачи в этом > начинании :). Вот только я то как раз обычно достаточно отчетливо > представляю себе во что именно физически и логически трансформируется то или > иное  действо в цифровых девайсах. Неужели месье асилил Левашева ? > А железные решения ничего такого фантастического не делают. Кроме того у них > есть недостаток: они оперируют проприетарным форматом метаданных, так что если не > дай боже железка вылетела а запасной такой же у вас нет > - вы вообще остаетесь без доступа к данным. Резко, больно и > внезапно. Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров сразу идут лесом. > Кстати да, вон у гугля распределенная сетевая ФС обслуживает всю планету. Софтварно. > Удачи вам собрать аппаратный RAID который осилит долбеж юзерами со всей > планет. Ы? :) К чему это ... наверно обострение. > Не надо переносить проблемы ZFS и BSD на пингвины. Их там нет, > в отличие от. Это у саней полностью отдельный кэш, живущий отдельно > от системного зачем-то. И тормозной дизайн ФС, который без подпорки диким > количеством кэша выставляет напоказ свою слоупочную натуру. Но в Linux и > BTRFS нет ни одной из этих проблем. Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц Ну если хотите в этом сами убедиться - попробуйте.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 22-Сен-12, 07:06
	> Что то не везет вам в думании ... Да ладно вам, нормально вполне. Кстати понимание работы этой механики еще не означает одобрение такого подхода и/или симпатий ко многим методам работы капиталистов. > заметил в силу своей природной незамечательности что иногда интересы очень разных > корпараций вдруг удивительно сочетаются? Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А как только дружба начинает мешать выгоде - так сразу же вчерашний друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов не забывайте о том что они улыбаясь и дружа с удовольствием прокатят "ближнего своего" и пырнут в спину, если это сулит хоть какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет по головам и трупам. Природа настоящего капиталиста такова. >> хотел аппаратный RAID - пойдет да купит его. А btrfs - >> просто полезняшка для админов этакая. > Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ... Да, я додумал: вы зациклены на *bsd и ZFS. И никак не можете понять, что архитектурно btrfs мало того что не слишком похож на zfs, так еще исправляет ряд его упущений и обладает рядом настроек которые в принципе позволят ему достаточно сухо и комфортно жить на весьма разных по своей природе накопителях. >> Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит >> идеально непрерывно, одним фрагментом - практически любая ФС ... > Дальше можно не читать. Странно что при всей своей эрудиции месье не > понимает что файл идеально непрерывно может лежать только после дефрагментации Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться добиться именно такого случая настолько насколько позволяют реалии свободного места на диске. Чем больше свободного места на диске и меньше фрагментировано свободное место, тем лучше это получается. В клиническом случае если мы резво пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно. >  и только в ntfs или fat :))) Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают и приветствуют. Чисто практически - уж насколько получится. И даже мелкие неидеальности типа seek в сторону 1 раз на 100Мб мало чего меняют. Ну будет не 100% скорости а 99%, допустим. Никто и не заметит особой разницы. Фрагментация являет собой проблему когда том становится загажен и не удается выкроить непрерывный кусок. > а для других фс даже дефрагментаторов нет :))) Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением старого размазанного варианта, например. При этом используется свойство аллокатора пытаться разложить файл максимально линейно. Таким манером можно частично отдефрагментировать практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь бы свободного места было много, иначе аллокатору негде будет развернуть деятельность по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, если совсем опа в ФС еще не наступила. По поводу чего и не советуют тома забивать более чем на 70-90%. Иначе сильно фрагментируется свободное место и том коллапсирует. Что будет - отлично видно на примере изена, с его легендарными 6Мб/сек на шпиндель :) Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу. В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. А раз он всяко есть и кантует блоки - пусть заодно и дефрагит в процессе! В btrfs этот достаточно очевидный факт до разработчиков дошел и там GC совмещен с дефрагером, по поводу чего у btrfs есть встроенный дефраг. В ZFS такого не было, да. Почему? Наверное потому что это одна из первых CoW ФС. Так что ваши сведения кривоваты и староваты. FAIL. > Неужели месье асилил Левашева ? Не припоминаю такой фамилии. Но мсье знает некоторые другие фамилии. Например, Ланау и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на 2 страницы и полагают что все остальные могут не хуже, поэтому просто не приводят подобные преобразования в своей книжке :). Ну а в плане электроникм мсье попалась достаточно годная книжка по основам полупроводниковой схемотехники от У. Титце и К. Шенка (в переводе на русский, они изначально немцы). Все основы изложенные там до сих пор вполне актуальны. И да, смею заверить что грубо прикинуть как будет разложен файл, хоть немного преставляя себе логику работы ФС - я в состоянии. Как в состоянии предсказать некоторые сценарии, например то что получилось на томе у какого-нибудь изена :). Я даже не видя того что у него на томе могу примерно представить себе как сие выглядит, если отрисовать занятость тома. ИЧСХ, оно как-то так обычно и оказывается. >> - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно. > Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот > потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров > сразу идут лесом. Собственно, одна из причин по которым не все юзают аппаратные рэйды. А также ФС с управлением томами самолично имеет больше шансов разложить данные по дискам более удачно если природа хранилища не скрыта от нее железкой. А так - оракл может чисто номинально дружить с кем угодно. Но в конечном итоге они базы продают. Рэйды им могут быть интересны, если это помогает базы продавать. Но в целом им перпендикулярно, существуют рэйды или нет. Это вообще кастомеровские проблемы и проблемы сторонних контор. А их интересуют продажи баз. Продастся ли при этом аппаратный рэйд - уж точно не проблема оракла. Поэтому называя вещи своими именами, ораклу более-менее все-равно. Тем более что если некое хранилище работает, то btrfs поверх него ничему не противоречит. Тем более что в btrfs настраивается как именно хранить данные и метаданные. Например если кто уверен что хранилище офигеть какое надежное - он может выключить зеркалирование метаданных, например. Скорость возрастет. А надежность... ну если хранилище надежное - сами знали на что шли. > К чему это ... наверно обострение. Да, обострение чувства голода. Кушать хочется после того как втирают всякое ламерство про фрагментацию :) > Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц > Ну если хотите в этом сами убедиться - попробуйте. Это вы про ZFS. Не надо переносить его свойства на btrfs. Я его ради лулзов запускал на железке с 64Мб и хилым процом. Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации и меньше нагружал проц, что для мелкой железки актуально. А на типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать вполне по королевски. Оно в целом помедленнее ext4 (который вышел на удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на недавние бенчи привел.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 22-Сен-12, 10:12
	> Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А > как только дружба начинает мешать выгоде - так сразу же вчерашний > друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это > просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов > не забывайте о том что они улыбаясь и дружа с удовольствием > прокатят "ближнего своего" и пырнут в спину, если это сулит хоть > какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет > по головам и трупам. Природа настоящего капиталиста такова. Нет никакой необходимости записывать свои открытия в форуме. > Да, я додумал: вы зациклены на *bsd и ZFS. И никак не > можете понять, что архитектурно btrfs мало того что не слишком похож > на zfs, так еще исправляет ряд его упущений и обладает рядом > настроек которые в принципе позволят ему достаточно сухо и комфортно жить > на весьма разных по своей природе накопителях. Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно. > Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи > файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться > добиться именно такого случая настолько насколько позволяют реалии свободного места на > диске. Чем больше свободного места на диске и меньше фрагментировано свободное > место, тем лучше это получается. В клиническом случае если мы резво > пишем файл на только что созданную пустую ФС, он скорее всего > будет выложен идеально линейно. Последняя враза явная лож :))) как минимум для половины фс. > Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно > на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают > и приветствуют. Чисто практически - уж насколько получится. И даже мелкие > неидеальности типа seek в сторону 1 раз на 100Мб мало чего > меняют. Ну будет не 100% скорости а 99%, допустим. Никто и > не заметит особой разницы. Фрагментация являет собой проблему когда том становится > загажен и не удается выкроить непрерывный кусок. Вы что то упустили в теории. > Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением > старого размазанного варианта, например. При этом используется свойство аллокатора пытаться > разложить файл максимально линейно. Таким манером можно частично отдефрагментировать > практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь > бы свободного места было много, иначе аллокатору негде будет развернуть деятельность > по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, > если совсем опа в ФС еще не наступила. По поводу чего > и не советуют тома забивать более чем на 70-90%. Иначе сильно > фрагментируется свободное место и том коллапсирует. Что будет - отлично видно > на примере изена, с его легендарными 6Мб/сек на шпиндель :) Месье может назвать хоть одну фс в линуксе которая попадает под его критерий- практически любую "классическую" ? > Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными > утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно > есть сразу. Есть но до виндозного ему еще очень далеко :)) > В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий > устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. > А раз он всяко есть и кантует блоки - пусть заодно > и дефрагит в процессе! В btrfs этот достаточно очевидный факт до > разработчиков дошел и там GC совмещен с дефрагером, по поводу чего > у btrfs есть встроенный дефраг. В ZFS такого не было, да. > Почему? Наверное потому что это одна из первых CoW ФС. Палундра в ZFS нет дефрагментатора %) > Не припоминаю такой фамилии. Я почему то не ожидал другова ответа :-)) >Но мсье знает некоторые другие фамилии. Например, Ланау > и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на > 2 страницы и полагают что все остальные могут не хуже, поэтому > просто не приводят подобные преобразования в своей книжке :). И какая практическая польза от этой ментальной маструбации ? > Это вы про ZFS. Не надо переносить его свойства на btrfs. Я > его ради лулзов запускал на железке с 64Мб и хилым процом. > Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации > и меньше нагружал проц, что для мелкой железки актуально. А на > типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать > вполне по королевски. Оно в целом помедленнее ext4 (который вышел на > удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на > недавние бенчи привел. Оно себя будет чуствовать по королевски пока вы не запустите лису или что там у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш. С счастью большинство читателей не станут тратить время на этот бред. В целом это называется калейдоскапический идиотизм. Диагноз гуглится.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 09:47
	> Оно себя будет чуствовать по королевски пока вы не запустите лису или > что там у вас на ноуте, тоесть пока 2 гига памяти > свободны и могут использоваться под кеш. Бугыг. Только хотел этому кексу написать "а ты текущую из всех щелей лису на что-нибудь другое менять пробовал" - как он сам сразу и спалился.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 17:58
	> Нет никакой необходимости записывать свои открытия в форуме. Ну я не виноват что вы не знаете элементарных вещей, приходится разъяснять и в ротик класть. Я бы предпочел этого не делать, честно-честно. >> настроек которые в принципе позволят ему достаточно сухо и комфортно жить >> на весьма разных по своей природе накопителях. > Мы тут много обсуждали натройки zfs но ниразу не видели настроек btrfs ... странно. Вообще-то это было про btrfs. А то что вы не видели - не удивительно. Вы видите только то что хотите видеть, а не то что есть на самом деле. Вы всегда пытаетесь выдать желаемое за действительное и ужасно палитесь на различных нестыковках :) >> пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно. > Последняя враза явная лож :))) Хоть это и не форум русского языка, но орфографические ошибки за которые ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с мягким знаком на конце. > как минимум для половины фс. Почему для половины? А не четверти? Или трех восьмых? Обоснуйте. Столь фундаментальная заява должна иметь под собой простое и понятное даже кухарке обоснование. Со своей стороны я могу себе представить как на свежесозданной ФС файл будет разложен линейно вплоть до почти полной емкости диска. Просто потому что ничего не валяется на проходе и не мешает его так раскладывать. >> не заметит особой разницы. Фрагментация являет собой проблему когда том становится >> загажен и не удается выкроить непрерывный кусок. > Вы что то упустили в теории. Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость заметно падает если диск заметный процент времени проводит делая перемещения голов нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. > Месье может назвать хоть одну фс в линуксе которая попадает под его > критерий- практически любую "классическую" ? Например, ext4 (в принципе и все ext2...ext4). JFS. До некоторой степени - XFS. У него правда есть allocation groups - он как раз не совсем линейно раскладывает файлы, нарезая их кусками. Но куски большие и по этому поводу скорость не только не проседает, но и вообще, это очень шустрая ФС. Особенно - в плане работы с большими файлами как раз. А за счет такой нарезки оно выигрывает в скорости на многодисковых хранилищах. >> утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу. > Есть но до виндозного ему еще очень далеко :)) Да, гламурных кнопочек нету. Какая трагедия. >> Почему? Наверное потому что это одна из первых CoW ФС. > Палундра в ZFS нет дефрагментатора %) Да вон iZEN уже ощущает результат. И даже если он осовободит место, сильно лучше может и не стать. В общем то нет простого метода расчистить такое без дефрагментатора. >> Не припоминаю такой фамилии. > Я почему то не ожидал другова ответа :-)) Наверное потому что это достаточно специфичный субъект. В то время как меня интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не просто домыслы. По этой причине я вообще достаточно осторожно отношусь к любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно отличается от практически наблюдаемого. >> просто не приводят подобные преобразования в своей книжке :). > И какая практическая польза от этой ментальной маструбации ? Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст миллионов в кармане. И даже набить брюхо не поможет. Просто у некоторых людей интересы простираются чуть дальше. > Оно себя будет чуствовать по королевски пока вы не запустите лису или что там > у вас на ноуте, тоесть пока 2 гига памяти свободны и могут использоваться под кеш. А оно и при небольшом кеше не сдувается так как ZFS. Вы прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что с блоками переменного размера. > С счастью большинство читателей не станут тратить время на этот бред. В > целом это называется калейдоскапический идиотизм. Диагноз гуглится. Да уж. Диагноз называется "BSDшник-пионер".
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	202. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 18:28
	> ... приходится разъяснять > и в ротик класть. Я бы предпочел этого не делать, честно-честно. И не делайте, тем более половина неверная ... > Вообще-то это было про btrfs. А то что вы не видели - > не удивительно. Вы видите только то что хотите видеть, а не > то что есть на самом деле. Вы всегда пытаетесь выдать желаемое > за действительное и ужасно палитесь на различных нестыковках :) Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ... Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ? > Хоть это и не форум русского языка, но орфографические ошибки за которые > ученикам 3 класса лепят двойки - напрягают. Вообще-то, "ложь" пишется с > мягким знаком на конце. Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь не часто ... > Со своей стороны я могу себе представить как на свежесозданной ФС файл > будет разложен линейно вплоть до почти полной емкости диска. Просто потому > что ничего не валяется на проходе и не мешает его так > раскладывать. В UFS и ZFS это точно не так :-))) >>> не заметит особой разницы. Фрагментация являет собой проблему когда том становится > Что именно? Укажите и обоснуйте. С моей колокольни это выгялдит так: скорость > заметно падает если диск заметный процент времени проводит делая перемещения голов > нежели чтение данных. Такая формулировка не исключает фрагментацию, но показывает зависимость > между скоростью чтения файла и расположением фрагментов. Это подтверждено многочисленными > наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. Все эти построения основаны на необходимости считывать данные которые могут хотябы потенциально быть записаны последовательно. Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу либо это удивительное совпадение которых в реальной жизни не бывает. > Да, гламурных кнопочек нету. Какая трагедия. Как насчет объединения свободного пространства ? > Наверное потому что это достаточно специфичный субъект. В то время как меня > интересуют в основном более-менее проверенные фактами и экспериментами вещи, а не > просто домыслы. По этой причине я вообще достаточно осторожно отношусь к > любым теориям которые не подтверждены практикой и/или когда теоретический результат сильно > отличается от практически наблюдаемого. Неужели вам удалось поймать нейтрино? > Мне нравится узнавать об устройстве мира. Этого достаточно. Нет, это не даст > миллионов в кармане. И даже набить брюхо не поможет. Просто у > некоторых людей интересы простираются чуть дальше. В двух словах пользы никакой :-))) > А оно и при небольшом кеше не сдувается так как ZFS. Вы > прикиньте? Да, там нормальный экстентный аллокатор а не черт знает что > с блоками переменного размера. Именно переменные блоки дают преимущества над железными RAID. У btrfs его нет увы, поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-))) > Да уж. Диагноз называется "BSDшник-пионер". Ох уж эти маркетологи.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 21:01
	> И не делайте, тем более половина неверная ... Не так уж плохо по сравнению с вашими сообщениями. У вас КПД намного хуже, увы. >> то что есть на самом деле. Вы всегда пытаетесь выдать желаемое >> за действительное и ужасно палитесь на различных нестыковках :) > Наверно поиск по Crtl F по маске sysctl тоже находит только то что хочет ... Не совсем понимаю при чем тут ваш sysctl. Что за перевод стрелок? Из ярких примеров - вы откуда-то взяли про 2 гига потребные btrfs. Явно путая его с ZFS или просто откровенно завирая на форуме. > Поделитесь с нами тонкостью настройки своей чудо btrfs или опять одна лирика ? Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким ламерюгам желания совершенно нет. Вот если вы опишете конфигурацию и что хотите получить - тогда можно будет подумать что можно покрутить. И то большинство твиков очевидны и я не вижу смысла метать бисер. > Судя по вашим познаниям в русском языке с информационными технологиями вы сталкиваетесь > не часто ... Просто если некто изъясняется на уровне папуаса, возникает ощущение что у него и интеллект в целом на уровне папуаса остался. Вон например тут рядом изен - типовой папуас рассказывающий про то как работает микроволновка: кладем еду, жмем это и это - она жужжит - получается еда. Во. При слове "магнетрон" или "волны" у папуаса случается кернелпаник :) >> Со своей стороны я могу себе представить как на свежесозданной ФС файл >> будет разложен линейно вплоть до почти полной емкости диска. Просто потому >> что ничего не валяется на проходе и не мешает его так раскладывать. > В UFS и ZFS это точно не так :-))) На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то близкое к этому. Если это не так - ну ой, сочувствую, плохо значит там с аллокаторами дела. Я в этом не виноват. И если для CoW это еще можно понять (хотя опять же, а что мешает класть фрагменты друг за другом последовательно?) то для "классики" это вообще трындец какой-то. >> наблюдениями, изучением расположения файлов соотв. утилитами и просто здравым смыслом. > Все эти построения основаны на необходимости считывать данные которые могут хотябы > потенциально быть записаны последовательно. Так мы вроде и говорили о идеальном случае когда 1 файл пишется на пустую ФС линейно. Большинство ФС его при этом весьма линейно и впихнет. При этом почти любая ФС покажет скорость записи и чтения сравнимую с скоростью работы диска в режиме RAW доступа без разбора ФС. Просто потому что в этой ситуации нечему тормозить. > Вот тут здравый смысл подсказывает что либо они принадлежат одному файлу > либо это удивительное совпадение которых в реальной жизни не бывает. А тут вы попались на невнимательности, поскольку это было про случай столь симпатичных вам сферических коней в вакууме - создаем файл на пустой ФС и смотрим какая скорость. >> Да, гламурных кнопочек нету. Какая трагедия. > Как насчет объединения свободного пространства ? Хм, вот это не помню, может и не умеет. В принципе объединение пространства неплохая идея, но в конечном итоге это уже относительно некритичный улучшайзер. Если уж посмотреть на бсды, там и такого нет. >> отличается от практически наблюдаемого. > Неужели вам удалось поймать нейтрино? Их в общем то нынче уже регулярно ловят, если что. Можно считать что на промышленной основе. Самолично не ловил, т.к. это требует слишком монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы хоть что-то поймать, вещества должно быть много. Значит, установка будет большой. >> некоторых людей интересы простираются чуть дальше. > В двух словах пользы никакой :-))) Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно так же в этом плане. Так что странно что вы ими умудряетесь при этом пользоваться. Хотя судя по тому что вы так хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно не фонтан. > Именно переменные блоки дают преимущества над железными RAID. А обосновать столь громкую заяву? В чем преимущества, откуда получаются, чем обусловлены на уровне физики и логики процесса? > У btrfs его нет увы, У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) как в ZFS. Что это означает? То что при непрерывной записи больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его его как ОДНУ запись экстента. А вот ZFS при этом будет вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых. Что быстрее: пометить регион в хренадцать мегов как занятый за 1 присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно намекают. > поэтому фаны линукса начинают ругать переменные блоки ... знакомо :-))) Так экстенты - то же самое по смыслу, только без тупых ограничений на максимальный размер в всего 128 кило/1 мег. >> Да уж. Диагноз называется "BSDшник-пионер". > Ох уж эти маркетологи. Да уж, основательно промыли ваши мозги маркетинговым буллшитом.
	Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

	261. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 22:04
	> У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть > один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) > как в ZFS. Что это означает? То что при непрерывной записи > больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если > некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его > его как ОДНУ запись экстента. А вот ZFS при этом будет > вынужден перелопатить куда больше метаданных, помечая все хренадцать блоков как занятых. > Что быстрее: пометить регион в хренадцать мегов как занятый за 1 > присест или за хренадцать раз? Вывод очевиден. Да и бенчмарки недвусмысленно > намекают. Тест от 27 июня 2012 года: "For the 8GB IOzone write test, ZFS on the OCZ Solid 2 SSD was right in the middle between EXT4 and Btrfs while on the HDD it was tied with EXT4 for being the slowest." http://www.phoronix.com/scan.php?page=article&item=linux_zfs... На HDD Ext4 чуточку слила LLNL ZFS v0.6.0-rc9. Так что вы там про экстенты говорили и про "лопатитЬся меньше данных"?... ;)
	Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

	272. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 23:21
	На Threaded I/O Write Test, особенно на HDD, ZFS можно сравнивать только с BTRFS. Почему - уже объяснял в этой теме.
	Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

	446. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 30-Сен-12, 19:25
	> http://www.phoronix.com/scan.php?page=article&item=linux_zfs... > На HDD Ext4 чуточку слила LLNL ZFS ...а про то что их в этих тестах на механике совершенно дико порвал btrfs - тактично промолчал. Ох уж эти бсдшники! :) "Если факты не подтверждают теорию, от них надо избавиться!" (законы мерфи). К сожалению для вас я иногда хожу по ссылкам :P
	Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

	263. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 22:47
	> Не совсем понимаю при чем тут ваш sysctl. Ох уж эти провалы в памяти ... > Тонкости настройки более-менее описаны в мануале. Пересказывать забесплатно ман всяким > ламерюгам желания совершенно нет. С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-)) >> В UFS и ZFS это точно не так :-))) > На каком-то фундаментальном уровне они могли бы изобразить по крайней мере что-то > близкое к этому. Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье ЧСВ в потолок уперлось. :-))) >> Все эти построения основаны на необходимости считывать данные которые могут хотябы >> потенциально быть записаны последовательно. Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались приблизительно с одинаковой скоростью ? Не ? > Хм, вот это не помню, может и не умеет. В принципе объединение > пространства неплохая идея, но в конечном итоге это уже относительно некритичный > улучшайзер. Если уж посмотреть на бсды, там и такого нет. Опять провалы в памяти ... > Их в общем то нынче уже регулярно ловят, если что. Можно считать > что на промышленной основе. Самолично не ловил, т.к. это требует слишком > монструозного реквизита, который на дороге не валяется. Зато методика опробована кучей > различных команд и работает. Нейтрино слабо взаимодействуют с веществом. Поэтому чтобы > хоть что-то поймать, вещества должно быть много. Значит, установка будет большой. Нейтрино не взаимодействует ни с чем ... месье далек от физики ? :-)) > Для желающих просто набить брюхо - ну да. Впрочем ваши бзди примерно > так же в этом плане. Так что странно что вы ими > умудряетесь при этом пользоваться. Хотя судя по тому что вы так > хорошо знаете виндовый дефрагер, вероятно как десктоп ваша любимая бздя действительно > не фонтан. Анекдот в тему: приходят два недо-пхп-программиста сисадминами на работу устраиваться, и один другому говорит: - не bsdи? прорвемся ... >> Именно переменные блоки дают преимущества над железными RAID. > У btrfs есть экстенты. Чем-то похожее по смыслу, но у них есть > один важный нюанс. Они не ограничены 128Кб (дефолт) или 1Мб (максимум) > как в ZFS. Что это означает? То что при непрерывной записи > больщих файлов большими кусками будет лопатиться меньше метаданных. Так что если > некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его > его как ОДНУ запись экстента. Ага а если питаение в этот момент пропадет то его одним куском и похерит :-))
	Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

	332. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 21:17
	>> Не совсем понимаю при чем тут ваш sysctl. > Ох уж эти провалы в памяти ... Так продолжите мыслю в нормальном виде. >> ламерюгам желания совершенно нет. > С такими провалами в памяти да забесплатно ? Я бы тоже не согасился :-)) Ну и замечательно, мне же меньше геморроя. > Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье > ЧСВ в потолок уперлось. :-))) Я могу себе представить как выглядело бы соответствующее размещение структур на диске. Только и всего. Насколько близко к этому приблизится реальный аллокатор - зависит от его реализации, разумеется. Просто в отличие от вас, полагающих что вам в высокие материи врубиться не дано, я предпочитаю понимать основы того как все это работает. И это не ЧСВ а констатация очевидных фактов. Просто капитанинг. > Вероятно разработчики UFS хотели чтоб при любой степени заполненности диска данные читались > приблизительно с одинаковой скоростью ? Не ? Они хотели одного: не бубухать в его переделку людские ресурсы которых у бсдшников сроду нет. Поэтому они оставили архаичный дизайн, примотав к нему скотчем и проволокой улучшайзеры. А указанную вами цель на 100% не достигает практически ни 1 дизайн ФС. Ну кроме случая когда ФС отдефрагят, но там свои проблемы, в том что в клиническом случае дефраг может не справиться ни за какое разумное время вообще. Например, мсье как-то раз видел как виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе на всего жалких 40Гб за целые сутки непрерывного хрустения. Какая скорость работы всего этого - несложно догадаться. Да-да, хваленый вами нтфс выдавал 5-10Мб/сек, что для десктопного винча просто смехотворно. В итоге оказалось проще сдвинуть оттуда все файлы и переформатить. Не в пример быстрее и результативнее. >> пространства неплохая идея, но в конечном итоге это уже относительно некритичный >> улучшайзер. Если уж посмотреть на бсды, там и такого нет. > Опять провалы в памяти ... Ох, правда? Тогда покажите мне дефрагеры в вашей любимой bsd. > Нейтрино не взаимодействует ни с чем ... Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино и узнал что теория относительности не пошатнулась, просто GPS используемый для синхронизации малость налажал. > месье далек от физики ? :-)) Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл "детектор нейтрино" - даже расскажут про них, какие бывают, где строят и прочая. Хотя может быть, все эти лохи тоже далеки от физики и только nagual у нас тут умный. Вот только он упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его относительная величина - мизер. А как же тогда радар у гайцев работает? А почему в GPS его учитывают? Они еще и теорию относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской механикой. А вот ФИГ. > и один другому говорит: - не bsdи? прорвемся ... Да, вам этот анекдот подходит, судя по постам :) >> некто хочет записать кусок "хренадцать мегабайт", btrfs вполне может оформить его >> его как ОДНУ запись экстента. > Ага а если питаение в этот момент пропадет то его одним куском и похерит :-)) Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл или будет в старом состоянии, или в новом. А что вы будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен. Зато выглядит почти как живой. В этом плане btrfs вообще монстр. Всегда можно отмотать на снапшот. Это настолько простая и легкая операция что он их на автомате делает. И при сбое просто отматывает на последний успешный снапшот. И рекавери при сбое быстрое и состояние файлов  куда предсказуемее чем обычно в классических ФС. В UFS это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь, мерседесом он от этого не станет.
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	338. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 22:15
	>> Безусловно месье знает лучше разработчиков но его забыли стросить. Похоже у месье >> ЧСВ в потолок уперлось. :-))) > Я могу себе представить как выглядело бы соответствующее размещение структур на диске. > Только и всего. Насколько близко к этому приблизится реальный аллокатор - > зависит от его реализации, разумеется. Ссылка на статью с описанием уже постилась. > Просто в отличие от вас, полагающих > что вам в высокие материи врубиться не дано, я предпочитаю понимать > основы того как все это работает. Судя по всему получается плохо ... > И это не ЧСВ а > констатация очевидных фактов. Просто капитанинг. nagual выглядывая в окно - Однако осень. > Поэтому они оставили архаичный дизайн, примотав к нему > скотчем и проволокой улучшайзеры. ext2 ext3 ext4 ... ждем ext5 ? :-)) > Например, мсье как-то раз видел как > виндовый дефрагер не осилил заметно улучшить картину на сильно забитом разделе > на всего жалких 40Гб за целые сутки непрерывного хрустения. Неужели месье за столько лет работы с разными фс так и не понял что любую фс нельзя забивать выше 70% ? >> Нейтрино не взаимодействует ни с чем ... > Вообще-то, достаточно сильный поток нейтрино повстречавшись с достаточно большим объемом > вещества все-таки немного но взаимодействует. Т.к. нейтрино почти не взаимодействуют > с веществом, детекторы являют собой достаточно исполинские сооружения. Ну чтобы повысить > вероятность детектирования, детектор должен быть большим, а нейтрино - побольше. Более > того, я вполне себе следил за приколами типа "якобы сверхсветовых" нейтрино > и узнал что теория относительности не пошатнулась, просто GPS используемый для > синхронизации малость налажал. Товарищ сержант а танки летают ? летают только очень низко ... :-))) > Мсье вполне себе интересуется элементарными частицами. Между прочим, если ввести в гугл > "детектор нейтрино" Если бы месье асилил хотябы первый том Левашева ему бы в голову не пришло вводить в гугл "детектор нейтрино"  :-))) > даже расскажут про них, какие бывают, где строят > и прочая. Хотя может быть, все эти лохи тоже далеки от > физики и только nagual у нас тут умный. Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну и где практическая польза от вложения ? > Вот только он > упустил слово "почти". Ну тогда допплеровского эффекта - почти нет. Его > относительная величина - мизер. А как же тогда радар у гайцев > работает? А почему в GPS его учитывают? Они еще и теорию > относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться ньютоновской > механикой. А вот ФИГ. Это те радары которые постоянно глючат ? :-))) > Это не баг, это фича. CoW реализует подвид полного журналинга. Поэтому файл > или будет в старом состоянии, или в новом. А что вы > будете делать с полу(пере)записанным файлом? Он все-равно в общем случае неюзабелен. Вспоминается копирование файла в несколько гиг по сети в вин 98 ... копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-))) > Зато выглядит почти как живой. В этом плане btrfs вообще монстр. > Всегда можно отмотать на снапшот. Это настолько простая и легкая операция > что он их на автомате делает. И при сбое просто отматывает > на последний успешный снапшот. И рекавери при сбое быстрое и состояние > файлов  куда предсказуемее чем обычно в классических ФС. В UFS > это малость подлечили побочным методом, но общей тормознутости и архаичности дизайна > этой ФС сие не отменяет. Сколько запорожцу подушки безопасности не ставь, > мерседесом он от этого не станет. Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в продакшен ни ни ...
	Ответить | Правка | К родителю #332 | Наверх | Cообщить модератору

	340. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 22:35
	> Неужели месье за столько лет работы с разными фс так и не > понял что любую фс нельзя забивать выше 70% ? [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/dev/null bs=1048576 1088+1 записей считано 1088+1 записей написано скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_03_\(1920x1080_Blu-ray_FLAC\)_\[115BDB01\].mkv of=/dev/null bs=1048576 1044+1 записей считано 1044+1 записей написано скопировано 1095420279 байт (1,1 GB), 11,2429 c, 97,4 MB/c [root@storage ~]# dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_04_\(1920x1080_Blu-ray_FLAC\)_\[73670FA5\].mkv of=/dev/null bs=1048576 1068+1 записей считано 1068+1 записей написано скопирован 1120538941 байт (1,1 GB), 10,574 c, 106 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 3,41094 c, 315 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t3 bs=1048576 count=1024 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 3,32492 c, 323 MB/c [root@storage ~]# dd if=/dev/zero of=/data/Anime/test.t4 bs=1048576 count=4096 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 16,3468 c, 263 MB/c [root@storage ~]# dd if=/data/Anime/test.t2 bs=1048576 of=/dev/null 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 5,15343 c, 208 MB/c [root@storage ~]# dd if=/data/Anime/test.t3 bs=1048576 of=/dev/null 1024+0 записей считано 1024+0 записей написано скопировано 1073741824 байта (1,1 GB), 5,09285 c, 211 MB/c [root@storage ~]# dd if=/data/Anime/test.t4 bs=1048576 of=/dev/null 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 20,0763 c, 214 MB/c [root@storage ~]# df -h Файловая система      Разм  Исп  Дост  Исп% смонтирована на /dev/mapper/Anime-Anime                       1,3T  1,2T   30G  98% /data/Anime [root@storage ~]# mount /dev/mapper/Anime-Anime on /data/Anime type ext4 (rw,user_xattr) Что я делаю не так? Том забит на 98%, новые файлы пишутся и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом... Все зависит от ворклоада. Ну и да - там, где блочный аллокатор сдохнет, экстентный живет вполне нормально. Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более того. # cat /proc/meminfo MemTotal:        1020596 kB
	Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

	345. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 23:39
	> Что я делаю не так? Том забит на 98%, новые файлы пишутся > и читаются быстрее, чем некоторые старые, "разложенные" торрент-клиентом... > Все зависит от ворклоада. Ну и да - там, где блочный аллокатор > сдохнет, экстентный живет вполне нормально. > Кэш? Ни разу. Вызывает небольшую погрешность измерений при записи, но не более > того. > # cat /proc/meminfo > MemTotal:        1020596 kB Во первых диск ссд а не хдд, во вторых кеширование, в третих интересна только запись. Если у месье все тесты проводятся с такой точностью то наверно не стоит тратить время ...
	Ответить | Правка | К родителю #340 | Наверх | Cообщить модератору

	354. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 23:51
	> Во первых диск ссд а не хдд, во вторых кеширование, в третих Seagate 7200.11, RAID 5 > интересна только запись Дык, она выше есть.
	Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

	357. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 23:55
	> Seagate 7200.11, RAID 5 3 диска в массиве. Параллельно с этого же массива выполняются 7 виртуальных машин, из которых 4 достаточно бодренькие по отношению к диску - MySQL, две площадки LA(M)P, и MaNGOS. Роутерная виртуалка со сквидом не в счёт.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	362. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 00:20
	>скопировано 1141045654 байта (1,1 GB), 0,379371 c, 3,0 GB/c Да нет там кеширования :-)) Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз записано ? :-)) Вот и в современной науке полно ученых с такими навыками тестирования :-))
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	369. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 07:34
	> Да нет там кеширования :-)) "Вызывает небольшую погрешность измерений при записи, но не более того." - не предполагает отсутствия кэша, какбэ. Естественно, кэш есть. <512 Мб свободных на площадке, и 512 Мб в контроллере (общий на всю платформу). Поэтому если при записи 1Гб+ он еще дает какую-никакую погрешность - то при записи 4Гб она уже собственно минимальна. Специально показал скорость кэша в первой же строчке, и во второй - то, что при чтении следующего гигового файла кеш уже не актуален - он меньше гига объёмом. > Это виртуалка ? :-)) Диск 30 гиг ? Файло за 1 раз Виртуалка. ESXi 5.0, VMFS объемом в 1.3 тера, 98% занято.
	Ответить | Правка | К родителю #362 | Наверх | Cообщить модератору

	375. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 08:42
	>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше. Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй яй :-)))
	Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

	378. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 25-Сен-12, 09:17
	>>Ну что ты какой тупой? Это КЭШ, блджад. Специально показал скорость кэша. Смотри дальше. > Модератор опенета вполне может написать статью на тему "Cклонномть к паталогической лжи > как осложнение ЛГМ". :-)) Месье не ожидал что его поймают на > подтасовках? Читатели опенета оказались проницательнее начальства на работе ? Ай яй > яй :-))) Один конкретный читатель оказался настолько туп, что увидев строчку с тестом кеша пустил сопли.
	Ответить | Правка | К родителю #375 | Наверх | Cообщить модератору

	447. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 30-Сен-12, 19:28
	> Во первых диск ссд а не хдд, И что? Ну выпускаются они. Массово. Стало быть с ними надлежит нормально работать.
	Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

	342. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 22:39
	>> Поэтому они оставили архаичный дизайн, примотав к нему >> скотчем и проволокой улучшайзеры. > ext2 ext3 ext4 ... ждем ext5 ? :-)) Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор.
	Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

	349. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok), 24-Сен-12, 23:45
	>>> Поэтому они оставили архаичный дизайн, примотав к нему >>> скотчем и проволокой улучшайзеры. >> ext2 ext3 ext4 ... ждем ext5 ? :-)) > Между ext3 и ext4 - огромная пропасть. Скотч проволка клей и спички ?
	Ответить | Правка | К родителю #342 | Наверх | Cообщить модератору

	466. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 01-Окт-12, 15:21
	> Скотч проволка клей и спички ? Прямо описание процесса разработки UFS. Надо же, к антикварному драндулету приклеили антикрыло. Которое впрочем там нафиг не упало из-за аэродинамики класса "кирпич".
	Ответить | Правка | К родителю #349 | Наверх | Cообщить модератору

	515. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 02-Окт-12, 21:26
	> Скотч проволка клей и спички ? Хоть слезы девственницы, если оно работает и делает это быстро и хорошо.
	Ответить | Правка | К родителю #349 | Наверх | Cообщить модератору

	365. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 00:36
	>>> Поэтому они оставили архаичный дизайн, примотав к нему >>> скотчем и проволокой улучшайзеры. >> ext2 ext3 ext4 ... ждем ext5 ? :-)) > Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. ZFSv29 — RAID-Z/mirror hybrid allocator Это то, о чём вы думаете?
	Ответить | Правка | К родителю #342 | Наверх | Cообщить модератору

	373. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 08:04
	>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. > ZFSv29 — RAID-Z/mirror hybrid allocator > Это то, о чём вы думаете? Иногда лучше читать, прежде чем говорить...
	Ответить | Правка | К родителю #365 | Наверх | Cообщить модератору

	377. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–2 +/–
	Сообщение от nagual (ok), 25-Сен-12, 08:50
	>>> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. >> ZFSv29 — RAID-Z/mirror hybrid allocator >> Это то, о чём вы думаете? > Иногда лучше читать, прежде чем говорить... Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей не читали ...
	Ответить | Правка | К родителю #373 | Наверх | Cообщить модератору

	379. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 25-Сен-12, 09:17
	> Я заметил некоторые каментаторы статей с острыми симтомами ЛГМ этих самых статей > не читали ... И я о том же.
	Ответить | Правка | К родителю #377 | Наверх | Cообщить модератору

	494. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 02-Окт-12, 11:00
	> Между ext3 и ext4 - огромная пропасть. В ext4 запилен экстентный аллокатор. Чтож вы не предупредили что запилено совсем недавно ? http://forum.ubuntu.ru/index.php?topic=80218.0 Это очередная обкатка технологий корпорациями ? Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs которую ждут с концу года https://www.opennet.ru/opennews/art.shtml?num=32974 ЗЫ Вот так некоторые начитаются слоника в домене и строят проекты на нестабильном дистрибутиве, на нестабильной фс ...
	Ответить | Правка | К родителю #342 | Наверх | Cообщить модератору

	497. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 02-Окт-12, 12:42
	А между тем, в продакшне ext4 работает, и работает абсолютно стабильно.
	Ответить | Правка | К родителю #494 | Наверх | Cообщить модератору

	533. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 06-Окт-12, 15:52
	> Оказывается стабильная фс XFS а не ext4 и уж тем более не btrfs Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько. XFS - вообще черт знает когда. Где-то в районе 2.6.28 был прибит последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых багов там вообще особо не чинилось. А EXT4 тогда только-только собирался выйти из -dev еще. И стал реально юзабелен в районе 2.6.32 примерно. И то - пару кондовых но к счастью суперредких багов потом починили. Один баг мог приводить к разрушению ФС, но вероятность на него наступить такова что проще выиграть джек-пот в лотерею, т.к. это происходит только при работе с очень большими файлами (более скольких-то Тб размером).
	Ответить | Правка | К родителю #494 | Наверх | Cообщить модератору

	534. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 06-Окт-12, 18:06
	> Вообще-то, XFS и ext4 официально заявлены стабильными уже фиг знает сколько. Кем заявлено ораклом ? А недавно микрософ заяволо о стабильности вин8 ага ... > XFS- вообще черт знает когда. Где-то в районе 2.6.28 был прибит > последний более-менее чувствительный баг касающихся зануления файлов. С тех пор крутых > багов там вообще особо не чинилось. А EXT4 тогда только-только собирался > выйти из -dev еще. И стал реально юзабелен в районе 2.6.32 > примерно. И то - пару кондовых но к счастью суперредких багов > потом починили. Один баг мог приводить к разрушению ФС, но вероятность > на него наступить такова что проще выиграть джек-пот в лотерею, т.к. > это происходит только при работе с очень большими файлами (более скольких-то > Тб размером). Ну про xfs верим.
	Ответить | Правка | К родителю #533 | Наверх | Cообщить модератору

	393. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 25-Сен-12, 20:02
	>> Только и всего. Насколько близко к этому приблизится реальный аллокатор - >> зависит от его реализации, разумеется. > Ссылка на статью с описанием уже постилась. Что - ссылка? Если вы не можете кратенько, в двух словах изложить что вы имели в виду без отсылок к различным простыням - грош вам цена в базарный день. Это означает что вы сами не поняли что там написано. > Судя по всему получается плохо ... По крайней мере, лучше чем у вас. Во всяком случае, я могу своим мозгом прикинуть что получится и что может получиться при том или ином дизайне ФС. А вы только и умеете что куда-то отсылать. Сами сформулировать мысль вы вообще не в состоянии. > nagual выглядывая в окно - Однако осень. Да уж, школьники и студенты вернулись с каникул, блин. Вы домашку то уже сделали, мсье спорщик? :) > ext2 ext3 ext4 ... ждем ext5 ? :-)) Думаю что таковым станет btrfs. И да, в 4-й версии по крайней мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать с скоростью современных ФС. >> на всего жалких 40Гб за целые сутки непрерывного хрустения. > Неужели месье за столько лет работы с разными фс так и не > понял что любую фс нельзя забивать выше 70% ? Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но лучше так все-таки не делать. Хотя с дефрагером уже и можно пожировать: в случае чего отдефрагать можно. > Товарищ сержант а танки летают ? летают только очень низко ... :-))) Простите, у вас 1 извилина, и та от фуражки? Ну или почему вы не в состоянии вбить в гугль фразу "детектор нейтрино" и узнать много нового о существовании таковых? >> "детектор нейтрино" > Если бы месье асилил хотябы первый том Левашева ему бы в голову > не пришло вводить в гугл "детектор нейтрино"  :-))) А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными фактами. В частности, нейтрино не только детектируют, но и использовали их в ряде экспериментов на БАК. В том числе как раз потому что они очень слабо взаимодействуют с веществом и поэтому без проблем пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами. Мало какая частица протиснется через полпланеты без построения специальных каналов для удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А нейтрино - запросто. Что делает его ценной штукой для посылки в сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в нужную сторону и все, готово. Это же свойство и затрудняет детектирование. Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе детектируется. Просто эффективность детектирования - низкая, поэтому требуется большой детектор для сколь-нибудь заметного результата. >> физики и только nagual у нас тут умный. > Эти лохи раскрутили евросоюз на трилионы евро для постройки коллайдера :-))) Ну > и где практическая польза от вложения ? Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий насчет мира элементарных частиц. Хомякам от этого ничего не будет, по крайней мере немедленно и сейчас. Но в целом знания о том где мы живем и как это устроено - нужны. Должны же мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность? Желание познавать устройство мира - одно из проявлений интеллекта. >> относительности учитывают. Хотя казалось бы, эффекты мизерные и можно отделаться >> ньютоновской механикой. А вот ФИГ. > Это те радары которые постоянно глючат ? :-))) Когда гражданин полицейский заинтересован палку срубить - тогда глючит. А так - эффект есть и работает. Впрочем он намного нагляднее слышен когда проезжающий мимо поезд издает гудок. При этом монотонный звук гудка превращается в очень характерный звук меняющийся по высоте. Удачи оспорить столь вопиющее проявление. > копирует копирует бац сеть глюкнула и опять с самого начала копирует копирует :-))) Крокодил^W нейтрино не ловится, не растет кокос^W^W^W сеть глючит. Как вы живете вообще? :) > Абсолютно с вами сгласен пока fsck лечит ext4 до неузноваемости ... в > продакшен ни ни ... Ну вообще с учетом тенденций указанных выше я не удивлен что у вас ext4 не чинится. И ZFS наверное рассыпется скоро.
	Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

	395. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 20:19
	> По крайней мере, лучше чем у вас. Во всяком случае, я могу > своим мозгом прикинуть что получится и что может получиться при том > или ином дизайне ФС. А вы только и умеете что куда-то > отсылать. Сами сформулировать мысль вы вообще не в состоянии. ВЫ главное результаты своих изысканий никому не показывайте :-)) > Думаю что таковым станет btrfs. И да, в 4-й версии по крайней > мере перешли на экстентный аллокатор, так что оно хотя-бы стало работать > с скоростью современных ФС. А современные это какие если не ufs ext4 b zfs ? Неужно ntfs ? :)))) > Почему-же, мсье в курсе. Правда 70% это довольно пессимистичный порог. На практике > EXT-ы не испытывают особых проблем где-то до 90% забитости диска. Но > лучше так все-таки не делать. Хотя с дефрагером уже и можно > пожировать: в случае чего отдефрагать можно. Учитывая скорость работы мозга особенно у руководства 70% это как раз тот момент когда нужно искать новое хранилище. > Простите, у вас 1 извилина, и та от фуражки? Ну или почему > вы не в состоянии вбить в гугль фразу "детектор нейтрино" и > узнать много нового о существовании таковых? У меня такое впечатление что вы распрямитель рук для головы применили. Не все йогурты одинаково полезны ... > А что, от Левашова настолько тупеют? Извините, я интересуюсь только экспериментально доказанными > фактами. Экспериментально доказано что неуловимый Джо пойман ... :-))) >[оверквотинг удален] > что они очень слабо взаимодействуют с веществом и поэтому без проблем > пролетяют прямо через заметный кусок планеты без особых проблем, потеряв по > пути достаточно небольшой процент частиц. Что делает их достаточно любопытными частицами. > Мало какая частица протиснется через полпланеты без построения специальных каналов для > удержания и предотвращения взаимодействий с веществом (что дорого и проблематично). А > нейтрино - запросто. Что делает его ценной штукой для посылки в > сильно удаленную лабораторию через что попало, т.е. достаточно отправить пучок в > нужную сторону и все, готово. Это же свойство и затрудняет детектирование. > Но "затрудняет" != "делает невозможным". На практике поток нейтрино вполне себе > детектируется. А еще месье до сих пор верит в Деда Мороза. > Просто эффективность детектирования - низкая, поэтому требуется большой > детектор для сколь-нибудь заметного результата. Летают но очень низко ... :-))) > Эти лохи по сути нашли бозон Хиггса, тем самым подтвердив ряд теорий > насчет мира элементарных частиц. Хомякам от этого ничего не будет, по > крайней мере немедленно и сейчас. Но в целом знания о том > где мы живем и как это устроено - нужны. Должны же > мы эволюционировать дальше, не ограничиваясь примитивными инстинктами как остальная живность? > Желание познавать устройство мира - одно из проявлений интеллекта. Месье так же верит что в наперстки можно выиграть ? :-))) Вы случайно все это не по телевизору увидели ? :-)))))
	Ответить | Правка | К родителю #393 | Наверх | Cообщить модератору

	212. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 19:13
	>> Палундра в ZFS нет дефрагментатора %) > Да вон iZEN уже ощущает результат. И даже если он осовободит место, > сильно лучше может и не стать. В общем то нет простого > метода расчистить такое без дефрагментатора. Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433 //--- % dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M 74+1 records in 74+1 records out 1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec) % df /store/video Filesystem     Size    Used   Avail Capacity  Mounted on store/video    790G    789G    1.1G   100%    /store/video ---// Стало: % dd if=/downloads1/Margin\ Call.mkv of=/store/video/Margin\ Call.mkv bs=20M 74+1 records in 74+1 records out 1561257376 bytes transferred in 18.599765 secs (83939630 bytes/sec) % df /store/video Filesystem     Size    Used   Avail Capacity  Mounted on store/video    789G    757G     32G    96%    /store/video И как? Стало лучше, по-твоему? ;) На самом деле тут одна особенность выяснилась. Тормозила не столько запись на RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы).
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 19:36
	>>> Палундра в ZFS нет дефрагментатора %) >> Да вон iZEN уже ощущает результат. И даже если он осовободит место, >> сильно лучше может и не стать. В общем то нет простого >> метода расчистить такое без дефрагментатора. > Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433 > Стало: Косяк. Надо скорость чтения файла, который клался на том под конец его захламливания. Понятно, что если стереть всё с тома и набить одним заходом заново - будет лучше. Но вот тому, что уже набито, от освобождения места лучше не станет.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	223. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 20:14
	>[оверквотинг удален] >>> Да вон iZEN уже ощущает результат. И даже если он осовободит место, >>> сильно лучше может и не стать. В общем то нет простого >>> метода расчистить такое без дефрагментатора. >> Было: https://www.opennet.ru/openforum/vsluhforumID3/86368.html#433 >> Стало: > Косяк. Надо скорость чтения файла, который клался на том под конец его > захламливания. > Понятно, что если стереть всё с тома и набить одним заходом заново > - будет лучше. Но вот тому, что уже набито, от освобождения > места лучше не станет. А оно изначально было "набито" без модификации, на новый чистый пул. Потом шла дозапись данными. Чему там тормозить?!
	Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

	229. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 20:27
	> А оно изначально было "набито" без модификации, на новый чистый пул. Потом > шла дозапись данными. Чему там тормозить?! Ключевое слово - "дозапись". А если там еще и удаления были - вот тут уже всё интереснее. Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома до 99% :)
	Ответить | Правка | К родителю #223 | Наверх | Cообщить модератору

	238. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 20:37
	>> А оно изначально было "набито" без модификации, на новый чистый пул. Потом >> шла дозапись данными. Чему там тормозить?! > Ключевое слово - "дозапись". А если там еще и удаления были - > вот тут уже всё интереснее. > Покажи скорость чтения одного из файлов, заливавшихся непосредственно перед забитием тома > до 99% :) А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при просмотре и ладно. ;) Сейчас: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec)
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	242. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 20:40
	> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при > просмотре и ладно. ;) Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое ставить жутковато.
	Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

	243. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 20:42
	>> А мне хватало — видео Full HD 1080p/MKV 14GB не тормозит при >> просмотре и ладно. ;) > Ну я и говорю - 100/1/1/0. На серверы (кроме долгосрочек CDN) такое > ставить жутковато. Сейчас: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 149.126454 secs (102164071 bytes/sec) Второй раз: % dd if=/store/video/Трон\ \(1982\).mkv of=/dev/null bs=20M 726+1 records in 726+1 records out 15235365714 bytes transferred in 125.197637 secs (121690521 bytes/sec)
	Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

	250. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 21:05
	> 1561257376 bytes transferred in 908.455462 secs (1718584 bytes/sec) Да-да, скорость хуже чем у самой засраной флешки. >  32G    96%    /store/video > И как? Стало лучше, по-твоему? ;) По-моему, если ты возьмешь файл который читался со скоростью 6мб/сек и сотрешь другой файл, то он продолжит читаться со скоростью 6мб/сек. Просто потому что его некому дефрагментировать ;) > диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи > файла, который был предварительно закэширован в ARC ZFS У, блин, так ты еще и читер. Если я закеширую что-нибудь в оперативку - я тебе покажу и гигазы в секунду запросто :)
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	258. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 21:47
	>> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи >> файла, который был предварительно закэширован в ARC ZFS > У, блин, так ты еще и читер. Если я закеширую что-нибудь в > оперативку - я тебе покажу и гигазы в секунду запросто :) Уже не различаешь скорость чистой записи в пул? Так вот, после кэширования файла в ARC и повторной операции записи показана чистая, ничем незамутнённая скорость записи данных на пул. А как ещё её проверить? Расскажи, послушаем, вместе посмеёмся. :))
	Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

	252. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 21:16
	>[оверквотинг удален] > Avail Capacity  Mounted on > store/video    789G    757G     >  32G    96%    /store/video > И как? Стало лучше, по-твоему? ;) > На самом деле тут одна особенность выяснилась. Тормозила не столько запись на > RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 > rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного > диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи > файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два > раза, представлен второй, наилучший результат её работы). А сколько было в самом начале до заполнения на 100% ?
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	259. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 21:50
	>[оверквотинг удален] >> store/video    789G    757G >>  32G    96%    /store/video >> И как? Стало лучше, по-твоему? ;) >> На самом деле тут одна особенность выяснилась. Тормозила не столько запись на >> RAID-Z пул (кстати, состоящий из трёх разделов ноутбучных винчестеров с 5400 >> rpm), сколько чтение с заполненного скачанными файлами пула, состоящего из одного >> диска Western Digital Caviar Blue WD6400AAKS. Последний результат показан для записи >> файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два >> раза, представлен второй, наилучший результат её работы). > А сколько было в самом начале до заполнения на 100% ? Где? На том диске, с которого считывается тестовый файл, или на тому пуле, куда он записывается? Около 2-6 МБ/с. Где-то так. Скорость записи на освобождённый пул уже значительно больше.
	Ответить | Правка | К родителю #252 | Наверх | Cообщить модератору

	264. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 22:53
	>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы). Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал скорость кэша, не более того. Да и для памяти что-то как-то очень хреново.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

	284. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 24-Сен-12, 00:01
	>>>> Последний результат показан для записи файла, который был предварительно закэширован в ARC ZFS (dd выполнялась два раза, представлен второй, наилучший результат её работы). > Бугага, лол. Не заметил сначала эту фразу. ЧИТ. ЭПИК ЧИТ. Ты показал > скорость кэша, не более того. Из кэша памяти на пул записываются данные. Что в этом не так?
	Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

	333. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 21:21
	> Из кэша памяти на пул записываются данные. Что в этом не так? Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд. Если все так, давай тогда считать что у меня скорость записи на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на крайних треках выдает мы умолчим, во :)
	Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору

	337. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 24-Сен-12, 21:56
	>> Из кэша памяти на пул записываются данные. Что в этом не так? > Ну знаешь, у меня DVD-sized iso улетает в кэщ за пару секунд. > Если все так, давай тогда считать что у меня скорость записи > на винч 2Гб/сек, чтоли. А то что винч максимум 150Мб/сек на > крайних треках выдает мы умолчим, во :) Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd — честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая в конце операции, стала бы филькиной грамотой.
	Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

	339. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 22:28
	> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе > 2ГБ/с — вместе посмеёмся. Это только cp(1) так может. dd — > честная утилита и пишет данные синхронно, иначе информация о скорости, выводимая > в конце операции, стала бы филькиной грамотой. Спасибо, повеселил. # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216 68+1 записей считано 68+1 записей написано скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv of=/data/Anime/test.t1 bs=16777216 68+1 записей считано 68+1 записей написано скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c Это скорость операций с диском магически удвоилась, или все-таки ты не прав насчёт кеша? Как считаешь?
	Ответить | Правка | К родителю #337 | Наверх | Cообщить модератору

	363. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 00:29
	>[оверквотинг удален] > 68+1 записей считано > 68+1 записей написано >  скопировано 1141045654 байта (1,1 GB), 9,42692 c, 121 MB/c > # dd if=/data/Anime/Viewed/Macross\ Frontier/TV1/\[Coalgirls\]_Macross_Frontier_02_\(1920x1080_Blu-ray_FLAC\)_\[B0A02588\].mkv > of=/data/Anime/test.t1 bs=16777216 > 68+1 записей считано > 68+1 записей написано >  скопировано 1141045654 байта (1,1 GB), 4,67428 c, 244 MB/c > Это скорость операций с диском магически удвоилась, или все-таки ты не прав > насчёт кеша? Как считаешь? Я считаю, что таким образом ты сравниваешь скорость чтения-записи (суммарно) со скоростью записи (только) из кэша. В первом случае идёт разогревание файлового кэша путём считывания в него данных с диска, а во втором случае кэш уже разогрет и измеряется практически чистая скорость записи данных из оперативной памяти (разогретого файлового кэша) на диск без особых накладных расходов на чтение с механического устройства. Если у меня файл 14 ГБ с одного диска 5400 rpm будет читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который имеет среднюю скорость записи в районе 200 МБ/с, то, как ты думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, потому что данные поступаю на запись с такой скоростью из медленного источника. Источник (медленный механический диск) — это бутылочное горлышко потока байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из оперативной памяти (буфера на запись — в общем случае), а не из какого-то ущербного соска. Я просто измерил чистую скорость записи на RAID-Z, вот и всё.
	Ответить | Правка | К родителю #339 | Наверх | Cообщить модератору

	364. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 00:35
	>[оверквотинг удален] > Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с и одновременно записываться на RAID10, который > имеет среднюю скорость записи в районе 200 МБ/с, то, как ты > думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, > потому что данные поступаю на запись с такой скоростью из медленного > источника. Источник (медленный механический диск) — это бутылочное горлышко потока > байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из > оперативной памяти (буфера на запись — в общем случае), а не > из какого-то ущербного соска. Я просто измерил чистую скорость записи на > RAID-Z, вот и всё. Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png Кстати 4 диска по цене столько же как 3 + контроллер :-)) а из raid0+1 можно вытащить 2 любых диска :-))
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	366. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 01:12
	>[оверквотинг удален] >> имеет среднюю скорость записи в районе 200 МБ/с, то, как ты >> думаешь, какая будет скорость записи? Правильно — не больше 20 МБ/с, >> потому что данные поступаю на запись с такой скоростью из медленного >> источника. Источник (медленный механический диск) — это бутылочное горлышко потока >> байтов. Чистая скорость записи измеряется записью данных на испытуемый носитель из >> оперативной памяти (буфера на запись — в общем случае), а не >> из какого-то ущербного соска. Я просто измерил чистую скорость записи на >> RAID-Z, вот и всё. > Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из > трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E). > а из raid0+1 можно вытащить 2 любых диска :-)) Нет, не любые два, а только из одной страйп-ветви. RAID-6 из четырёх дисков "позволяет" потерять два любых диска.
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

	367. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 01:44
	>[оверквотинг удален] >>> из какого-то ущербного соска. Я просто измерил чистую скорость записи на >>> RAID-Z, вот и всё. >> Ох уж эта осень. :-)) Даже у thg.ru результаты тестирования raid5 из >> трех дисков намного скромнее http://www.thg.ru/storage/raid_scaling_2/images/image005.png > Наверно потому, что для модификации полосы набора данных на аппаратном RAID-5 нужна > дополнительная операция чтения? RAID-Z обходится без этой промежуточной операции. (У меня > RAID-Z сделан на ноутбучных винчестерах Samsung SpinPoint M7E). >> а из raid0+1 можно вытащить 2 любых диска :-)) > Нет, не любые два, а только из одной страйп-ветви. > RAID-6 из четырёх дисков "позволяет" потерять два любых диска. Vmware на диск пишет чествно и здравый смысл не обгоняет. umount -f /dev/da10p1 gpart delete -i 1 da10 gpart destroy da10 gpart create -s gpt /dev/da10 gpart add -t freebsd-ufs -l disk0 da10 newfs -J -O2 -U /dev/da10p1 mkdir -p /mnt/da10p1 mount /dev/da10p1 /mnt/da10p1 touch /mnt/da10p1/test dd if=/dev/random of=/mnt/da10p1/test bs=1M count=2000 df -H |grep da10 da10p1 deleted da10 destroyed da10 created da10p1 added /dev/da10p1: 2048.0MB (4194232 sectors) block size 32768, fragment size 4096         using 4 cylinder groups of 512.00MB, 16384 blks, 65536 inodes.         with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1048768, 2097344, 3145920 /mnt/da10p1: write failed, filesystem is full dd: /mnt/da10p1/test: No space left on device 1983+0 records in 1982+0 records out 2078277632 bytes transferred in 31.129022 secs (66763345 bytes/sec) /dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1 скорость приблизительно одинаковая 66763345 bytes/sec без -J 2078277632 bytes transferred in 30.756519 secs (67571939 bytes/sec) без -S 2078277632 bytes transferred in 30.515984 secs (68104559 bytes/sec) Вобщем в виртуалке результаты тестов сомнительны.
	Ответить | Правка | К родителю #366 | Наверх | Cообщить модератору

	372. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 08:03
	> /dev/da10p1       2.1G    2.1G   -165M   109%    /mnt/da10p1 Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность в *BSD всегда, или надо как-то специфично изголяться?
	Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

	467. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 01-Окт-12, 15:26
	> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность > в *BSD всегда, или надо как-то специфично изголяться? Ух ты, отрицательное свободное место на диске :). Интересно, это как? :)
	Ответить | Правка | К родителю #372 | Наверх | Cообщить модератору

	478. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 02-Окт-12, 00:25
	>> Минус 165 Мб свободного места и 109% утилизации диска? Это такая точность >> в *BSD всегда, или надо как-то специфично изголяться? > Ух ты, отрицательное свободное место на диске :). Интересно, это как? :) Это когда на диск в 6гиг под btrfs пишешь 5.2 и вдруг нет не так ВДРУГ место кончается ... Самое смешьное это когда одно из трех такое ВДРУГ лечится только ребутом :-))) ЗЫ linux сер ...
	Ответить | Правка | К родителю #467 | Наверх | Cообщить модератору

	489. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 02-Окт-12, 07:32
	Ряд утилит с uint под показатель дискового места будут очень рады такому ответу системы (отрицательному значению)...
	Ответить | Правка | К родителю #478 | Наверх | Cообщить модератору

	371. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 08:00
	> а из raid0+1 можно вытащить 2 любых диска :-)) На хабре написали? Удачи в вытаскивании.
	Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

	370. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 07:59
	> Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения - надо очень постараться. Был спор: влияет ли кэш на dd. Ты сказал, что dd - какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл опровержение. К чему все остальное словоблудие - непонятно. Чистая скорость записи на FS без компрессии измеряется просто и быстро: dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero of=/path/test bs/count=четырехкратный объем кеша Результат второго запуска можно считать более-менее достоверным. Ну или просто вторую часть теста - там будет погрешность измерений порядка 10-15%, в зависимости от скорости дисков. # dd if=/dev/zero of=/data/Anime/thrash.t1 bs=1048576 count=2048 ; dd if=/dev/zero of=/data/Anime/test.t2 bs=1048576 count=4096 2048+0 записей считано 2048+0 записей написано скопировано 2147483648 байт (2,1 GB), 8,92 c, 241 MB/c 4096+0 записей считано 4096+0 записей написано скопировано 4294967296 байт (4,3 GB), 17,8542 c, 241 MB/c
	Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

	376. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 08:45
	> Если у меня файл 14 ГБ с одного диска 5400 rpm будет > читаться со скоростью 10-20 МБ/с Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе.
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	490. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 02-Окт-12, 07:33
	>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет >> читаться со скоростью 10-20 МБ/с > Под freebsd на UFS не воспроизводится ... Наверно проблема в линуксе. У него FreeBSD, детка.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

	381. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 12:44
	>> Если у меня файл 14 ГБ с одного диска 5400 rpm будет >> читаться со скоростью 10-20 МБ/с > То пора выкинуть диск или раздел - чтобы достигнуть такой скорости чтения > - надо очень постараться. "Очень постараться" — это иметь дедупликацию ZFS на заполненном пуле. ;) > Был спор: влияет ли кэш на dd. Ты сказал, что dd - > какая-то "мегасинхронная" утилита, на которую кеш не влияет. Я тебе привёл > опровержение. К чему все остальное словоблудие - непонятно. Я не говорил, что кэш не влияет на dd(1). Я показал, какую роль играет неразогретый и разогретый кэш при чтении-записи файла с помощью dd(1) с диска на диск (обмен данными между пулами). > Чистая скорость записи на FS без компрессии измеряется просто и быстро: > dd if=/dev/zero of=/path/thrashcache bs/count=двукратный объем кеша ; dd if=/dev/zero > of=/path/test bs/count=четырехкратный объем кеша Пишется на один диск WD: % dd if=/dev/zero of=/downloads1/test0.img bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec) % dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10 10+0 records in 10+0 records out 1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec) % dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50 50+0 records in 50+0 records out 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) % dd if=/dev/zero of=/downloads1/test2000.img bs=2000M count=5 5+0 records in 5+0 records out 10485760000 bytes transferred in 913.458192 secs (11479190 bytes/sec)
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	382. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 12:54
	>[оверквотинг удален] > 10+0 records out > 1048576000 bytes transferred in 23.079325 secs (45433564 bytes/sec) > % dd if=/dev/zero of=/downloads1/test00.img bs=100M count=10 > 10+0 records in > 10+0 records out > 1048576000 bytes transferred in 23.802206 secs (44053732 bytes/sec) > % dd if=/dev/zero of=/downloads1/test000.img bs=100M count=50 > 50+0 records in > 50+0 records out > 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) А представьте нам скрипт тестирования в полном виде, не для праздного интереса а чтоб мы могли повторить эксперимент и чтоб у нас небыло оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании фс. ;-)
	Ответить | Правка | К родителю #381 | Наверх | Cообщить модератору

	383. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 13:13
	> А представьте нам скрипт тестирования в полном виде, не для праздного интереса > а чтоб мы могли повторить эксперимент и чтоб у нас небыло > оснований обвинять вас в мошенничестве. Начиная с разметки диска и создании > фс. ;-) Сейчас всё брошу и буду скрипт писать для вас.
	Ответить | Правка | К родителю #382 | Наверх | Cообщить модератору

	384. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 13:31
	Месье учил нас пользоваться гуглем, ну чтож: zfs core dump Результатов: примерно 33 900 (0,15 сек.) ой btrfs core dump Результатов: примерно 91 600 (0,12 сек.) ОО ufs2 core dump Результатов: примерно 19 100 (0,12 сек.) ээх ext4 core dump Результатов: примерно 142 000 (0,10 сек.) аяяйяй ext3 core dump Результатов: примерно 477 000 (0,37 сек.) вау ext2 core dump Результатов: примерно 212 000 (0,16 сек.) не зря не зря его пилили ... UFS core dump Результатов: примерно 434 000 (0,28 сек.) сумма за все годы ? xfs core dump Результатов: примерно 195 000 (0,45 сек.) если суммировать ext2-ext4 да еще это добавить :-)) ntfs failed Результатов: примерно 3 260 000 (0,11 сек.) лидер во всем :-)) raid failure Результатов: примерно 48 900 000 (0,28 сек.) hdd failure Результатов: примерно 13 700 000 (0,30 сек.) за все время ssd failure Результатов: примерно 6 690 000 (0,18 сек.) догоним и перегоним ? lvm failed Результатов: примерно 1 020 000 (0,24 сек.) lol geom failed Результатов: примерно 375 000 (0,26 сек.) да уж ... Поиск сила :-)))
	Ответить | Правка | К родителю #383 | Наверх | Cообщить модератору

	386. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 25-Сен-12, 17:06
	Ну да. У неуловимых Джо кейсов, естественно, близко к 0 - ибо никто не юзает и не собирается. ext4 in production Результатов: примерно 2 240 000 (0,45 сек.) ext3 in production Результатов: примерно 3 570 000 (0,43 сек.) ufs in production Результатов: примерно 871 000 (0,34 сек.) упс. zfs in production Результатов: примерно 536 000 (0,37 сек.) ой? :) raid in production Результатов: примерно 60 400 000 (0,33 сек.) argh!
	Ответить | Правка | К родителю #384 | Наверх | Cообщить модератору

	448. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 30-Сен-12, 19:31
	> Поиск сила :-))) Неандерталец открыл для себя микроволновку :)
	Ответить | Правка | К родителю #384 | Наверх | Cообщить модератору

	385. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 25-Сен-12, 17:05
	> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) 26Mb/sec Страшно фрагментированный том, видимо.
	Ответить | Правка | К родителю #381 | Наверх | Cообщить модератору

	387. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 25-Сен-12, 18:26
	>> 5242880000 bytes transferred in 200.131803 secs (26197136 bytes/sec) > 26Mb/sec > Страшно фрагментированный том, видимо. Да нет. Просто на нём свободного места около 12 ГБ.
	Ответить | Правка | К родителю #385 | Наверх | Cообщить модератору

	392. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 19:09
	Итак давайте обсудим оптимальные для тестов  bs и count :-))
	Ответить | Правка | К родителю #387 | Наверх | Cообщить модератору

	399. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 22:11
	> Да нет. Просто на нём свободного места около 12 ГБ. Скорость записи не зависит от количества свободного места. А вот от его фрагментированности - запросто.
	Ответить | Правка | К родителю #387 | Наверх | Cообщить модератору

	394. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 25-Сен-12, 20:03
	> Давай воспроизведи с помощью dd(1) скорость копирования данных на DVD в районе > 2ГБ/с — вместе посмеёмся. Да вон тебе перец показал уже скорость в 3Гб/сек. Тебе мало? :)
	Ответить | Правка | К родителю #337 | Наверх | Cообщить модератору

	137. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 22-Сен-12, 23:36
	> у btrfs есть встроенный дефраг. В ZFS такого не было, да. > Почему? Наверное потому что это одна из первых CoW ФС. Наверно потому что в продажу пошли первые SSD диски. Это отлично что вы рассказали нам про встроенный в бтрфс дефрагментатор. Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы ... В этом плане ZFS с ее COW и SSD друзья а так как ZFS позицианируется под BD то урреждающее чтение или дефрагментация там и нафиг ненужны.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	147. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 09:55
	>>> В этом плане ZFS с ее COW и SSD друзья Снова садись, снова два. Без TRIM они не то, что не друзья, а вообще не совместимы генетически.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 11:13
	>>>> В этом плане ZFS с ее COW и SSD друзья > Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам что вы понимаете под TRIM а то мало ли вдруг и тут что то левое :-))
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 11:23
	> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам > что вы понимаете под TRIM а то мало ли вдруг и > тут что то левое :-)) Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, когда они освобождаются в ФС. Зачем это надо? Затем, что внутри флешки есть механизм веарлевелинга (по сути тот же CoW), который использует под новые данные незанятые блоки. Но вот - увы и ах - флешка ничего не знает про файловую систему. Чтобы сказать ей, что блок свободен - нужен TRIM. И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке не останется ничего другого, кроме как использовать под веарлевелинг при любой записи небольшой "временный набор" - резерв пространства как раз для этих целей. По мере заполнения "надлежащей" файловой системы запись все чаще и чаще будет перезаписью, и срок работы флешки сократится в разы. Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, только запись новых данных. Таким образом производительность без TRIM тоже под вопросом.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	166. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 11:33
	> По мере заполнения "надлежащей" файловой системы запись все чаще и > чаще будет перезаписью Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет адресовать места больше чем на диске :))) тоесть когда ZFS забьет все свбодное место она сама начнет перезаписывать самые старые неактуальные записи :-))) а писать в резервную область для ZFS принципиально невозможно потому что туда нет прямой адресации. Месье должен четко понимать что SSD диски портятся от перезаписи а не от гранения станых неактуальных блоков. >и срок работы флешки сократится в разы. С точностью до наоборот. > Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - > флешка выполняет копирование блока с изменением нужного куска. Блок SSD и блок ZFS должны совпадать. > Если во внутреннем > блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, > только запись новых данных. Таким образом производительность без TRIM тоже под > вопросом. Смотреть выше.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	171. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от AlexAT (ok), 23-Сен-12, 12:08
	> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет Перечитай написанное мной еще раз - ты ниасилил...
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	191. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 16:56
	>> Боюсь это принципиально невозможно :))) потому что ZFS в принципе не сможет > Перечитай написанное мной еще раз - ты ниасилил... Зачем читать я на память помню :-) спецально для месье неасилившего мой предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных блоков перекладывается с контроллера ssd на zfs что при совпадении размера блока должно дать некоторый прирост производительности, так как контроллеру небудет необходипости считывать и сравнивать блок перед перезаписью.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	203. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 18:35
	> Зачем читать я на память помню :-) спецально для месье неасилившего мой Чукча не читатель? > предыдущий пост в случае с ZFS и SSD выбор наиболее неактуальных > блоков перекладывается с контроллера ssd на zfs что при совпадении размера Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести он себя будет вполне обычным образом - используя под веаринг резерв.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	230. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 20:28
	> Ага, вот только контроллеру SSD совершенно неведомо, что там ZFS, и вести > он себя будет вполне обычным образом - используя под веаринг резерв. Как же туго с логикой. Вот если на SSD все блоки уже заняты и идет запись занятого блока SSD сделает запись в запасной или с тот который уже занят ?
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	233. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 20:33
	> Как же туго с логикой. Вот если на SSD все блоки уже > заняты и идет запись занятого блока SSD сделает запись в запасной > или с тот который уже занят ? В свободный. Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". Бывает ситуация "все блоки заполнены, включая резервные, но часть подлежит стиранию". В последней ситуации в довесок еще и GC запустится, и вот тут производительности настанет самый что ни на есть пушной зверёк.
	Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

	262. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 22:27
	>> Как же туго с логикой. Вот если на SSD все блоки уже >> заняты и идет запись занятого блока SSD сделает запись в запасной >> или с тот который уже занят ? > В свободный. Как же туго с логикой 2. > Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". LOL > Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". Если ОС может адресовать только видимые ей то как могут быть заполнены резервные ? :-)) > В последней ситуации в довесок еще и GC запустится, и вот тут > производительности настанет самый что ни на есть пушной зверёк. Ну хоть один реальный тест это подтверждающий.
	Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

	273. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 23:28
	> Как же туго с логикой 2. >> Предвосхищая вопрос: на SSD не бывает ситуации "все блоки заняты". > LOL Да, LOL. Полнейшее, лютое, вопиющее незнание логики работы накопителей на флеше детектед. Сюда хоть загляни, что-ли, для начального ликбеза: http://en.wikipedia.org/wiki/Write_amplification >> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". > Если ОС может адресовать только видимые ей то как могут быть заполнены > резервные ? :-)) ОС не имеет отношения к тому, что происходит непосредственно на флеше. Она пинает контроллер, не более. И совершенно не в курсе внутренней структуры флеша. >> В последней ситуации в довесок еще и GC запустится, и вот тут >> производительности настанет самый что ни на есть пушной зверёк. > Ну хоть один реальный тест это подтверждающий. http://www.xbitlabs.com/articles/storage/display/kigston-hyp...
	Ответить | Правка | К родителю #262 | Наверх | Cообщить модератору

	279. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 23:36
	>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". >> Если ОС может адресовать только видимые ей то как могут быть заполнены >> резервные ? :-)) Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло - оно фоновое, только по событию GC.
	Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

	283. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 00:00
	>>>> Бывает ситуация  "все блоки заполнены, включая резервные, но часть подлежит стиранию". >>> Если ОС может адресовать только видимые ей то как могут быть заполнены >>> резервные ? :-)) > Элементарно, Ватсон. Левелер их уже заюзал, а стирания еще не произошло - > оно фоновое, только по событию GC. И что device timeout ? Бред.
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	286. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 00:07
	> И что device timeout ? Бред. При чем тут device timeout? Нет, всего лишь задержка в несколько МС на стирание. Заметная, но не фатальная.
	Ответить | Правка | К родителю #283 | Наверх | Cообщить модератору

	334. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 21:24
	> При чем тут device timeout? Нет, всего лишь задержка в несколько МС > на стирание. Заметная, но не фатальная. Пипец, хардкорные разработчики бсды должны сгореть со стыдухи за своих "коллег". С такими друзьями никаких врагов не надо.
	Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

	251. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 21:05
	> Перечитай написанное мной еще раз - ты ниасилил... Он вообще какой-то деревянный. Еще один изен прямо.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	169. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 11:45
	>> Месье неасилил смысл COW ? Печально ... В таком случае поведайте нам >> что вы понимаете под TRIM а то мало ли вдруг и >> тут что то левое :-)) > Бугага. TRIM нужен для того, чтобы флешка помечала свои блоки, как свободные, > когда они освобождаются в ФС. Зачем это надо? Затем, что внутри > флешки есть механизм веарлевелинга (по сути тот же CoW), который использует > под новые данные незанятые блоки. Но вот - увы и ах > - флешка ничего не знает про файловую систему. Чтобы сказать ей, > что блок свободен - нужен TRIM. Ой, а что же будет, если размер блока ФС случайно или по незнанию пользователя совпадает с размером блока SSD или в целое число раз больше размера блока SSD? > И поэтому, когда все рабочие блоки данных флешки окажутся забитыми (а с > CoW "сверху" без TRIM они окажутся забитыми очень быстро) - флешке > не останется ничего другого, кроме как использовать под веарлевелинг при любой > записи небольшой "временный набор" - резерв пространства как раз для этих > целей. По мере заполнения "надлежащей" файловой системы запись все чаще и > чаще будет перезаписью, и срок работы флешки сократится в разы. В Wiki про TRIM написано, что "Так как очистка ячеек в странице необходима перед тем, как в них можно будет записывать снова, но только целый блок может быть очищен, процесс перезаписи инициирует цикл чтение-очистка-модификация-запись: содержимое целого блока должно быть сохранено в кеше перед тем, как оно может быть удалено с накопителя, перезаписываемые данные модифицируются в кеше и только после этого целый блок (с обновленной страницей) записывается на накопитель. Это явление известно как усиление записи.". Никакого "резерва пространства" в SSD нет. > Но это еще не всё. Когда нужно перезаписать кусочек внутреннего блока - > флешка выполняет копирование блока с изменением нужного куска. Если во внутреннем > блоке всё, кроме перезаписываемого куска, было сTRIM'ано - копирования не будет, > только запись новых данных. Таким образом производительность без TRIM тоже под > вопросом. В кэш SSD помещаются данные из целого блока (SSD), так что применимость или не применимость TRIM тут никакой роли не играет — "усиление записи" для используемых страниц (так как в традиционных ФС размер блока много меньше размера блока SSD, то они будут) всё равно произойдёт.
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	173. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 12:13
	> Ой, а что же будет, если размер блока ФС случайно или по > незнанию пользователя совпадает с размером блока SSD или в целое число > раз больше размера блока SSD? Ничего не будет. Флешка как не знала о том, что блок логически высвобожден, так и не узнает. И не будет использовать данный блок для левелинга. > В Wiki про TRIM написано, что "Так как очистка ячеек в странице На заборе тоже много чего написано. Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, до того, как он понадобится системе. Стирание - не ахти какая быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно ниже традиционок - эти FS не очищают блоки, и каждая перезапись на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает ли это BTRFS - не знаю. > В кэш SSD помещаются данные из целого блока (SSD), так что применимость > или не применимость TRIM тут никакой роли не играет Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	179. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от iZEN (ok), 23-Сен-12, 12:33
	>> Ой, а что же будет, если размер блока ФС случайно или по >> незнанию пользователя совпадает с размером блока SSD или в целое число >> раз больше размера блока SSD? > Ничего не будет. Флешка как не знала о том, что блок логически > высвобожден, так и не узнает. И не будет использовать данный блок > для левелинга. Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой CoW ФС. >> В Wiki про TRIM написано, что "Так как очистка ячеек в странице > На заборе тоже много чего написано. Так сотри и напиши правильно. Кто мешает? > Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, > до того, как он понадобится системе. Стирание - не ахти какая > быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно > ниже традиционок - эти FS не очищают блоки, и каждая перезапись > на них будет инициировать стирание. Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков совпадают) страниц блока SSD, новые данные будут записываться после обнуления предыдущего содержимого. А в традиционных ФС вместо предварительного стирания страниц (они уже ранее обнулены GC после команды TRIM) будет происходить "усиление записи" немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD), что равносильно искусственному изнашиванию ячеек флэш-памяти. Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт дополнительной операции по обнулению блока SSD. За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц под блок ФС было выполнено на аппаратном уровне после команды TRIM, однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший по размеру блок ФС, приводит к износу ячеек памяти. >> В кэш SSD помещаются данные из целого блока (SSD), так что применимость >> или не применимость TRIM тут никакой роли не играет > Хотелось бы пруфлинк на спецификацию записи конкретным контроллером с обоснованием сказанного. Wiki/TRIM
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	208. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 18:45
	> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой > CoW ФС. Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь там контроллера. Но проблема не в том. Проблема в том что контроллер - есть. И он не знает какие блоки используются. Поэтому вынужден очищать блоки только когда туда пытаются писать по факту. А не заранее. И вот это является очень неоптимальным режимом работы. И места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать операции записи, и запись медленнее происходит. > Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков > совпадают) страниц блока SSD, И вот это - плохо. Потому что операция стирания - медленная и деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и деструктивнее чем конкуренты из-за неподдержки TRIM. > новые данные будут записываться после обнуления предыдущего содержимого. > А в традиционных ФС вместо предварительного стирания страниц (они уже > ранее обнулены GC после команды TRIM) будет происходить "усиление записи" Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с поддержкой trim запись будет просто записью страниц без нужды что-то там стирать и перетрясать. > немодифицированных страниц (так как размер блока ФС намного меньше размера блока SSD), > что равносильно искусственному изнашиванию ячеек флэш-памяти. "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав контроллер SSD в наихучший режим работы из всех возможных. По поводу чего оно будет тормознее работать и сильнее протирать флеш. Erase как раз весьма деструктивная операция. А т.к. пространства для маневра у GC контроллера будет минимум, erase будет делаться постоянно, по поводу и без. > Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных > (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт > дополнительной операции по обнулению блока SSD. Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки. А у btrfs вполне себе реализован trim. Вот в таком виде подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера SSD не мешает. > За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц > под блок ФС было выполнено на аппаратном уровне после команды TRIM, На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок. > однако "усиление записи" немодифицированных страниц в блоке SSD, куда записывается меньший > по размеру блок ФС, приводит к износу ячеек памяти. Больше всего изнашивает память erase как раз. Да еще для довольно большого региона сразу, в отличие от записей страниц. > Wiki/TRIM Там нет спецификаций касающихся логики работы конкретных контроллеров.
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	209. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 18:50
	> И вот это - плохо. Потому что операция стирания - медленная и > деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и > деструктивнее чем конкуренты из-за неподдержки TRIM. > "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав > контроллер SSD в наихучший режим работы из всех возможных. По поводу > чего оно будет тормознее работать и сильнее протирать флеш. Erase как > раз весьма деструктивная операция. А т.к. пространства для маневра у GC > контроллера будет минимум, erase будет делаться постоянно, по поводу и без. Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще приходится делать ERASE - тем хуже флешу.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	335. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 21:32
	> Абсолютно согласен. Чем меньше пространства у левелера под маневры, и чем чаще > приходится делать ERASE - тем хуже флешу. Я не понимаю почему они в такое не въезжают. Тупые какие-то - не могут массивы блоков представить и что произойдет в такой или эдакой ситуации.
	Ответить | Правка | К родителю #209 | Наверх | Cообщить модератору

	222. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 23-Сен-12, 20:05
	>> Для CoW аппаратный левелинг неактуален — он делается на программном уровне самой >> CoW ФС. > Ага, щаззз. Ну то-есть оно бы может и размазывало записи, не будь > там контроллера. Но проблема не в том. Проблема в том что > контроллер - есть. И он не знает какие блоки используются. Поэтому > вынужден очищать блоки только когда туда пытаются писать по факту. А > не заранее. И вот это является очень неоптимальным режимом работы. Откуда ты знаешь? Без TRIM контроллер не запускает механизм очистки, а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди обнуления/записи контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру блока SSD). > И > места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать > операции записи, и запись медленнее происходит. Вывод из посылки, которая не верна. >> Согласен. Каждая запись в ZFS будет инициировать стирание всех (если размеры блоков >> совпадают) страниц блока SSD, > И вот это - плохо. Потому что операция стирания - медленная и > деструктивная. Так и запишем: ZFS при прочих равных будет медленнее и > деструктивнее чем конкуренты из-за неподдержки TRIM. Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, но из-за малого размера блока ФС, содержимое блока SSD каждый раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, но так же И делается "усиление записи" для всех остальных страниц блока SSD, не участвующие в хранении данных записываемого блока ФС. Контроллер SSD записывает данные на флэш только поблочно, при этом используется оперативный кэш для заполнения вновь затребованных страниц и освежения немодифицируемых страниц. Это способствует большему износу ячеек памяти, чем если бы блок ФС совпадал с размером блока SSD. Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Ресурс флэш тратиться на освежение, которого можно избежать в принципе — сделать размер блока ФС равным размеру блока SSD. >> новые данные будут записываться после обнуления предыдущего содержимого. >> А в традиционных ФС вместо предварительного стирания страниц (они уже >> ранее обнулены GC после команды TRIM) будет происходить "усиление записи" > Что есть "усиление записи"? Выражайся пожалуйста общепринятыми терминами. В любой ФС с > поддержкой trim запись будет просто записью страниц без нужды что-то там > стирать и перетрясать. Контроллер SSD по команде ФС записывает данные на флэш только поблочно, при этом имеются в виду не блоки ФС (хотя и они тоже в этом процессе участвуют), а более объёмная по отношению к ФС величина — блок SSD, имеющий размер 512 килобайт. Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть очищенные страницы в блоке, то их не нужно предварительно обнулять (это сделал GC после команды TRIM), скорость записи на них высока. Однако в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает данные на флэш только целым блоком из оперативного кэша. Это называется "усилением записи". > "Преимущество" ZFS в том что она поставит р@ком логику размазывания записи, загнав > контроллер SSD в наихучший режим работы из всех возможных. Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как не тайна за семью печатями. > По поводу > чего оно будет тормознее работать и сильнее протирать флеш. Erase как > раз весьма деструктивная операция. А т.к. пространства для маневра у GC > контроллера будет минимум, erase будет делаться постоянно, по поводу и без. GC работает с отдельными страницами. И тут никак не влияет на скорость поблочной (пере)записи данных, так как за один раз стирается и модифицируется весь блок SSD — мы говорим для условия, когда размеры блоков ФС и SSD совпадают. Когда же размеры блоков ФС и SSD не совпадают, то тут начинается интересная штука: при интенсивных операциях записи-стирания данных GC может и не успеть обнулить помеченные TRIM страницы, поэтому новая запись в них будет происходить с ПРЕДВАРИТЕЛЬНЫМ обнулением содержимого непосредственно перед модификацией. И мы тут сильно потеряем в скорости записи на мелких блоках ФС, так как будет постоянная перезагрузка оперативного кэша SSD для модификации его блоков. В случае с совпадением размеров блоков операция очистки производится для всего блока SSD сразу, данные записываются большими порциями — нет оверхеда на подчистку отдельных страниц. >> Таким образом за ZFS преимущество в том, что нет "усиления записи" отдельных >> (немодифицированных) страниц блока SSD, но теряется скорость записи данных за счёт >> дополнительной операции по обнулению блока SSD. > Таким образом, у ZFS вообще нет преимуществ на SSD и есть недостатки. > А у btrfs вполне себе реализован trim. Вот в таком виде > подобная ФС уже прилично накладывается на логику флеша и GC'у контроллера > SSD не мешает. Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. ;) Выяснится, что GC может и не успевает за подчистками. Заодно и проверить ресурс флэшатины под обеими ФС. ;) >> За традиционными ФС преимущество в скорости записи, так как обнуление отдельных страниц >> под блок ФС было выполнено на аппаратном уровне после команды TRIM, > На фирмварном. Это сложная операция, при которой GC собирает все используемые страницы > блока, группирует их, сохраняет нужные куда-то еще и наконец стирает блок. Ты действительно веришь, что GC после своей работы с блоком разделяет блок на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки SSD и складирует их куда-то? Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;)
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	225. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 20:24
	> контроллеру не нужно. Запись ФС будет происходить без задержек кроме той, > что нужна на полную очистку блока (принимаем, что размер блока ФС О боже. В этом и проблема. Очистка блока по меркам CPU/шины - операция длиною в вечность. Ее лучше делать в фоне, не заставляя шину ждать. А писать в свободные блоки левелера. Я тебе секрет открою, так и быть - современный контроллер всё равно не будет стирать целевой блок, запишет в свободный блок "резерва". Поэтому даже потерю производительности заметишь не всегда. Но вот блоков этих мало, и веаринг драйва в итоге будет неоптимальным. Совсем-совсем. > Контроллер SSD записывает данные на флэш только поблочно Бред. Поблочно производится только очистка. Запись может идти постранично. > Контроллер SSD по команде ФС записывает данные на флэш только поблочно Чушь. См. выше. > величина — блок SSD, имеющий размер 512 килобайт. На практике - от 64Кб до 2Мб в зависимости от организации флеша. Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем. > Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть Еще раз: никакой модификации данных не происходит. Данные пишутся в один из "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание. > Но они тоже будут перезаписаны (освежены), так как контроллер SSD записывает Это происходит только в моменты работы GC. > Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как > не тайна за семью печатями. Это делает сам контроллер. Все попытки навязать ему сверху какое-либо распределение приведут только к быстрому занятию всех активных блоков рабочего набора. А без TRIM - еще и к тому, что контроллер будет вынужден всегда веарить за счёт резерва. > для модификации его блоков. В случае с совпадением размеров блоков операция > очистки производится для всего блока SSD сразу, данные записываются большими порциями > — нет оверхеда на подчистку отдельных страниц. Только в случае, если есть полностью свободный блок. А учитывая, что TRIM у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, и на каждую запись будем получать ERASE. Малый размер блока даже несколько более выгоден в случае SSD, поскольку позволяет не делать ERASE на запись 1 байта, если в наличии есть свободная страница. В идеале блок должен быть именно размером со страницу, чтобы не выполнять копирования, и не стирать целые блоки при записи мелких файлов. > Ты действительно веришь, что GC после своей работы с блоком разделяет блок > на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки > SSD и складирует их куда-то? Именно так он и работает. Читай публикации по веарлевелингу флешей. Работа GC чем-то сходна с классическими дефрагментаторами. Для перекомпоновки, к слову, достаточно всего лишь одного резервного блока. Но левелинг при этом будет никакой, естественно, поэтому на "резерв" реально берется обычно 5-10% от объёма флеша.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	300. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 06:39
	> и веаринг драйва в итоге будет неоптимальным. Совсем-совсем. ... > Бред. Поблочно производится только очистка. Запись может идти постранично. Два чая этому гражданину. >> величина — блок SSD, имеющий размер 512 килобайт. > На практике - от 64Кб до 2Мб в зависимости от организации флеша. Ну это же изен. Я думаю что даташиты на микросхемы флеша он вообще никогда не читал. > Встречаются варианты и с <64Кб, но сомневаюсь, что идут в "бытовую" > продажу в виде SSD. В основном это встроенные флеши на разных мобилках и прочем. Собственно 512Кб достаточно типовой размер нынче. Но в целом это на усмотрение производителя чипов, так что чего ради изен к 512К привязался... как будто он еще и выровнять сможет на границу блока :) > "резервных" блоков постранично, на чистые страницы. Если чистой страницы на данный > момент нет - запускается GC левелера, превращая всю операцию в томительное ожидание. Ну вот это и будет модификацией. Только от этого SSD пытается уйти но без TRIM не особо получится. > только к быстрому занятию всех активных блоков рабочего набора. А без > TRIM - еще и к тому, что контроллер будет вынужден всегда > веарить за счёт резерва. А до изена это не доходит. Он видимо все-таки прочел как работает флеш память, но garbage collector + размазка записей кажется уже за пределами его понимания. > Только в случае, если есть полностью свободный блок. А учитывая, что TRIM > у нас нет, и пишем, как попало - скорее всего полностью свободных блоков не будет, > и на каждую запись будем получать ERASE. Вот именно. А изен почему-то этого не понимает. Ха-ха. > Малый размер блока даже несколько более выгоден в случае SSD, поскольку > позволяет не делать ERASE на запись 1 байта, если в наличии > есть свободная страница. Без trim чревато тем что постепенно все зафрагментируется и свалится в режим когда для записи 1 байта надо тереть erase block. А с trim - ну да, вполне нормально будет. > В идеале блок должен быть именно размером со страницу, ...и совпадать с ее границами :) > Именно так он и работает. Читай публикации по веарлевелингу флешей. Да это ж изен, для него нормально бред нести. Хотя как ни странно он начинает немного понимать как флеш работает в плане устройства по блокам. Глядишь, лет через 10 начнет понимать и работу wear leveling :)
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

	297. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+1 +/–
	Сообщение от Аноним (-), 24-Сен-12, 06:15
	> Откуда ты знаешь? Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. Ну вот такое у меня хобби есть. Это как раз примерно то самое что в SSD нынче суют. > Без TRIM контроллер не запускает механизм очистки, Спасибо, Кэп. > а значит нет вынужденной диспетчеризации потоков команд на запись данных от ФС > и внутреннего процесса очистки. То есть тормозить и диспетчировать очереди > обнуления/записи контроллеру не нужно. Ты такой умный что пипец. Правда при всем этом ты не знаешь что то что именно сделает контроллер по поводу TRIM - вообще не специфицировано. То-есть, это всего лишь хинт контроллеру что мы не юзаем данные блоки и их можно разгрести. Когда именно и как контроллер это изволит разгрести и что он сделает по этому поводу - вообще его дело. Он может например подождать минимальной нагрузки на накопитель в фоне разрулить. > Запись ФС будет происходить без задержек кроме той, > что нужна на полную очистку блока (принимаем, что размер блока ФС == размеру > блока SSD). Опух? Erase block флеша как правило нынче 512Кб и поди еще попробуй угадать границы оного, да еще с блоками переменного размера которыми ты тут так понтуешься. И кстати erase - это весьма длительная операция. Если программирование страницы может быть довольно быстрой процедурой (и то не всегда), то erase блока запросто растягиватеся на многие миллисекунды. Максимальное время обычно указано в даташите на микросхемы флеша. >> места для маневра так что флеш быстрее затирается из-за невозможности оптимизировать >> операции записи, и запись медленнее происходит. > Вывод из посылки, которая не верна. Вполне себе верна. Чем больше пространства для маневра - тем реже приходится судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. Собственно грубый прототип того что получается ты и так увидел на забитом под завязку томе. А тут похожая логика: размазывание записи - по сути вариант CoW получается. Ну и общие свойства стало быть похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его не видно в емкости накопителя которая написана на упаковке, а вот место в чипах памяти оно жрет. Производителю не нравится напаивать больше памяти при том что цифра на упаковке не увеличивается. Ведь хомячки покупают гигабайты :) > Почему она медленнее, если для традиционных ФС с поддержкой TRIM стирание тоже выполняется, В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. Тогда стирания не будет, только программирование страниц. И чем больше места не занято - тем больше пространства для маневра: может получиться воткнуть желаемую запись куда-то в уже очищенные страницы. А если trim нет то постепенно все придет к схеме когда "проблема решается по мере возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а что нет. По поводу чего и скорость записи просядет, и возможности оптимизации размещения записей у контроллера будут откушены по полной программе. Хинт: если бы все было так как ты говоришь, никто не стал бы геморроиться с реализацией команды TRIM от которой и так нет эффекта. По-моему, это даже детсадовцу понятно? :) > но из-за малого размера блока ФС, содержимое блока SSD каждый > раз помещается в кэш SSD, делается запись в заранее обнуленные страницы, > но так же И делается "усиление записи" для всех остальных страниц > блока SSD, не участвующие в хранении данных записываемого блока ФС. Еще раз: что такое "усиление записи"? Нельзя ли выражаться общепризнанными терминами? Ну там read, erase, page programming, ... ? > Контроллер SSD записывает данные на флэш только поблочно, В общем случае - постранично. У флеша 2 вида блоков. > способствует большему износу ячеек памяти, чем если бы блок ФС совпадал > с размером блока SSD. Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - часто будет тереться ДВА блока там где хватило бы одного. Ну а с блоками переменного размера ты еще и никогда не сможешь выровнять ФС так чтобы ее блоки совпали с блоками флеша. Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. В случае с TRIM это не такая уж проблема, т.к. erase не будет и будет только программирование страниц по количеству записываемого. А вот без него логика контроллера свалится в черти-какой штопор. Грубый прикидон мне подсказывает что экстенты + trim будут работать не в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы и по объему желаемой записи и ... все :). Юзание TRIM порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий вообще каждый раз. > Частая перезагрузка оперативного кэша контроллера SSD из-за малого размера блока традиционных > ФС приводит к частому "освежению" немодифицированных страниц и уменьшается ресурс ячеек. Ресурс ячеек прежде всего уменьшается от ERASE'а блоков на каждый пук. А если пространства для маневрирования и удовлетворения текущего запроса нет - поневоле придется дергаться и тереть блоки на каждый пук. Правда просто? > TRIM тут никаким боком не поможет, кроме как увеличит скорость записи. Он даст больше пространства для маневра: может получиться оформить операцию записи как только программирование страниц. Без стирания вообще. Откуда и рост скорости. И меньшая деструктивность процесса в среднем. Грубо говоря, повышается КПД логики SSDшного контроллера. > Ресурс флэш тратиться на освежение, которого можно избежать в принципе — > сделать размер блока ФС равным размеру блока SSD. Ну да, ну да, и угадать размещение блока ФС чтобы не попало на границы блоков флеша, когда будет на ровном месте тереться 2 блока вместо 1 просто потому что блок ФС угораздило же лежать в обоих. А блоки переменного размера окончательно испортят компот, сделав это начинание невозможным. Не говоря о том что тратить блок 512Кб на файлик в 1Кб размером будет достаточно обидно. > Контроллер SSD по команде ФС записывает данные на флэш только поблочно, Минимальной единицой записи в флеш является страница. Есть более крупные блоки - группы страниц, стирание в 0 происходит только большими группами. Ты о каких из блоков? > при этом имеются в виду не блоки ФС (хотя и они тоже > в этом процессе участвуют), а более объёмная по отношению к ФС > величина — блок SSD, имеющий размер 512 килобайт. Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с 512-Кб блоками так чтобы они совпали с секторами флеша - ты, натурально, выиграешь по скорости записи. Практически - флаг тебе в руки это сделать в ZFS с ее блоками переменного размера и смотри не удавись от жабы когда файл 1 Кб начнет жрать 512Кб блок, если это вдруг получится. > Модификация данных происходит в оперативном кэше SSD с целым блоком. Если есть > очищенные страницы в блоке, то их не нужно предварительно обнулять (это > сделал GC после команды TRIM), скорость записи на них высока. Однако > в блоке SSD присутствуют и другие блоки ФС, которые не модифицируются. > Но они тоже будут перезаписаны (освежены), Проблема в том что ты вроде бы начинаешь вкуривать что такое read-modify-write, но совершенно забыл про wear leveling. Который в общем случае постарается сделать запись в другое место флеша чтобы размазать запись. И вот тут возможны варианты. В случае когда юзается TRIM - есть свобода маневра и можно просто оформить это как программирование страниц. А вот если trim нет - с чистыми блоками небогато. И вот тут придется разгребать хлам по полной. Попав на дополнительные процедуры read-modify-write и erase "просто потому что это надо хоть куда-то записать, черт возьми". А когда нет того что хотелось - придется лепить из того что есть и распихивать ну хоть как-то. Как оптимально - всем понятно. Поэтому собственно и сделали trim ;) > так как контроллер SSD записывает данные на флэш только целым блоком > из оперативного кэша. Это называется "усилением записи". А я думал что это называется read-modify-write. > Да ну. Оптимальное распределение блоков ФС по всему пространству носителя вроде как > не тайна за семью печатями. С одной стороны, прикольно что до изена стало доползать как выравнивать фс на блоки флеша. С другой - я бы посмотрел как ты ZFS на блок флеша выровняешь :D. > GC работает с отдельными страницами. Логично - он расчищает блоки чтобы можно было их erase'нуть без потери данных, перегруппируя страницы в другие блоки, сдвигая их так что они без "прорех" из неактуальных данных. Вот только у этой логики отбирается вся свобода маневра когда trim нет. По поводу чего оно натужно дергается в попытках выкроить свободные блоки "ну хоть как нибудь" а не разрулить запрос "как оптимальнее". Trim это основательно лечит. > весь блок SSD — мы говорим для условия, когда размеры блоков > ФС и SSD совпадают. Кроме размера должны еще и границы блоков совпасть. А вот это уже не самое простое требование. А с блоками переменного размера - ну ты понял, да? :) > для модификации его блоков. В случае с совпадением размеров блоков операция > очистки производится для всего блока SSD сразу, данные записываются большими порциями > — нет оверхеда на подчистку отдельных страниц. Если забить на часть бреда, вот этот кусок даже в принципе верен. Вот только это весьма идеализированный случай. И маловероятно что ты нечто такое на ZFS вообще сможешь изобразить. > Осталось проверить поведение обеих ФС при интенсивных операциях записи-стирания данных. > ;) Выяснится, что GC может и не успевает за подчистками. В клиническом случае может и не успеть. Вот только в этом случае SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс не больно огромный, порядка нескольких тысяч циклов всего. Так что (в идеальном случае) несколько тысяч записей объемом с накопитель и усе, он начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. >  Заодно и проверить ресурс флэшатины под обеими ФС. ;) В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора менять SSD" :). А в менее суровых случаях имхо ФС с trim выиграют. > Ты действительно веришь, что GC после своей работы с блоком разделяет блок > на отдельные страницы (очищенные и занятые), компонует очищенные в чистые блоки > SSD и складирует их куда-то? Естественно, на то и GC. Иначе он мог бы нарваться на тупые и смешные ситуации например когда в каждом блоке засрано по странице. Так что полную страницу записать уже нельзя. Вроде бы места дофига а записывать некуа. И чего? > Вот только КУДА — наверно, в Астрал, так как метаинформацию для такой > перекомпоновки потребуется столько же, что и сам полезный объём SSD. ;) Ну нифига себе у тебя технологии, если запись о трансляции блока занимает столько же сколько сам блок.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	309. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 07:35
	> Интересовался устройством FTL (flash translation layer) и наблюдал как это вообще работает. > Ну вот такое у меня хобби есть. Это как раз примерно > то самое что в SSD нынче суют. О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов. > Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет > с блоком SSD. Поэтому - да, ты очень хорошо подсказываешь - > часто будет тереться ДВА блока там где хватило бы одного. Absolutely. А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы записи одной страницы. Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц.
	Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

	316. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 11:28
	> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы > записи одной страницы. Пример - перезапись 1 байта в файле :) Вот для этого существует дедуплекация. > Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS > - в любом случае получим запись целых блоков вместо страниц. Если там будет контроллер SF2*** там все будет свсем не так как вы думаете :-)))
	Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

	320. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 12:19
	>> А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы >> записи одной страницы. Пример - перезапись 1 байта в файле :) > Вот для этого существует дедуплекация. При чем тут дедупликация, вообще? >> Для CoW это вообще страшнейшая операция. А в случае блок=блок ZFS >> - в любом случае получим запись целых блоков вместо страниц. > Если там будет контроллер SF2*** там все будет свсем не так как > вы думаете :-))) А если бы еще и во рту грибы росли...
	Ответить | Правка | К родителю #316 | Наверх | Cообщить модератору

	321. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok), 24-Сен-12, 12:23
	> А если бы еще и во рту грибы росли... Месье поял насколько он неправ ? Ну не расстраивайтесь так из-за ерунды. Вот позитивная статья http://b-a-t.livejournal.com/210090.html для поднятия настроения ... особенно каменты :-)))
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	322. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 12:24
	>> А если бы еще и во рту грибы росли... Пойми - ошибка конкретной фирмвари конкретного контроллера будет исправлена, если она есть. Да и мнение одного хомячка не определяет.
	Ответить | Правка | К родителю #321 | Наверх | Cообщить модератору

	341. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 22:37
	> О, хоть кто-то :) Я в свое время реверсил FTL (TFS) на > Samsung'ах X100/X600/E700 - разбирал данные в т.ч. с полумертвых аппаратов. Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в некоторых блоках не нравилось, они перекрыли запись ряда интересных блоков через свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые шлются в девайс, инициализируют железо, детектируют тип флеща и его набор команд (intel, AMD) ну и делают чтение, стирание и запись (по сути некий эквивалент олдскульных программ-мониторов, только ремотненько, по UART-у). А кроме всего прочего был расковырян формат области EEPROM в флеше, оказавшийся простой флешовой файловой системой. С простой формой wear leveling и номерами блоков вместо названий файлов. Для наиболее интересных из них был отбабахан действующий макет read-modify-write. Правда полноценный GC делать меня заломало, так что в сильно экзотических случаях оно в принципе могло обломаться. Впрочем, на практике это случалось только у особо крутых извращенцев долго мучавших зону EEPROM, таковых было очень мало и проблема не существовала. Отличная штука для понимания устройства флешовых систем: простенько но со вкусом и все основные элементы - на месте. А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL который они уже тогда раздавали просто так. И я понял что большинство из логики работы этой штуки я уже где-то видел. В общем то вся эта механика у всех достаточно похожа по общей логике работы. >> часто будет тереться ДВА блока там где хватило бы одного. > Absolutely. Ну я то представляю себе что получится. А вот nagual-ы и izen-ы очень врядли. Зато пальцы то погнуть хочется :) > А еще чаще будет тереться/писаться целая пачка блоков там, где хватило бы > записи одной страницы. Ну да. Одно дело если GC будет надрываться и пытаться выкроить место из того что есть под то что хотелось и другое если просто страницы распихали и готово :) > Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. Это почему? Оформляется выносок в сторону. Это достаточно быстро само по себе. Вот правда метаданных будет больше чем данных + фрагментация возрастет. Если все время глушить такие запросы - ФС деградирует разумеется, но это не есть типовой юзкейс. А ФС оптимизируют все-таки на более-менее типовые сценарии. То что всякими извращениями можно любую ФС на лопатки уложить - ни для кого не новость :) > А в случае блок=блок ZFS - в любом случае получим запись целых блоков вместо страниц. ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку trim своим бредом. Смешные они, эти юные бсдшники :)
	Ответить | Правка | К родителю #309 | Наверх | Cообщить модератору

	343. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 22:51
	> Сименсы, сэр. Все что на 166-м проце ;). Поскольку сименсу копание в Ох как, значит коллеги :) > свой дебажный протокол. Пришлось пойти сложным путем: были написаны загрузчики которые > шлются в девайс, инициализируют железо, детектируют тип флеща и его набор Почти то же самое. Загрузчики только юзали самсунговские, но тоже реверсилась система команд, и прошивалка делалась, ага. SGHFD (SGH Flasher/Dumper, уже из области археологии ныне). > А кроме всего прочего был расковырян формат области EEPROM в флеше, > оказавшийся простой флешовой файловой системой. С простой формой wear leveling и > номерами блоков вместо названий файлов. У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера. Реверсинг X100 (TFS 3.03) доставил много веселых часов, потому что некоторые значения номеров блоков в левелере считались откровенно через задницу. А реверсинг E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен. --- [из сохранившегося]    POverEnd denotes the sector from which area after PStart + Remap Data    Length + Remap Info Length continues (probably, but it can be relatively    simply calculated without using this field).    One more thing. If remap sectors come over filesystem length (as    example mapping 23 sectors to 3C6 gets us to sector 3E8 which is    just outbound of the data area, then it is wrapped to sector 0    and further, so in our case 3E7 is 0 and 3E8 is really 1. Crap. --- [из сохранившегося] > Отличная штука для понимания устройства флешовых систем: простенько но со вкусом > и все основные элементы - на месте. +1 > А потом мне вообще случайно попался в лапы сорц полновесного интеловского FTL > который они уже тогда раздавали просто так. И я понял что > большинство из логики работы этой штуки я уже где-то видел. В > общем то вся эта механика у всех достаточно похожа по общей > логике работы. >> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. > Это почему? Оформляется выносок в сторону. > Вот правда метаданных будет больше чем данных. ВотЪ. Приятно говорить с понимающим человеком :)
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	397. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 25-Сен-12, 21:08
	> Ох как, значит коллеги :) Получается что так :) > Почти то же самое. Загрузчики только юзали самсунговские, А в этом случае свои были, сделанные на основе изучения сименсовских и штук от других граждан, etc. Сименсовские сильно ориентированы на флешинг апдейтов + у них протокол дурной: мелкие блоки. Заломало логику с окнами делать и прочая. Получилась штука простая как дубинка и с кучей упрощений. Но вполне работающая и в 10 раз меньше кода в бутлоадере + простой, понятный и неубиваемый протокол. Хоть и халтурка слегка (полная синхроншина, ни окон протокола, ни прерываний UART, которые поди еще найди в неизвестном проце). > но тоже реверсилась система команд, и прошивалка делалась, ага. > SGHFD (SGH Flasher/Dumper, уже из области археологии ныне). Ну и сименсы х3х-х5х тоже археология уже. Ну а знания о том как делают флешовые ФС и свойства флеша и по сей день актуальны :). Кстати у английских википедиков вполне доходчиво описано на уровне устройства чипа флеша откуда берется столь странная механика. >> номерами блоков вместо названий файлов. > У самсунгов внутри оказалось некое подобие FAT, разложенное поверх сносного веарлевелера. А это немного смахивает на ранние версии JFFS, чтоли. По крайней мере трюк с допрограммированием уже программированных байтов без стирания блока за счет читерства с битиками там тоже был. > E700 (TFS 3.12) вообще сломал мозг - там левелер слегка нелинеен. О как. > --- [из сохранившегося] О как, похоже на полноценный wear leveling. А немцы просто сгородили нечто типа флешовой ФС но попримитивнее. Потом они кстати похожий формат данных и для настоящей ФС заюзали. По сути ранний прототип flash file systems по типу JFFS получился. >> Отличная штука для понимания устройства флешовых систем: простенько но со вкусом >> и все основные элементы - на месте. >>> Пример - перезапись 1 байта в файле :) Для CoW это вообще страшнейшая операция. >> Это почему? Оформляется выносок в сторону. >> Вот правда метаданных будет больше чем данных. > ВотЪ. Приятно говорить с понимающим человеком :) Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту в природе мало. Только Шишкину не говорите, а то он разопрется как PoC отгрохать том состоящий почти целиком из метаданных и будет орать что это отстой :)
	Ответить | Правка | К родителю #343 | Наверх | Cообщить модератору

	401. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 22:18
	> Ага :). Просто извращенцев дописывающих все файлы в ФС по 1 байту > в природе мало. Только Шишкину не говорите, а то он разопрется > как PoC отгрохать том состоящий почти целиком из метаданных и будет > орать что это отстой :) LAWL :) +100500
	Ответить | Правка | К родителю #397 | Наверх | Cообщить модератору

	348. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 23:44
	> ИМХО эти чудики просто прикрывают свою голопопость и отсутствие надежды на поддержку > trim своим бредом. Смешные они, эти юные бсдшники :) Ой ЧСВ пробило потолок :-))
	Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

	312. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 11:09
	> И кстати erase - это весьма длительная операция. Как то раз один дурак ляпнул и теперь все заучили как молитву. Это из раздела - переходные процессы длятся бесконечно долго :-))) Без тестов больше эту херню тут не пишите. >[оверквотинг удален] > Вполне себе верна. Чем больше пространства для маневра - тем реже приходится > судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции. > Собственно грубый прототип того что получается ты и так увидел на > забитом под завязку томе. А тут похожая логика: размазывание записи - > по сути вариант CoW получается. Ну и общие свойства стало быть > похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его > не видно в емкости накопителя которая написана на упаковке, а вот > место в чипах памяти оно жрет. Производителю не нравится напаивать больше > памяти при том что цифра на упаковке не увеличивается. Ведь хомячки > покупают гигабайты :) Еще производитель старается подгадать срок эксплуотации под гарантийный ... > В этом случае как раз контроллер имеет все шансы заранее сгрести мусор. > Тогда стирания не будет, только программирование страниц. И чем больше места > не занято - тем больше пространства для маневра: может получиться воткнуть > желаемую запись куда-то в уже очищенные страницы. А если trim нет > то постепенно все придет к схеме когда "проблема решается по мере > возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок > чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а > что нет. По поводу чего и скорость записи просядет, и возможности > оптимизации размещения записей у контроллера будут откушены по полной программе. Многие люди суют ssd в рейды встроенные в матери, и большая половина этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так что ждать обновлений биоса как погоды у моря. И что многие жалуются на ужасное - ужасное падение производительности ? Кеп покажи как ты умеешь гуглить :-)) > Хинт: если бы все было так как ты говоришь, никто не стал > бы геморроиться с реализацией команды TRIM от которой и так нет > эффекта. По-моему, это даже детсадовцу понятно? :) Трим маркетинговый ход на который есть патент :-)) или не ? > Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет > с блоком SSD. Месье не делал но знает ... > Поэтому - да, ты очень хорошо подсказываешь - > часто будет тереться ДВА блока там где хватило бы одного. Ну > а с блоками переменного размера ты еще и никогда не сможешь > выровнять ФС так чтобы ее блоки совпали с блоками флеша. И все же это реально ... > Так > что многие блоки ФС попадут на пересечение блоков флеша. Вот ить > незадача то. Тут вам и двукратный wear, и более тормозная запись > лишний раз. Так тестов никто и не привел ... > В случае с TRIM это не такая уж проблема, > т.к. erase не будет и будет только программирование страниц по количеству > записываемого. А вот без него логика контроллера свалится в черти-какой штопор. > Грубый прикидон мне подсказывает что экстенты + trim будут работать не > в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы > и по объему желаемой записи и ... все :). Юзание TRIM > порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий > вообще каждый раз. Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ... > Ну да, ну да, и угадать размещение блока ФС чтобы не попало > на границы блоков флеша, когда будет на ровном месте тереться 2 > блока вместо 1 просто потому что блок ФС угораздило же лежать > в обоих. А блоки переменного размера окончательно испортят компот, сделав это > начинание невозможным. Не говоря о том что тратить блок 512Кб на > файлик в 1Кб размером будет достаточно обидно. А в других фс не обидно ... > Минимальной единицой записи в флеш является страница. Есть более крупные блоки - > группы страниц, стирание в 0 происходит только большими группами. Ты о > каких из блоков? > Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с > 512-Кб блоками так чтобы они совпали с секторами флеша - ты, > натурально, выиграешь по скорости записи. Практически - флаг тебе в руки > это сделать в ZFS с ее блоками переменного размера и смотри > не удавись от жабы когда файл 1 Кб начнет жрать 512Кб > блок, если это вдруг получится. А ьы хотели бд на zfs и там вообще 10 файлов максимум ... > С одной стороны, прикольно что до изена стало доползать как выравнивать фс > на блоки флеша. С другой - я бы посмотрел как ты > ZFS на блок флеша выровняешь :D. gnop create -S 4096 /dev/gpt/disk0 zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop Это ? > Кроме размера должны еще и границы блоков совпасть. А вот это уже > не самое простое требование. А с блоками переменного размера - ну > ты понял, да? :) Так чтоли zfs set recordsize=128k tank/mysql/iblogs ? > В клиническом случае может и не успеть. Вот только в этом случае > SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс > не больно огромный, порядка нескольких тысяч циклов всего. Так что (в > идеальном случае) несколько тысяч записей объемом с накопитель и усе, он > начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. Вот такое Г... просто ненужно покупать. > В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора > менять SSD" :). А в менее суровых случаях имхо ФС с > trim выиграют. У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-)) Как же там все темно http://habrahabr.ru/post/143659/ дословно: Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает удалённую пользователем информацию своим особым образом и вообще хранит данные на диске в виде одного большого архива ... Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет.
	Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

	318. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 12:17
	>> И кстати erase - это весьма длительная операция. > Как то раз один дурак ляпнул и теперь все заучили как молитву. http://www.datasheetcatalog.org/datasheet/SamsungElectronic/... Страница 19, tBERS. Ситуация типовая для NAND. > Это из раздела - переходные процессы длятся бесконечно долго :-))) > Без тестов больше эту херню тут не пишите. Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи. > Многие люди суют ssd в рейды встроенные в матери, и большая половина > этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Хомячки с локалхостами в контексте обсуждения мало интересны. > Трим маркетинговый ход на который есть патент :-)) или не ? TRIM - насущная необходимость для нормального левелинга флеша. Тчк. > Сан юзает ссд диски под кеш zfs и знать незнает что использует Сан уже от'юзался. Унылый такой мертвячок. А SSD под кеши юзаются в основном на аппаратных контроллерах, которые знают про TRIM. > Вот такое Г... просто ненужно покупать. Просто нужно нормально юзать флеш - так, как обусловлено техническими характеристиками, а не так, как левая задняя нога чешется.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	423. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 26-Сен-12, 18:59
	> Садись, корень из двух в квадрате. Сначала пойми, как работает флеш, потом приходи. При том даже на (английской) википедии доступно разжевано каког оно именно так. > TRIM - насущная необходимость для нормального левелинга флеша. Тчк. Сейчас будет фокус: как только его запилят в ZFS - они это резко осознают. Люблю все-таки лицемеров - кормят хорошо и лулзов генерят море :) > основном на аппаратных контроллерах, которые знают про TRIM. Еще есть категория граждан пытающихся затыкать технические прорехи маркетинговым буллшитом. Правда настолько явно лажаться - не прокатит, да и вообще, что-то не помог саням их маркетинг.
	Ответить | Правка | К родителю #318 | Наверх | Cообщить модератору

	344. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 23:38
	> Как то раз один дурак ляпнул и теперь все заучили как молитву. Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы уж простите, сэр, но я почему-то полагаю что производитель чипов лучше знает свойства своих поделий чем какой-то там nagual. И они, вероятно, менее дураки, поскольку в отличие от вас они эти чипы и производят. По поводу чего должны знать их свойства. И если все производители пишут в датащитах примерно одно и то же, обобщаем и делаем вывод что это свойство "технологии вообще". ИЧСХ, это действительно свойство "технологии вообще". > Это из раздела - переходные процессы длятся бесконечно долго :-))) > Без тестов больше эту херню тут не пишите. Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они ж крутые мачо. Умнее производителей чипаков :) >> памяти при том что цифра на упаковке не увеличивается. Ведь хомячки >> покупают гигабайты :) > Еще производитель старается подгадать срок эксплуотации под гарантийный ... В случае с SSD это не получится хотя-бы потому что производитель не властен над объемом записываемых данных. Да и репутация от отказов накопителей сильно страдает. Так что специально никто не пакостит. Просто издержки особенностей технологии помноженные на желание хомяков купить побольше гигазов и подешевле дают свой результат. Все зависит от того насколько с умом подходить к делу. У меня например системный накопитель протерся на ~0.1% за полгода, судя по статистике SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает что если ничего не изменится, он еще доооооолго будет работать в таком режиме. Но во первых, я юзаю TRIM, во вторых я аккуратно оптимизнул и вынес все что делало не в меру активные записи на механику. В третьих я не забиваю накопитель на 99.9% т.к. сам себе не враг и не очень хочу дорогие SSD спускать пачками в трэш по своей глупости. >> что нет. По поводу чего и скорость записи просядет, и возможности >> оптимизации размещения записей у контроллера будут откушены по полной программе. > Многие люди суют ssd в рейды встроенные в матери, и большая половина > этих рейдов ну разве кроме последних моделей понятия неимеет о триме. А я что, виноват что дуралеев на свете много? Хотя в том же линуксе такой RAID обычно рюхается чисто программно и от контроллера вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера. Вся поддержка со стороны мамки сводится аж к добавочному ROM для системного BIOS который умеет показывать несколько дисков как якобы один для DOS и начальных загрузчиков, так что они с этого могут начать грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых диска на контроллере. И уже сама из них изображает "RAID". > Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так > что ждать обновлений биоса как погоды у моря. Лулз состоит в том что все современные операционки не используют в своей работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО делает кернель операционки. А вот незнание таких основ архитектуры современных операционок вам чести не делает. Так и запишем. > И что многие жалуются на ужасное - ужасное падение производительности ? > Кеп покажи как ты умеешь гуглить :-)) Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. >> эффекта. По-моему, это даже детсадовцу понятно? :) > Трим маркетинговый ход на который есть патент :-)) или не ? Прежде всего это фича призванная ускорить работу и замедлить протирание SSD. Потому что возвраты по гарантии никому не уперлись, а хомяк за новым SSD и так придет, когда выкатят в 2 раза более емкий и в 2 раза более быстрый, зря чтоли корпоративщики потребццтво прокачивали? Хомяку неизбежно захочется больше, да :) >> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет с блоком SSD. > Месье не делал но знает ... Мсье делал и как раз именно поэтому - знает. Да, это был не ZFS, но это не мешает прикинуть на основе имеющихся знаний как оно получится. >> выровнять ФС так чтобы ее блоки совпали с блоками флеша. > И все же это реально ... Тогда ждем рецепт в студию с описанием технологии этого действа :). Я пока такое видел только для примитивных ФС и относительно примитивных флешек и SD карт. Там все проще. И блоки постоянного размера, и контроллеры потупее. >> Так что многие блоки ФС попадут на пересечение блоков флеша. Вот ить >> незадача то. Тут вам и двукратный wear, и более тормозная запись лишний раз. > Так тестов никто и не привел ... А какой смысл бисер метать? На тесты надо довольно много времени, так что если не попадется готовых очень кстати и нахаляву, я не буду такой объем работы воротить задаром для непойми кого. Особенно если он не знает что современные ОС BIOS'ом не пользуются в процессе работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер? >> порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий >> вообще каждый раз. > Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... У сана вообще маркетинговый буллшит вместо технологий был в норме вещей, как я погляжу. Но такой расклад устраивает далеко не всех. Вот вы и кушайте маркетинговый шит, а я хорошие, интересные и полезные технологии предпочитаю. > вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ... Зато маркетологи с удовольствием втирали некомпетентному лошью маркетинговый буллщит про то как ZFS оптимизирован для SSD. Хотя инженеры саней пальца о палец для этого не ударили. Ну а что, доллары то не пахнут. Правда это не особо помогло и сани продались. Ну а оракл на этот маркетинговый шит уже забил. Благо ZFS для их БД не фонтан а больше им ничего и не надо. Тем более что клиентура все чаще желает линукс. >> файлик в 1Кб размером будет достаточно обидно. > А в других фс не обидно ... Так никто в здравом уме и не юзает блоки ФС фиксированного размера в 512Кб если вы не заметили. Как по мне - достаточно выравнивать на размер страницы. >> не удавись от жабы когда файл 1 Кб начнет жрать 512Кб >> блок, если это вдруг получится. > А ьы хотели бд на zfs и там вообще 10 файлов максимум ... А с ней опа будет по другим поводам. Там логика журналирования БД подерется с природой работы ФС и будет двойная работа. CoW радостно закопирует и изменения в БД, и изменения в журнале. Многократное умножение работы - совершенно на ровном месте. Просто потому что два алгоритма не подружились между собой. >> ZFS на блок флеша выровняешь :D. > gnop create -S 4096 /dev/gpt/disk0 > zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop > Это ? Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного размера. Но может и спровоцировать выравнивание по страницам в лучшем случае, как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть в детали того как ZFS блоки переменного раскладывает. >> не самое простое требование. А с блоками переменного размера - ну ты понял, да? :) > Так чтоли zfs set recordsize=128k tank/mysql/iblogs ? Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности устройства ZFS, блоков переменного размера и прочая, что я не взялся что-то гарантировать и даже прикинуть что будет если и смогу то сильно приблизительно. Но в целом - вы как ни странно, верно уловили что ориентированные на выравнивание по блокам RAID или секторам дисков опции частично применимы и для SSD. Правда с оговорками. Проблема в том что истинную геометрию флешатины скрывает контроллер, у которого к тому же есть некая своя логика работы в фирмваре. По этому поводу честно вычислить параметры технически невозможно. Можно подобрать, сделав ряд экспериментов. Для более простых ФС и контроллеров это даже народом освоено слегка. >> начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям. > Вот такое Г... просто ненужно покупать. Так другое особо и не производят. Хотя в принципе бывают SLC накопители иногда, но - стоят дофига, а объем мелкий. Что как-то не очень то и перевешивает бОльший срок службы и бОльшую скорость записи в большинстве случаев. Общество потребления, однако. >> trim выиграют. > У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-)) Мой системный SSD например судя по его SMART рискует сильно пережить и гарантию и вообще. А так - накопитель сдуру можно убить довольно быстро. > Как же там все темно http://habrahabr.ru/post/143659/ дословно: > Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. > Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает > удалённую пользователем информацию своим особым образом и вообще хранит данные на > диске в виде одного большого архива ... А sandforce вообще странные штуки. Они жульничают с скоростями чтения-записи и прочая, делая скоростное сжатие данных. По поводу чего на нежмущихся данных скорость заметно меньше чем на жмущихся. Странные люди - маркетинг такой маркетинг. ZFSники с этого мало что выигрывают: если они хотели сжатие - оно в ZFS и так было. Да и в btrfs есть. > Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет. Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел - наслышан об оном.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	359. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 00:11
	>> Как то раз один дурак ляпнул и теперь все заучили как молитву. > Этот "дурак" назывался между прочим даташитами на чипы. От производителей чипов. Вы > уж простите, сэр, но я почему-то полагаю что производитель чипов лучше > знает свойства своих поделий чем какой-то там nagual. Как правило инженеры которые делают и инженеры которые пишут это не одни и те же люди и вторые понимают первых очень плохо ... Кто может тот делает а кто неможет вот как вы других учит :-))) > И они, вероятно, > менее дураки, поскольку в отличие от вас они эти чипы и > производят. По поводу чего должны знать их свойства. И если все > производители пишут в датащитах примерно одно и то же Да любят они копипастить друг у друга :-)) как же без этого. >> Это из раздела - переходные процессы длятся бесконечно долго :-))) >> Без тестов больше эту херню тут не пишите. > Вы это производителям чипов флеш-памяти расскажите. А то пишут, понимаешь, в своих > даташитах. А всякие nagual-ы и изены - не верят, понимаешь. Они > ж крутые мачо. Умнее производителей чипаков :) Так и запишем - месье писатель, тесты это слоржно ... > Все зависит от того насколько с умом подходить к делу. У меня > например системный накопитель протерся на ~0.1% за полгода, судя по статистике > SMART у накопителя :D. Т.е. в среднем произошел примерно 1 цикл > перезаписи всех блоков. Из ~1000 гарантированных производителем чипов. Что-то мне подсказывает > что если ничего не изменится, он еще доооооолго будет работать в > таком режиме. Но во первых, я юзаю TRIM, во вторых я > аккуратно оптимизнул и вынес все что делало не в меру активные > записи на механику. В третьих я не забиваю накопитель на 99.9% > т.к. сам себе не враг и не очень хочу дорогие SSD > спускать пачками в трэш по своей глупости. Если бы месье асилил статью на хабре он бы узнал что для половины ссд дисков трм включать не только не полезно но даже вредно :-)) > А я что, виноват что дуралеев на свете много? Хотя в том > же линуксе такой RAID обычно рюхается чисто программно и от контроллера > вообще ничего такого не требуется. Собственно, там нет никакого RAID контроллера. > Вся поддержка со стороны мамки сводится аж к добавочному ROM для > системного BIOS который умеет показывать несколько дисков как якобы один для > DOS и начальных загрузчиков, так что они с этого могут начать > грузиться. А дальше ОС отбирает бразды правления и видит 2 независимых > диска на контроллере. И уже сама из них изображает "RAID". В двух словах люди использующие аппаратные рейды дуралеи ... Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ? >> Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так >> что ждать обновлений биоса как погоды у моря. > Лулз состоит в том что все современные операционки не используют в своей > работе услуги BIOS и поэтому сие до лампочки. Эту работенку ВНЕЗАПНО > делает кернель операционки. А вот незнание таких основ архитектуры современных операционок > вам чести не делает. Так и запишем. Это делают драйвера ... > Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше > пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. Кеп неумеет гуглить ? > Мсье делал и как раз именно поэтому - знает. Да, это был > не ZFS, но это не мешает прикинуть на основе имеющихся знаний > как оно получится. На btrfs ext4 неудалось выровнять размер блока как в ссд а потому zfs гавно ... спасибо кеп ноу коментс. > Тогда ждем рецепт в студию с описанием технологии этого действа :). Кстати уже писалось если не асилите найти то медицина бессильна. > А какой смысл бисер метать? На тесты надо довольно много времени, так > что если не попадется готовых очень кстати и нахаляву, я не > буду такой объем работы воротить задаром для непойми кого. Особенно если > он не знает что современные ОС BIOS'ом не пользуются в процессе > работы для доступа к контроллеру мамки. А смысл то надрывать попу, > меча бисер? Короче с тестами опять не судьба ... > А с ней опа будет по другим поводам. Там логика журналирования БД > подерется с природой работы ФС и будет двойная работа. CoW радостно > закопирует и изменения в БД, и изменения в журнале. Многократное умножение > работы - совершенно на ровном месте. Просто потому что два алгоритма > не подружились между собой. Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? > Я не вижу, что в этом списке помешает ZFS шпарить блоками переменного > размера. Но может и спровоцировать выравнивание по страницам в лучшем случае, > как я понимаю. Насколько эффективно? Хороший вопрос, для этого надо лезть > в детали того как ZFS блоки переменного раскладывает. И тут тоже с тестами не судьба ... > Чисто теоретически, кручение этого параметра может до некоторой степени улучшить работу > с SSD. Чисто практически там такой mindf...k, особенно с учетом навороченности > устройства ZFS, блоков переменного размера и прочая, что я не взялся > что-то гарантировать и даже прикинуть что будет если и смогу то > сильно приблизительно. Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может... > Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел > - наслышан об оном. Как это не печально но последние модели интела тоже на нем - кризис. И трим этим ссд нужен как в бане лыжи.
	Ответить | Правка | К родителю #344 | Наверх | Cообщить модератору

	368. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 25-Сен-12, 07:32
	> Как правило инженеры которые делают и инженеры которые пишут это не одни > и те же люди и вторые понимают первых очень плохо ... И только nagual знает всё лучше вендоров. Вместе с братьями-акробатами на хабре. > Если бы месье асилил статью на хабре он бы узнал что для Я лучше по мануалам, чем по минному полю горе-экспериментаторов, не знающих теории. > половины ссд дисков трм включать не только не полезно но даже вредно :-)) Интересно, чьё больное воображение на хабре родило сей опус? Чистой воды буллшит же. > Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? Для СУБД? Да. Либо RAW, либо FS без каких-либо извращений. > Как это не печально но последние модели интела тоже на нем - > кризис. И трим этим ссд нужен как в бане лыжи. Это только в ваших фантазиях, дарагой друх.
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	398. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 25-Сен-12, 21:33
	>> уж простите, сэр, но я почему-то полагаю что производитель чипов лучше >> знает свойства своих поделий чем какой-то там nagual. > Как правило инженеры которые делают и инженеры которые пишут это не одни > и те же люди и вторые понимают первых очень плохо ... Понимаете, как я написал выше, я когда-то делал специфичный софт и там был специфичный протокол. В силу небольшой халтурки с упрощением протокола, данный самопальный протоколец подклинивало между передачей блоков. В аккурат на время erase и program. По поводу чего я намного лучше вас представляю себе сколько какие процедуры касающиеся флеша занимают. Наверное потому что я же их и реализовывал и наслаждался результатом. Но вы в вашем праве полечить меня еще. Хотя я и разжирею с такого раскорма меня разными ламерами :) > Кто может тот делает а кто неможет вот как вы других учит :-))) Вообще-то я впполне себе реализовывал процедуры записи в флеш. По поводу чего и имею представление о том как это работает. >> производители пишут в датащитах примерно одно и то же > Да любят они копипастить друг у друга :-)) как же без этого. А там нет копипасты. Это как правило более-менее честно меряется и/или приводятся worst cases соответствующие аппаратным таймаутам. Хотя удобно конечно думать что все дураки а вот вы умный. Ну, надизайньте чип и пустите в производство - тогда поверю. >> ж крутые мачо. Умнее производителей чипаков :) > Так и запишем - месье писатель, тесты это слоржно ... Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье тому сколько времени они занимают, лол :) >> т.к. сам себе не враг и не очень хочу дорогие SSD >> спускать пачками в трэш по своей глупости. > Если бы месье асилил статью на хабре Это ваша прерогатива - осиливать статьи на хабрашвабре. Специально для таких как вы ресурс. Еще можете всяких Левашовых читать. Хотя лучше сразу уж не мелочиться и взять МК бульвар. Там намного интереснее материалец попадается. > он бы узнал что для половины ссд дисков трм включать не только не полезно но даже > вредно :-)) Для дисков с дефективной реализацией контроллера и/или его фирмвары - да. Вот только это дефект диска. По хорошему с такими багами - сразу в гарантийку и пусть чинят как хотят. Sandforce ранних выпусков вообще прославился лютыми багами типа внезапных умираний и прочих приколов. > В двух словах люди использующие аппаратные рейды дуралеи ... В двух словах, некоторые дуралеи не знают что на мамках в 99.9% случаев райды чисто софтварные. > Вы где нибудь на ссд диске видели надпись no raid ? или что то вроде ? Нет. А должен был? >> вам чести не делает. Так и запишем. > Это делают драйвера ... Я догадывался. Но вы зачем-то вякнули про bios. Тем хуже для вас. >> Я знаю основы архитектуры ОС и без гуглинга. А вот вы жесточайше >> пропалились. Понты вообще до добра не доводят. Особенно глупые и наивные. > Кеп неумеет гуглить ? Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до описания конструкции. > На btrfs ext4 неудалось выровнять размер блока как в ссд а потому > zfs гaвно ... спасибо кеп ноу коментс. Улыбают меня эти бсдшники :). "Ну и что что с голой попой, все-равно BSD рулез!!!111" :) >> Тогда ждем рецепт в студию с описанием технологии этого действа :). > Кстати уже писалось если не асилите найти то медицина бессильна. Процитируйте? >> работы для доступа к контроллеру мамки. А смысл то надрывать попу, меча бисер? > Короче с тестами опять не судьба ... Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает. Ну или вы. Правда вам я доверяю меньше чем форониксу, увы. >> работы - совершенно на ровном месте. Просто потому что два алгоритма >> не подружились между собой. > Тоесть использовать raw поверх железного рейда без всяких там btrfs рулит ? А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если она совсем уж мешается. Правда забавно, да? :) > И тут тоже с тестами не судьба ... Затвердила сорока Якова одно про всякого :) > Увы месье теоретик, он знает что будет работать плохо но тестами доказать не может... Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша. Ы? >> Спасибо, у меня хватает ума обходить ранние поколения сандфорсов за пушечный выстрел >> - наслышан об оном. > Как это не печально но последние модели интела тоже на нем - кризис. А это уже новые модели где старые ляпы частично исправлены. > И трим этим ссд нужен как в бане лыжи. Сандфорсы вообще какие-то странные контроллеры. Но кроме них есть навалом других. Себе я бы ничего на сандфорсе покупать не стал.
	Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

	402. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 25-Сен-12, 23:06
	> Мсье писатель. Мсье лично писал процедуры стирания и программирования флеша. Поучите мсье > тому сколько времени они занимают, лол :) Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень. Это моразм ? > В двух словах, некоторые дуралеи не знают что на мамках в 99.9% > случаев райды чисто софтварные. Спасибо кеп. Осень да ? > Насчет "кеп" не знаю а вот вы точно не умеете. Даже детектор > нейтрино нагуглить не в состоянии. Хотя там есть все, вплоть до > описания конструкции. https://www.google.com.ua/search?client=opera&rls=ru&q=%... > Улыбают меня эти бсдшники :). "Ну и что что с голой попой, > все-равно BSD рулез!!!111" :) В лексекон настоящего линуксоида обязательно должны входить слова жопа и бсд :-)))) > Процитируйте? zdb -U /var/tmp/zpool.cache |grep ashift ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot не ? > Для нормального проведения таких тестов надо уйму времени. Пусть ее фороникс забабахает. > Ну или вы. Правда вам я доверяю меньше чем форониксу, увы. Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло претензий к тестам :-)) > А в btrfs можно, внезапно, отключить CoW логику для конкретных файлов, если > она совсем уж мешается. Правда забавно, да? :) Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4 так же внезамно в kvm виснут виртуалки :-)) > Затвердила сорока Якова одно про всякого :) А по существу ? > Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша. > Ы? Это к чему ?
	Ответить | Правка | К родителю #398 | Наверх | Cообщить модератору

	424. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 26-Сен-12, 19:25
	> Месье что то очень часто вспоминает бурную молодость. Иногда к месту, иногда неочень. Думаю что в данном случае мсье припомнил это кстати. Устройство флеша в целом мало изменилось за эти годы. Техпроцессы стали тоньше, контроллеры лучше. Но общие принципы работы никуда не делись и физика процесса вся та же. Поэтому знания мсье вполне актуальны. Вон соседний мсье не поленился даже адресно макнуть в даташит, где время стирания указано. > Это моразм ? Когда слово "маразм" не получается написать без ошибок - это он самый! Я гарантирую это. > https://www.google.com.ua/search?client=opera&rls=ru&q=%... > %D1%80%D0%BE%D0%B7&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest Это бесплатный бонус к "моразму" для большей убедительности? Ну ладно, засчитано, тема "моразма" раскрыта :) > В лексекон Кроме "моразма" ничуть не менее былинно и когда слово "лексикон" не могут написать правильно. Парад деда моразма, не иначе :) > ashift делается через gnop а  recordsize через zfs set recordsize=4k zroot Я так понимаю что сие нацелено на выравнивание по страницам. Что разумно и правильно. Но изен помнился хотел выравнивание на erase block. Мне не совсем понятно как это обеспечивается при блоках переменного размера или где в этой писанине отключение данной фичи. > не ? Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше вас знать вашу ФС чтоли? > Вы пишите пишите то что думаете о методике тестирования чтоб потом небыло > претензий к тестам :-)) Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький HDD и SSD и на них ФС развернуть и помучать - это уже нечто годное. Но это много возни. Получить представление о том какие более-менее реалистичные тесты есть можно у того же фороникса. Правда они бенчат не все нагрузки, но это лучше чем ничего. И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе чтобы вы понимали что такое погрешность измерений, например? Если уж вы бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках. >> она совсем уж мешается. Правда забавно, да? :) > Я заметил в линуксе многие вещи происходят внезапно , внезапно улетает ext4 Не знаю, у меня ничего не улетело за столько лет. Юзаю с 2.6.32 ядра. Все на месте. Хотя где-то в районе .35 редкий но меткий баг починили но его еще суметь надо огрести т.к. лезет только на очень больших файлах. > так же внезамно в kvm виснут виртуалки :-)) Странно, а у меня они просто работают. Тем паче что бзды вообще не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения. >> Затвердила сорока Якова одно про всякого :) > А по существу ? По существу, проведение бенчей в нормальном виде - достаточно долго и требует оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей - не настолько простая задача как это кажется. У них в общем то обычно есть нормальное описание конфига и какое-никакое описание методики, они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты. >> Мсье такой теоретик что аж сам писал процедуры стирания и записи флеша.Ы? > Это к чему ? К наездам на то что мсье теоретик. А вот и фиг, мсье практик. Просто даже небольшая практика требует большой теории.
	Ответить | Правка | К родителю #402 | Наверх | Cообщить модератору

	429. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 26-Сен-12, 21:05
	> Т.е. вы сами не уверены что оно делает. Зашибись, я должен лучше > вас знать вашу ФС чтоли? Ну чтовы :-) вы просто неправильно поняли написанное :-)) > Я думаю что 5 дисков на 1Гб - это "моразм". Вот реалистичненький > HDD и SSD и на них ФС развернуть и помучать - > это уже нечто годное. Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и собственно работой логики фс месье настаивает ... это уже маразм. > И да, надеюсь у вас был хотя-бы курс лабораторных работ в вузе > чтобы вы понимали что такое погрешность измерений, например? Если уж вы > бенчить что-то намерены. Фороникс и то в курсе и отмечают оную > на графиках. Ой мессье не смог вспомнить название теории Стьюдента. > Странно, а у меня они просто работают. Тем паче что бзды вообще > не умеют хостом для виртуалок быть и потому вообще выпадают из > рассмотрения. tcpdump на виртуалке запустите :-)) > По существу, проведение бенчей в нормальном виде - достаточно долго и требует > оборудования и квалификации. Даже тот же фороникс переплюнуть по качеству бенчей > - не настолько простая задача как это кажется. У них в > общем то обычно есть нормальное описание конфига и какое-никакое описание методики, > они в состоянии опробовать разные нагрузки и более-менее осмысленно разгрести результаты. Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-)) > К наездам на то что мсье теоретик. А вот и фиг, мсье > практик. Ода мы уже заметили :-))
	Ответить | Правка | К родителю #424 | Наверх | Cообщить модератору

	432. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 26-Сен-12, 21:46
	> Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и > собственно работой логики фс месье настаивает ... это уже маразм. Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я понимаю, что это далеко от идеологии BSD'шника, но всё же.
	Ответить | Правка | К родителю #429 | Наверх | Cообщить модератору

	433. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 26-Сен-12, 23:14
	> Просто инженеров интересует реальный перформанс, а не сферические кони в вакууме. Я > понимаю, что это далеко от идеологии BSD'шника, но всё же. Это вы про тех самых инженеров которые немогут bc и count на пальцах показать ?
	Ответить | Правка | К родителю #432 | Наверх | Cообщить модератору

	436. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 27-Сен-12, 17:30
	> Это вы про тех самых инженеров которые немогут bc и count на > пальцах показать ? bc - это вообще программа-калькулятор такая. А вы наверное про bs.
	Ответить | Правка | К родителю #433 | Наверх | Cообщить модератору

	451. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 30-Сен-12, 20:56
	> Ну чтовы :-) вы просто неправильно поняли написанное :-)) Наверное дело в том кто объясняет. Вот были бы вы супермозгом, типа резерфорда, вы бы и ядерную физику кухарке разжевали в 2 счета. А поскольку вы сами не понимаете что лопочете - отсюда и результат. Сложно объяснить окружающим свою мысль если сам не понимаешь или неправильно понимаешь что хотел сказать. > Несмотря на на все намёки в разнице быстродействия мехпнизмов реальных дисков и > собственно работой логики фс месье настаивает ... это уже маразм. Мсье настаивает на том что ZFS вообще не демонстрирует ничего сногсшибательного в бенчах. А в ряде бенчей испытывает откровенные проблемы. >> бенчить что-то намерены. Фороникс и то в курсе и отмечают оную на графиках. > Ой мессье не смог вспомнить название теории Стьюдента. О, мсье даже помнит такие названия? Ну тогда может быть еще не все потеряно. Но учтите, мы тут бдим (не путать с "бздим"). >> не умеют хостом для виртуалок быть и потому вообще выпадают из рассмотрения. > tcpdump на виртуалке запустите :-)) Запустил. И чего? Вроде ничего необычного. Tcpdump, показывает трафф на интерфейсе. Вроде относительно честно. > Их бенчи не воспроизводятся :-)) их невозможно переплюнуть :-)) А что, пробовали воспроизводить? Неужто вы нашли железо как у них? Это при том что вы 1 диск для тестов выкроить не можете? Как-то неубедительно. >> К наездам на то что мсье теоретик. А вот и фиг, мсье практик. > Ода мы уже заметили :-)) Кому ода? Ламерам? :)
	Ответить | Правка | К родителю #429 | Наверх | Cообщить модератору

	245. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 20:44
	> Поэтому > вынужден очищать блоки только когда туда пытаются писать по факту. А > не заранее. И вот это является очень неоптимальным режимом работы. Учитывая что все последующие инсинуации основаны всего на одном предположении извольте предоставить доставерные тесты.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	298. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 06:26
	> доставерные ДостАверные тесты - это круто, да :)
	Ответить | Правка | К родителю #245 | Наверх | Cообщить модератору

	192. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	–1 +/–
	Сообщение от nagual (ok), 23-Сен-12, 17:01
	> Да, кроме всего прочего, TRIM - нормальный способ выполнить очистку блока заранее, > до того, как он понадобится системе. Стирание - не ахти какая > быстрая операция, и именно поэтому производительность ZFS будет на флешке сильно > ниже традиционок - эти FS не очищают блоки, и каждая перезапись > на них будет инициировать стирание. Единственный способ этого избежать - TRIM'ать > "устаревшие" ненужные более блоки после гарантированного завершения транзакций. Делает > ли это BTRFS - не знаю. Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил.
	Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

	204. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 18:41
	> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... > Что то не припомню чоб на 100% заполненом SSD диске тест записи > вдруг внезапно тормозил. http://www.anandtech.com/show/2829/9 http://www.bit-tech.net/hardware/storage/2010/02/04/windows-... Так, в качестве ликбеза.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	234. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 23-Сен-12, 20:33
	>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... >> Что то не припомню чоб на 100% заполненом SSD диске тест записи >> вдруг внезапно тормозил. > http://www.anandtech.com/show/2829/9 > http://www.bit-tech.net/hardware/storage/2010/02/04/windows-... > Так, в качестве ликбеза. Очень порадовали результаты тестов по первой ссылке: одни производители SSD дали бабла писателям PCMark Vantage и там 0% а другие не дали и там аж 23% Есть какие нибудь доставерные тесты где скорость меряется dd ?
	Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

	237. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 23-Сен-12, 20:36
	> Есть какие нибудь доставерные тесты где скорость меряется dd ? Есть. Самый достоверный тест - это произведенный собственными руками. Поэтому - прошу. К слову, результаты с теорией при правильном тестировании не разойдутся.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	299. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 24-Сен-12, 06:29
	> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... Да любого - как будто, эта логика у всех сильно отличается. Детали реализации могут отличаться, а вот общий смысл - фиг. > Что то не припомню чоб на 100% заполненом SSD диске тест записи вдруг внезапно тормозил. Возможно выехал на резервных маневровых страницах. Но это прокатит только при сравнительно небольших записях и не всегда. Ну и просто статистику по wearing'у надо смотреть. У хороших накопителей она на редкость дотошная.
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

	313. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 24-Сен-12, 11:10
	>> Похоже мы обсуждаем особенности какого то отдельно взятого дешового контроллера ... > Да любого - как будто, эта логика у всех сильно отличается. Детали > реализации могут отличаться, а вот общий смысл - фиг. Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-))
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	319. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 24-Сен-12, 12:18
	> Да не любого http://habrahabr.ru/post/143659/ читать до просветвленья :-)) После скриншотика с гламурного макбука блеванул, и читать перестал.
	Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

	201. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 23-Сен-12, 17:58
	> Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. А TRIM то там и нету. А в btrfs - опять же, есть. Ха.
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от iZEN (ok), 24-Сен-12, 19:45
	>>>> В этом плане ZFS с ее COW и SSD друзья > Снова садись, снова два. Без TRIM они не то, что не друзья, > а вообще не совместимы генетически. Смотри-ка, что pjd вчера закоммитил в head: http://svnweb.freebsd.org/base?view=revision&revision=240868 //--- Author: pjd Date: Sun Sep 23 19:40:58 2012 UTC (19 hours, 57 minutes ago) Changed paths: 19 Log Message: Add TRIM support. The code builds a map of regions that were freed. On every write the code consults the map and eventually removes ranges that were freed before, but are now overwritten. Freed blocks are not TRIMed immediately. There is a tunable that defines how many txg we should wait with TRIMming freed blocks (64 by default). There is a low priority thread that TRIMs ranges when the time comes. During TRIM we keep in-flight ranges on a list to detect colliding writes - we have to delay writes that collide with in-flight TRIMs in case something will be reordered and write will reached the disk before the TRIM. We don't have to do the same for in-flight writes, as colliding writes just remove ranges to TRIM. Sponsored by:    multiplay.co.uk This work includes some important fixes and some improvements obtained from the zfsonlinux project, including TRIMming entire vdevs on pool create/add/attach and on pool import for spare and cache vdevs. Obtained from:    zfsonlinux Submitted by:    Etienne Dechamps <etienne.dechamps@ovh.net> ---// Тут мнение: http://forum.ixbt.com/topic.cgi?id=11:44215-55#1599
	Ответить | Правка | Наверх | Cообщить модератору

	403. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 26-Сен-12, 13:39
	А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :)
	Ответить | Правка | К родителю #323 | Наверх | Cообщить модератору

	404. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 26-Сен-12, 13:40
	> А мнение iZEN и nagual о фиче теперь поменяется на противоположное? :) Неизбежно.
	Ответить | Правка | К родителю #403 | Наверх | Cообщить модератору

	425. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от Аноним (-), 26-Сен-12, 19:26
	> Неизбежно. Смешно будет смотреться когда им придется обсирать свою же предыдущую точку зрения :)
	Ответить | Правка | К родителю #404 | Наверх | Cообщить модератору

	491. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 02-Окт-12, 07:36
	> btrfs и SSD не совместимы ... В этом плане ZFS с > ее COW и SSD друзья а так как ZFS позицианируется под Без TRIM? Да, друзья. Примерно как волк зайцу. > Если вы не подскажете как его отключить нафиг через sysctl то будет считать что btrfs и SSD не совместимы -o ssd при монтировании
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	522. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от nagual (ok), 04-Окт-12, 10:12
	> А ничего что у всяких соляр и бздей на выбор полторы ФС, > при том одна переросточная и тормозная ынтырпрайзятина ZFS а вторая - > ископаемое с архитектурой каменноугольного периода UFS. Интересно для кого вы пишите этот бред ? Вот теореме Пифагора более 2000 лет и никто ничего нового не придумал ? Ай яй яй !!? Может быть потому что свойства трехмерного пространства с того времени не менялись ? UFS более десяти лет может быть по тому что устройства хранения данных с того времени сильно не менялись? Ну добавили soft update журнал снапшеты но в целом все по старому ... Зато в линуксе бурный рост :)) на фоне бурных глюков :)) Куча фс которые по сути одно и тоже если не считать btrfs с ее cow но linux с btrfs как то сильно отстал от freebsd с zfs ... это случайно :)) копипастеры зазевались? Очень радует разница между jsf и xfs :)) Нахрена две почти одинаковые fs ? Кто то хотел бабла срубить ? ЗЫ linux это та же избушка что и windows только повернута к лесу передом ...
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	528. "Обновление ZFSonLinux 0.6.0-rc11, реализации ZFS для ядра Li..."	+/–
	Сообщение от AlexAT (ok), 05-Окт-12, 11:37
	> Ну добавили soft update журнал снапшеты но в целом все по > старому... Ну да - всё те же тормоза. > Зато в линуксе бурный рост :)) на фоне бурных > глюков :)) Не ошибается тот, кто ничего не делает.
	Ответить | Правка | Наверх | Cообщить модератору

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

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