Вчера во FreeBSD размер блока по умолчанию был увеличен (http://svn.freebsd.org/changeset/base/222319) с 16 Кб до 32 Кб, а размер фрагмента - с 2 Кб до 4 Кб. Это было сделано для улучшения производительности на дисках с размером сектора 4 Кб. Кроме того, наблюдения показали, что настройки по умолчанию увеличиваются в 2 раза каждые 10 лет (в связи с ростом размеров дисков) - предыдущее увеличение было в 2001 году. Максимально возможный размер блока на UFS2 составляет 64 Кб.
На майском саммите разработчиков FreeBSD обсуждались (http://wiki.freebsd.org/201105DevSummit/FileSystems) и другие вопросы, касающихся файловых систем и способов разбиения диска на разделы (корень, /var, /home, /usr и др.) по умолчанию. Однако, такие возможные изменения, как увеличение размера номера inode до 64 бит и поддержка микрофайлов, невозможно реализовать без изменения дискового формата, UFS3 же пока активно не разрабатывается.URL: http://svn.freebsd.org/changeset/base/222319
Новость: http://www.opennet.me/opennews/art.shtml?num=30686
Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному использованию?
ХЗ, сижу на ней. Просто всё нормально. Вроде. Вы подали мысль... Можно по бенчмаркить.
Если касательно десктопа: с другой стороны, ну что вам от производительности файловой системы?
> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
> системы?Ну как же ж.
DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
А, ну это полюбому. :)
У меня отдельный девайс файлы качает. :)
>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>> системы?
> Ну как же ж.
> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)10 метров в секунду?)
>>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>>> системы?
>> Ну как же ж.
>> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
> 10 метров в секунду?)Да легко! :)
Не каждый диск такое выдержит (просьба не апеллировать к заявленной производителем пропускной способности: мы же не посекторно на HDD информацию заливаем).
> Не каждый диск такое выдержитТиповая линейная скорость чтения современного диска - около 100-150Мб/сек. Затормозить его до 10Мб/сек еще постараться надо. Для этого операционка, ФС и остальные должны ну совсем никак не пытаться оптимизировать доступ к диску.
К примеру, если вы посмотрите на работу торрент-клинтов, то увидите, что они обычно читают блоками по 128kb. Типичный блок, отдаваемый в торренте за раз - 32k. Хотя иногда получается читать большими блоками, но обычно при увеличении объема и количество раздач все переходит к тем самым 128k чтениями (писать, при хорошей буферизации, получается большими блоками, вплоть до мегабайта). Зависимость блоков чтения от объема раздач хорошо видно по статистике azureus. В utorrent чтение всегда по 128kb, а в остальных типа transmission можете помониторить iostat'ом и аналогичными.Теперь представьте, у вас 100 гб раздач (а бывает и куда больше). В целом это раздается нескольким сотням клиентов. И с какой скоростью ЖД способен отдавать данные в полностью случайных чтениях (100 гб и много клиентов => запросы идут все время в разные части диска) блоками по 128 кб? 10 Мб/сек - это примерно на пределе возможностей одиночного диска, на самом деле, в таких условиях. С доп. нагрузкой диск уже не справится.
А операционка и фс вам никак не помогут ускорить случайные чтения, размазанные по сотне гигов. Группировка чтений по 128к при отдаваемых 32к блоках - это максимум, на что можно рассчитывать.
> Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному
> использованию?Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2 -- нет, overhead на ведение журнала будет мешать честному сравнению.
А что касается сравнения связки geom_journal+UFS2+Journalled Soft-updates vs. EXT4 -- мне неизвестны результаты ни одних толковых тестов.
И вот почему: большинство "тестеров" помешаны на "искаропки". Типа, мы ничего не тюним, вот, как вендор настроил, так и тестируем.
Но в UFS2 по умолчанию не используется журналирование, так что "начинаем ходить по кругу".
Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки. Она много на что годна в таком виде, но всё же она тем и интересна многим юзерам, что в ней почти ничего по умолчанию за вас не решено, и вы можете сделать из неё то, что вам в итоге и нужно. Я с первых дней знакомства с ней много лет назад начал первым делом после установки собирать нужное мне ядро, а ядро Линукс я пересобирал за этот же срок, ну, может, раза два, причем для каких-то маловажных мелочей. Не говоря уже о десктопном применении фри и линукса. Считается, опять же, что фря - не десктопный дистриб, но, опять таки, затюнив и настроив всё, что нужно, в итоге можно получить точно такой же десктоп, как и из коробочного Линукса. The point is: фрю не зазорно тестировать после некоего тюнинга, а не из коробки.
"Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки."Ну тут кому что. Кому-то может и нравится разбираться с флагами компиляции terminfo, находить баг с невозможностью использования шифрованного раздела и проч.
Я вот лично до сих пор не могу понять, почему в sysinstall функция Exit-Cancel сделана тремя (!) разными способами: "Q", ">>>Exit" и что-то там еще.
кстати, sysinstall уже выпилен из -current, т.ч. о мертвых либо хорошо, либо ничего :).
а так вообще sysinstall на своем ноуте последний раз использовал года три назад, с тех пор только обновляю систему и порты.
ok, понял:) а что вместе него в карент?
bsdinstall
> The point is: фрю не зазорно тестировать после некоего тюнинга,
> а не из коробки.Ну да, только для _честного_ тестирования Линукс тоже неплохо было бы оттюнить, причём тем же самым человеком, который тюнил Фрю, дабы исключить ситуации "я забыл" и разный уровень квалификации, но он должен хорошо разбираться и в тюнинге Фри, и в тюнинге Линукса, что встречается в современном мире крайне редко.
Ввиду чего соревнования оттюненых операционок -- это соревнования людей, которые их тюнили, что, конечно же, не прибавляет им объективности.
>Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.Ух ты! Как же я её юзаю тогда столько лет??? И мужики-то не знают...
>> Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.
> Ух ты! Как же я её юзаю тогда столько лет???
> И мужики-то не знают...ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае, мне непонятно...
> ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае,
> мне непонятно...Это в том смысле, что в ядро не вкомпилировано? Это и нормально - если бы ядро собиралось со всеми возможными опциями, это было бы что монстроидальное. А в поставке ALTQ идет изкаропки, не надо выдумывать.
>> ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае,
>> мне непонятно...
> Это в том смысле, что в ядро не вкомпилировано? Это и
> нормально - если бы ядро собиралось со всеми возможными опциями, это
> было бы что монстроидальное. А в поставке ALTQ идет изкаропки,
> не надо выдумывать.#/etc/rc.d/pf status
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 0 days 00:00:22 Debug: Urgent#uname -sri
FreeBSD 8.2-RELEASE i386 GENERICНет его в коробке. Minimal possible install. Тянуть сорцы не вопрос, но всяко не нужно преувеличивать.
> No ALTQ support in kernelТут написано, если у кого плохо с английским, что его нет в ярде, о чем, собственно, я и говорил, если, опять же, кто-то читал через строчку.
> Нет его в коробке. Minimal possible install. Тянуть сорцы не вопрос, но
> всяко не нужно преувеличивать.ALTQ задействуется путём перекомпиляции ядра с нужными параметрами, а не загрузки исходников, о чём недвусмысленно говорит соответствующий ман: http://www.FreeBSD.org/cgi/man.cgi?query=altq&sektion=4 ...Это для тех, кто манов не читает.
Для тех, кто плохо читает по-русски, тут было написано про "из коробки".
> Для тех, кто плохо читает по-русски, тут было написано про "из коробки".А что такое искаропки для source-based системы? :-)
> о чём недвусмысленно говорит соответствующий ман: http://www.FreeBSD.org/cgi/man.cgi?query=altq&sektion=4
> Это для тех, кто манов не читает.Добавлю, "In order to use a certain discipline you have to build it into a custom kernel" никак не вяжется с "из коробки". ЧЯДНТ?
> Добавлю, "In order to use a certain discipline you have to build
> it into a custom kernel" никак не вяжется с "из коробки".Мсье любит работать на ядре GENERIC? Искаропки для source-based системы означает иметь возможность собрать что хочешь без дополнительных установок и загрузок из Сети.
> ЧЯДНТ?
Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и возможности. Это в корне неправильно - ядро будет неоправданно большим. Уже говорил выше.
> Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и
> возможности. Это в корне неправильно - ядро будет неоправданно большим.Это чему-то мешает?
>> Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и
>> возможности. Это в корне неправильно - ядро будет неоправданно большим.
> Это чему-то мешает?Что мешает? Ожидание или большое ядро? Ожидание - вам виднее. А большое ядро, уверен, что разработчики не делают не просто так, а делают ядро GENERIC именно таким по соображениям наиболее частого примерения модулей по-умолчанию. Кроме того, PF и его дополнения не родные во FreeBSD.
>> Добавлю, "In order to use a certain discipline you have to build
>> it into a custom kernel" никак не вяжется с "из коробки".
> Мсье любит работать на ядре GENERIC? Искаропки для source-based системы означает
> иметь возможность собрать что хочешь без дополнительных установок и загрузок из
> Сети.Мсье без причины не плодит зоопарки на вверенной технике. А оппонент так и не желает понять написанное доступным русским языком, где были указаны входные данные для эксперимента? За 5 минут раскатать минимальную систему на тухлый атом и ждать два часа сборки ядра или развлекаться с кросс-сборкой - это, по вашему мнению, продуктивно?
И, для информации, если плохо читали хэндбук: FreeBSD очень даже может быть и binary-based системой. Подход имеет право на жизнь.
>> ЧЯДНТ?
> Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и
> возможности. Это в корне неправильно - ядро будет неоправданно большим.
> Уже говорил выше.Из коробки - это максимум "kldload modulename".
> Мсье без причины не плодит зоопарки на вверенной технике. А оппонент так
> и не желает понять написанное доступным русским языком, где были указаны
> входные данные для эксперимента? За 5 минут раскатать минимальную систему на
> тухлый атом и ждать два часа сборки ядра или развлекаться с
> кросс-сборкой - это, по вашему мнению, продуктивно?Собранное самостоятельно ядро - это зоопарк, по-вашему? :-) На мой взгляд, лучше подождать два часа (хотя на практике это полчаса максимум), чем нагружать слабую систему излишне большим ядром, что, по моему убеждению, явное извращение - ядро-то больше раза в четыре, минимум. Может, просто лень? ;-)
> И, для информации, если плохо читали хэндбук: FreeBSD очень даже может быть
> и binary-based системой. Подход имеет право на жизнь.Может, если это своя сборка.
> Из коробки - это максимум "kldload modulename".
Не все модули можно загрузить так. В этом случае только компиляция - это сторонний модуль, портированный из другой системы.
Искаорпки для системы, означает, что названная возможность существует в дефолтно устанавливаемой системе. По-вашему, если какой-то модуль или драйвер требует настройки для работы, то он уже неискаропки? Так? Тогда ни в одной системе не существует драйверов WiFi, сетевых плат и много чего ещё искаропки только потому, что всё вышеназванное требует обязательной настройки перед работой. :-)
>> Мсье без причины не плодит зоопарки на вверенной технике. А оппонент так
>> и не желает понять написанное доступным русским языком, где были указаны
>> входные данные для эксперимента? За 5 минут раскатать минимальную систему на
>> тухлый атом и ждать два часа сборки ядра или развлекаться с
>> кросс-сборкой - это, по вашему мнению, продуктивно?
> Собранное самостоятельно ядро - это зоопарк, по-вашему? :-) На мой взгляд,
> лучше подождать два часа (хотя на практике это полчаса максимум), чем
> нагружать слабую систему излишне большим ядром, что, по моему убеждению, явное
> извращение - ядро-то больше раза в четыре, минимум. Может, просто
> лень? ;-)Пересобираю ядро только там, где это действительно нужно. BRAS, к примеру. 1 раз для всех. А для кучки разношерстных офисных мыльниц/файлопомоек/etc - GENERIC в самый раз. И обновляю бинарно без геморроя. Не стоит забывать переносимость GENERICvsCUSTOM, если уж вспоминать про размеры.
>> И, для информации, если плохо читали хэндбук: FreeBSD очень даже может быть
>> и binary-based системой. Подход имеет право на жизнь.
> Может, если это своя сборка.Ответ неверный. Собранная мейнтейнерами плюс пакеты вместо портов. да и portupgrade -PP в таком случае - приятно.
>> Из коробки - это максимум "kldload modulename".
> Не все модули можно загрузить так. В этом случае только компиляция
> - это сторонний модуль, портированный из другой системы.навскидку вспомню ALTQ и IPSEC из такого добра. упустил что-то?
> Искаорпки для системы, означает, что названная возможность существует в дефолтно устанавливаемой
> системе.я показывал выше пример дефолтной установки. с таким подходом и LFS - из коробки.
>По-вашему, если какой-то модуль или драйвер требует настройки для
> работы, то он уже неискаропки? Так? Тогда ни в
> одной системе не существует драйверов WiFi, сетевых плат и много чего
> ещё искаропки только потому, что всё вышеназванное требует обязательной настройки перед
> работой. :-)dhclient if_name - и никакой настройки. или ifconfig if_name xx.xx.xx.xx/xx. Все есть. В коробке. да и конфиг поправить вместо пересборки чего угодно - это разные вещи.
На этой ноте считаю для себя тред исчерпавшим себя, до новых встреч в эфире.
> dhclient if_name - и никакой настройки. или ifconfig if_name xx.xx.xx.xx/xx. Все есть.
> В коробке. да и конфиг поправить вместо пересборки чего угодно -
> это разные вещи.А ifconfig - это, конечно же, не настройка! :-) И dhclient if_name тоже не настройка, которая берёт данные с предварительно настроенного DHCP-сервера, который настраивается несколько дольше, чем одной командой, но его настройка - это не настройка. :-)
> На этой ноте считаю для себя тред исчерпавшим себя, до новых встреч
> в эфире.Да ради Бога!
Я тоже. Речь о том, что нет ничего такого в тюнинге перед бенчмарком, ибо в отличие от популярных дистрибутивов линукса фря поставляется в очень дефолтном состоянии, ну, скажем, ткнув пальцем в небо, флэшки автоматом не монтируются во фре по умолчанию, но это ж не значит, что фря этого не умеет, просто у линуксов и фри дефолты очень разные. Чтобы развернуть шлюз - конечно ничего менять и не надо, kldload-нуть пару модулей - и готово, и этим-то фря и хороша, что всё быстро и ничего лишнего, но тут речь про другое совсем.
при использовании geom_journal производительность падает раза в два (мерил скорость записи dd), для UFS+J (который в head) потери производительности незначительные, но сама работа как-то смущает
> при использовании geom_journal производительность падает раза в дваЖурнал, конечно же, лежал на том же физическом носителе, что и данные?
>> при использовании geom_journal производительность падает раза в два
> Журнал, конечно же, лежал на том же физическом носителе, что и данные?угу. но это был нетбук, поэтому расположить их где-то в другом месте не представлялось возможным.
а есть результаты, насколько сильно это помогает?
>>> при использовании geom_journal производительность падает раза в два
>> Журнал, конечно же, лежал на том же физическом носителе, что и данные?
> угу. но это был нетбук, поэтому расположить их где-то в другом месте
> не представлялось возможным.External USB Drive?
> а есть результаты, насколько сильно это помогает?
У меня, к сожалению, нет, только теоретические соображения и абстракции на тему параллелизма в дисковых контроллерах.
Можно попробовать в Интернете порыться на эту тему...
dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения с однопоточным синхронным IO?
> Часто ли встречаются серьезные приложения с однопоточным синхронным IO?Бэкап?-)))
> dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения
> с однопоточным синхронным IO?что-то мне подсказывает, что в случае многопоточных приложений результат будет только хуже. и уж если однопоточная запись показывает такие результаты
> geom_journal+UFS2+Journalled Soft-updatesс ума сошли)
или geom_journal+UFS2
или Journalled Soft-updates, он же SUJ, который сейчас только в 9-ке.И да, ext4 будет быстрее, уже миллионы бенчмарков делали
> с ума сошли)Запросто. Я про UFS забыл уж года три, как. :) А новости про неё читаю "по диагонали", да.
Э... ZFS?
> Э... ZFS?Конечно.
> Конечно.Кстати совсем не факт что он быстрее чем ext4 будет ;).Правда для честного сравнения надо ему полное журналирование врубить, и тогда ext4 может быть даже сольет, но это уже другой вопрос.
>> Конечно.
> Кстати совсем не факт что он быстрее чем ext4 будет ;).Кто, ZFS?
ZFS, как правило, на bulk-тестах на безвыпендрёжном оборудовании работает медленее, чем любая другая файловая система. Впрочем, как писали сами ZFS'ники, "one could be arbitrarily fast when data integrity is not in question", в этом смысле /dev/null быстрее всех работает, как на чтение, так и на запись. ;)
Понятное дело, если вынести ZIL на отдельный носитель (особенно если этот носитель будет SSD), и при наличии достаточно быстрого микропроцессора, чтобы скорость пересчёта контрольных сумм была o(скорость работы дисковой подсистемы), и гигов четырёх ОЗУ под ARC, и шахмат с поэтессами, тогда да. :)
ZFS хорош не тем, что как-то по-особенному быстро работает, а тем, что надёжно хранит данные. Причём не просто надёжно хранит данные, а надёжно хранит данные ЗАДЁШЕВО.
Время интеллектуальных дисковых контроллеров с RAID'ами потихоньку уходит в прошлое: Adaptec на своих RAID-контроллерах уже сделал "режим JBOD". Просто быстрый дисковый контроллер, безо всяких там...
ZIL на SLC-flash (сделать mirror из 32ГБ SSD)
L2ARC на MLC-flash (сделать mirror или raidz из 64ГБ SSD)
все данные на HDD (сделать raidz)
и порядок.
Да-да-да. И блэкджек. :) ARC, кстати, можно в ОЗУ положить -- 64 гектара не так и много.
> Да-да-да. И блэкджек. :) ARC, кстати, можно в ОЗУ положить -- 64 гектара не так и много.ARC и так в ОЗУ.
http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/
>> Кстати совсем не факт что он быстрее чем ext4 будет ;).
> Кто, ZFS?Конечно.
> ZFS, как правило, на bulk-тестах на безвыпендрёжном оборудовании работает медленее, чем
> любая другая файловая система.Ну для честного сравнения EXT4 надо включить полный журналинг, как раз для более-менее сравнимой целостности. И он сразу потеряеи в скорости записи в пару раз.
> этом смысле /dev/null быстрее всех работает, как на чтение, так и на запись. ;)
Ого, а вам удалось даже что-то прочитать из /dev/null?! Круто, у вас теперь есть накопитель неограниченной емкости :)
> Понятное дело, если вынести ZIL на отдельный носитель (особенно если этот носитель
> будет SSD),Проблема только в том что вы вообще можете только гадать как там этот SSD работает и насколько честно он вам сообщает про запись данных. Как вы понимаете, логика работы флеша не имеет ничего общего с обычными дисковыми операциями и контроллер SSD упирается по трансляции операций, наворачивая очень нетривиальные действия. В частности чтение-модификация-запись блоков. Насколько там оно не потеряет данные если питание отвалится не вовремя - только производитель SSD и знает.
> и при наличии достаточно быстрого микропроцессора, чтобы скорость пересчёта
> контрольных сумм была o(скорость работы дисковой подсистемы),Более странного использования O-нотации я не видел :P. Но тем не менее, современным многоядерникам не вопрос хоть 1 ядро подарить под чексуммы.
> и гигов четырёх ОЗУ под ARC, и шахмат с поэтессами, тогда да. :)
Если так рассуждать, рамдиск вообще всех порвет. И порвет. Только дорого и данные при слете питания - вылетают в трубу. Если вы не записали 4Гб данных, при слете питания вы пролетаете на 4Гб данных. Ну, если их не было на диске, значит не было.
> ZFS хорош не тем, что как-то по-особенному быстро работает, а тем, что
> надёжно хранит данные. Причём не просто надёжно хранит данные, а надёжно
> хранит данные ЗАДЁШЕВО.Насчет надежности - реализации под бзди не так уж много времени и уже появились первые набившие шишки. Что-то говорить о степени надежности конкретной реализации можно будет когда ее массово начнет использовать куча народа. А то вон ext4 был стабильным, был... а потом нашли баг который вызывает умирание всего тома. Правда, так поздно его нашли в силу крайне редкого вылезания: надо было создать очень большой файл. И осиливший это на практике и приполз в багтрекер. Но это как раз тот случай, когда редкость бага с лихвой компенсируется последствиями. У ZFS в бзде проблемы можно узреть и при намного менее экзотичных сценариях. А код сложнее. Какая у него степень протестированности? Ну вот любители "надежности хранения" потестят на своих данных и ответят нам на этот вопрос ;)
> Время интеллектуальных дисковых контроллеров с RAID'ами потихоньку уходит в прошлое: Adaptec
> на своих RAID-контроллерах уже сделал "режим JBOD". Просто быстрый дисковый контроллер,
> безо всяких там...Потому что нет большой разницы, будет ли проц на RAID контроллере или в системе. Единственное преимущество - кеш мало кушает и можно батарейкой подпереть. С другой стороны, реально критичные сервера один фиг подпирают UPSами для контролируемого шатдауна.
> > Понятное дело, если вынести ZIL на отдельный носитель (особенно если этот носитель будет SSD),
> Проблема только в том что вы вообще можете только гадать как ...
> > и гигов четырёх ОЗУ под ARC, и шахмат с поэтессами, тогда да. :)
> Если так рассуждать, рамдиск вообще всехПростите друг, но вы, похоже, не рубите в ZFS. Причём тут ARC и рамдиск?
> Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2
> -- нет, overhead на ведение журнала будет мешать честному сравнению.У журнала который журналит только метаданные - оверхед по сравнению с совсем не журналирующей ФС довольно небольшой. А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная и шустрая получилась.
> У журнала который журналит только метаданные - оверхед по сравнению с совсем
> не журналирующей ФС довольно небольшой.Смотря что делать -- 'tar xzvf linux-2.6.32.tar.gz' даже журналирование метаданных затормозит.
> А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная
> и шустрая получилась.Ну, без тестов тут сложно говорить...
> Смотря что делать -- 'tar xzvf linux-2.6.32.tar.gz' даже журналирование метаданных затормозит.На сколько то конечно затормозит, но не настолько насколько журналирование данных+метаданных. Вообще, в свежих ядрах пингвины довольно сурово шпарят. Даже XFS разогнали по части работы с метаданными. В несколько раз аж. Смотрите как дико взлетел тест PostMark на http://www.phoronix.com/scan.php?page=article&item=linux_263... в 39 ядре на XFS? Он теперь из отстающих в лидеры вырвался. А на больших файлах он всегда и был быстрым.
> Ну, без тестов тут сложно говорить...
Это да. При том желающих их проделать на одном и том же оборудовании к сожалению не так уж много. В голову приходит разве что фороникс с его странным оборудованием типа ноутбук. Если для EXT4 это понятно, то вот ZFS на всем этом? Ну понятно какие там результаты получаются. А потом местные пионеры недовольно орут. Правда, ничего лучше они предложить не могут. Древний UFS - это не ответ.
болезнь фороникса. потом также как результаты тестирования выглядят, как черный ящик
Поддерживаю. Чтобы протестить только файловую систему, неплохо бы избавиться от остальных систем. ^_^ Неплохое (немного бородатое) руководство: http://wiki.freebsd.org/BenchmarkAdvice
Это ещё вдогонку следующей новости очередной от phoronix'а.
>> способов разбиения дискаНапомню, для тех кто пропустил, начиная с какого-то недавнего времени под var и / выделяется больше места, нежели прежде. Ну, это по дефолту.
на 64-х битах при сборке ядра с дебагом не хватает места на kernel и kernel.old одновременно
>>> способов разбиения диска
> Напомню, для тех кто пропустил, начиная с какого-то недавнего времени под var
> и / выделяется больше места, нежели прежде. Ну, это по дефолту.Для однодисковых систем достаточно такой GPT-разбивки:
1 раздел: меньше мегабайта — загрузчик.
2 раздел: свободное пространство около 4 ГБ под SWAP или систему быстрого восстановления.
3 раздел: собственно, сама система со всеми своими каталогами, около 25-30 ГБ.
4 раздел: домашние каталоги пользователей, размер — у кого как.
5 раздел: архив мультимедиа высокой доступности, остальное пространство диска.Для особо въедливых с MBR-слайсом BSD-разделы такие:
ad4s1a — система, 5-10 ГБ
ad4s1b — SWAP, 1-4 ГБ
ad4s1d — /usr/local, 8 ГБ
ad4s1e — /var, 1 ГБ (зависит от предназначения системы, можно использовать на RAM-диске)
ad4s1f — /tmp, 2 ГБ (можно отказаться от дискового размещения, использовать на RAM-диске)
ad4s1g — /usr/home
ad4s1h — /archiveКаталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы, так как для них достаточно переопределить переменные окружения и не быть зажатыми в конкретных размерах разделов, да и "букв" на MBR и так мало.
> Каталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы, так
> как для них достаточно переопределить переменные окружения и не быть зажатыми
> в конкретных размерах разделов, да и "букв" на MBR и так
> мало.Перестань мучиться и используй ZFS
Там все что ты перечислил делается отдельными разделами
И кое-что что ты не перечислил :)
> Перестань мучиться и используй ZFSС 8.0-BETA использую.
> Там все что ты перечислил делается отдельными разделами
Чем-чем?
> И кое-что что ты не перечислил :)
Что?
Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по полчаса чекается. Разве это нормально?
> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
> полчаса чекается. Разве это нормально?Почему вам мешает проверка в фоне?
Дисковая подсистема тормозит. :(
> Дисковая подсистема тормозит. :(Ну мы же с вами профессионалы! ;)
Запитайте компьютер через UPS (желательно с двойным преобразованием, младшие модели стоят от 15-20 тысяч рублей), чтобы корректно всё работало и не зависело от квалификации местных электриков.
>> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
>> полчаса чекается. Разве это нормально?
> Почему вам мешает проверка в фоне?если мне память не изменяет, то проверка в фоне не приводит к исправлению ошибок - ибо том уже примонтирован на чтение-запись
>если мне память не изменяетизменяет
>>если мне память не изменяет
> изменяетпрежде чем ляпнуть, надо самому попробовать - ребутнуть комп при записи в ufs, загрузиться без проверки, а потом запустить fsck -y и посмотерть, что именно скажет fsck
когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и не таких самоуверенных бездарей выдерживал
> когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и
> не таких самоуверенных бездарей выдерживалсказал аноним. ага :)
подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл моде...
> подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл
> моде...Почти всегда требует сингл мод, особенно при падениях на интенсивных операциях ввода-вывода.
P.S. ZFS рулит!
Следующий релиз в ветке 8 будет именно такой, ну а если хотите из коробки zfc или журналирование, то берите последний дистрибутив pc-bsd и ставьте фрю, а не pc-bsd