The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от opennews (ok) on 27-Май-11, 15:52 
Вчера во 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=30686

Ответить | Правка | Cообщить модератору

Оглавление

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


1. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +3 +/
Сообщение от vi_m (ok) on 27-Май-11, 15:52 
Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному использованию?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 15:59 
ХЗ, сижу на ней. Просто всё нормально. Вроде. Вы подали мысль... Можно по бенчмаркить.
Если касательно десктопа: с другой стороны, ну что вам от производительности файловой системы?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:04 
> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
> системы?

Ну как же ж.

DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

7. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 16:08 
А, ну это полюбому. :)
У меня отдельный девайс файлы качает. :)
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

13. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от XoRe (ok) on 27-Май-11, 16:31 
>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>> системы?
> Ну как же ж.
> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)

10 метров в секунду?)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

18. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +1 +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:48 
>>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>>> системы?
>> Ну как же ж.
>> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
> 10 метров в секунду?)

Да легко! :)

Не каждый диск такое выдержит (просьба не апеллировать к заявленной производителем пропускной способности: мы же не посекторно на HDD информацию заливаем).

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

43. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +1 +/
Сообщение от Аноним (??) on 28-Май-11, 01:51 
> Не каждый диск такое выдержит

Типовая линейная скорость чтения современного диска - около 100-150Мб/сек. Затормозить его до 10Мб/сек еще постараться надо. Для этого операционка, ФС и остальные должны ну совсем никак не пытаться оптимизировать доступ к диску.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

55. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Stax (ok) on 28-Май-11, 21:09 
К примеру, если вы посмотрите на работу торрент-клинтов, то увидите, что они обычно читают блоками по 128kb. Типичный блок, отдаваемый в торренте за раз - 32k. Хотя иногда получается читать большими блоками, но обычно при увеличении объема и количество раздач все переходит к тем самым 128k чтениями (писать, при хорошей буферизации, получается большими блоками, вплоть до мегабайта). Зависимость блоков чтения от объема раздач хорошо видно по статистике azureus. В utorrent чтение всегда по 128kb, а в остальных типа transmission можете помониторить iostat'ом и аналогичными.

Теперь представьте, у вас 100 гб раздач (а бывает и куда больше). В целом это раздается нескольким сотням клиентов. И с какой скоростью ЖД способен отдавать данные в полностью случайных чтениях (100 гб и много клиентов => запросы идут все время в разные части диска) блоками по 128 кб? 10 Мб/сек - это примерно на пределе возможностей одиночного диска, на самом деле, в таких условиях. С доп. нагрузкой диск уже не справится.

А операционка и фс вам никак не помогут ускорить случайные чтения, размазанные по сотне гигов. Группировка чтений по 128к при отдаваемых 32к блоках - это максимум, на что можно рассчитывать.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

4. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:02 
> Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному
> использованию?

Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2 -- нет, overhead на ведение журнала будет мешать честному сравнению.
А что касается сравнения связки geom_journal+UFS2+Journalled Soft-updates vs. EXT4 -- мне неизвестны результаты ни одних толковых тестов.
И вот почему: большинство "тестеров" помешаны на "искаропки". Типа, мы ничего не тюним, вот, как вендор настроил, так и тестируем.
Но в UFS2 по умолчанию не используется журналирование, так что "начинаем ходить по кругу".

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +2 +/
Сообщение от Bocha email(??) on 27-Май-11, 16:09 
Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки. Она много на что годна в таком виде, но всё же она тем и интересна многим юзерам, что в ней почти ничего по умолчанию за вас не решено, и вы можете сделать из неё то, что вам в итоге и нужно. Я с первых дней знакомства с ней много лет назад начал первым делом после установки собирать нужное мне ядро, а ядро Линукс я пересобирал за этот же срок, ну, может, раза два, причем для каких-то маловажных мелочей. Не говоря уже о десктопном применении фри и линукса. Считается, опять же, что фря - не десктопный дистриб, но, опять таки, затюнив и настроив всё, что нужно, в итоге можно получить точно такой же десктоп, как и из коробочного Линукса. The point is: фрю не зазорно тестировать после некоего тюнинга, а не из коробки.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от crypt (??) on 27-Май-11, 16:21 
"Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки."

Ну тут кому что. Кому-то может и нравится разбираться с флагами компиляции terminfo, находить баг с невозможностью использования шифрованного раздела и проч.
Я вот лично до сих пор не могу понять, почему в sysinstall функция Exit-Cancel сделана тремя (!) разными способами: "Q", ">>>Exit" и что-то там еще.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

38. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от 1 (??) on 27-Май-11, 21:49 
кстати, sysinstall уже выпилен из -current, т.ч. о мертвых либо хорошо, либо ничего :).
а так вообще sysinstall на своем ноуте последний раз использовал года три назад, с тех пор только обновляю систему и порты.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

39. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от crypt (??) on 27-Май-11, 22:53 
ok, понял:) а что вместе него в карент?
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

60. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от fidaj (ok) on 29-Май-11, 20:53 
bsdinstall
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

16. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +4 +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:46 
> The point is: фрю не зазорно тестировать после некоего тюнинга,
> а не из коробки.

Ну да, только для _честного_ тестирования Линукс тоже неплохо было бы оттюнить, причём тем же самым человеком, который тюнил Фрю, дабы исключить ситуации "я забыл" и разный уровень квалификации, но он должен хорошо разбираться и в тюнинге Фри, и в тюнинге Линукса, что встречается в современном мире крайне редко.

Ввиду чего соревнования оттюненых операционок -- это соревнования людей, которые их тюнили, что, конечно же, не прибавляет им объективности.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

25. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 27-Май-11, 17:04 
>Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.

Ух ты!  Как же я её юзаю тогда столько лет???  И мужики-то не знают...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

29. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 17:57 
>> Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.
> Ух ты!  Как же я её юзаю тогда столько лет???  
> И мужики-то не знают...

ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае, мне непонятно...

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

47. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 28-Май-11, 04:44 
> ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае,
> мне непонятно...

Это в том смысле, что в ядро не вкомпилировано?  Это и нормально - если бы ядро собиралось со всеми возможными опциями, это было бы что монстроидальное.  А в поставке ALTQ идет изкаропки, не надо выдумывать.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

62. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от mr_gfd on 30-Май-11, 00:27 
>> 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. Тянуть сорцы не вопрос, но всяко не нужно преувеличивать.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

64. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 06:51 
> No ALTQ support in kernel

Тут написано, если у кого плохо с английским, что его нет в ярде, о чем, собственно, я и говорил, если, опять же, кто-то читал через строчку.

> Нет его в коробке. Minimal possible install. Тянуть сорцы не вопрос, но
> всяко не нужно преувеличивать.

ALTQ задействуется путём перекомпиляции ядра с нужными параметрами, а не загрузки исходников, о чём недвусмысленно говорит соответствующий ман: http://www.FreeBSD.org/cgi/man.cgi?query=altq&sektion=4 ...Это для тех, кто манов не читает.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

66. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от mr_gfd on 30-Май-11, 14:54 
Для тех, кто плохо читает по-русски, тут было написано про "из коробки".
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

68. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 15:23 
> Для тех, кто плохо читает по-русски, тут было написано про "из коробки".

А что такое искаропки для source-based системы? :-)

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

67. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от mr_gfd on 30-Май-11, 15:06 
> о чём недвусмысленно говорит соответствующий ман: 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" никак не вяжется с "из коробки". ЧЯДНТ?

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

69. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 15:27 
> Добавлю, "In order to use a certain discipline you have to build
> it into a custom kernel" никак не вяжется с "из коробки".

Мсье любит работать на ядре GENERIC?  Искаропки для source-based системы означает иметь возможность собрать что хочешь без дополнительных установок и загрузок из Сети.

> ЧЯДНТ?

Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и возможности.  Это в корне неправильно - ядро будет неоправданно большим.  Уже говорил выше.

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

70. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrey Mitrofanov on 30-Май-11, 15:34 
> Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и
> возможности.  Это в корне неправильно - ядро будет неоправданно большим.

Это чему-то мешает?

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

72. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 15:38 
>> Вероятно, ожидаете, что в ядро GENERIC будут включены все возможные модули и
>> возможности.  Это в корне неправильно - ядро будет неоправданно большим.
> Это чему-то мешает?

Что мешает?  Ожидание или большое ядро?  Ожидание - вам виднее. А большое ядро, уверен, что разработчики не делают не просто так, а делают ядро GENERIC именно таким по соображениям наиболее частого примерения модулей по-умолчанию.  Кроме того, PF и его дополнения не родные во FreeBSD.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

71. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от mr_gfd on 30-Май-11, 15:34 
>> Добавлю, "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".

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

73. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 15:46 
> Мсье без причины не плодит зоопарки на вверенной технике. А оппонент так
> и не желает понять написанное доступным русским языком, где были указаны
> входные данные для эксперимента? За 5 минут раскатать минимальную систему на
> тухлый атом и ждать два часа сборки ядра или развлекаться с
> кросс-сборкой - это, по вашему мнению, продуктивно?

Собранное самостоятельно ядро - это зоопарк, по-вашему? :-)  На мой взгляд, лучше подождать два часа (хотя на практике это полчаса максимум), чем нагружать слабую систему излишне большим ядром, что, по моему убеждению, явное извращение - ядро-то больше раза в четыре, минимум.  Может, просто лень? ;-)

> И, для информации, если плохо читали хэндбук: FreeBSD очень даже может быть
> и binary-based системой. Подход имеет право на жизнь.

Может, если это своя сборка.

> Из коробки - это максимум "kldload modulename".

Не все модули можно загрузить так.  В этом случае только компиляция - это сторонний модуль, портированный из другой системы.

Искаорпки для системы, означает, что названная возможность существует в дефолтно устанавливаемой системе.  По-вашему, если какой-то модуль или драйвер требует настройки для работы, то он уже неискаропки?  Так?  Тогда ни в одной системе не существует драйверов WiFi, сетевых плат и много чего ещё искаропки только потому, что всё вышеназванное требует обязательной настройки перед работой. :-)

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

74. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от mr_gfd on 30-Май-11, 16:18 
>> Мсье без причины не плодит зоопарки на вверенной технике. А оппонент так
>> и не желает понять написанное доступным русским языком, где были указаны
>> входные данные для эксперимента? За 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. Все есть. В коробке. да и конфиг поправить вместо пересборки чего угодно - это разные вещи.

На этой ноте считаю для себя тред исчерпавшим себя, до новых встреч в эфире.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

75. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Ян Злобин email(ok) on 30-Май-11, 16:35 
> dhclient if_name - и никакой настройки. или ifconfig if_name xx.xx.xx.xx/xx. Все есть.
> В коробке. да и конфиг поправить вместо пересборки чего угодно -
> это разные вещи.

А ifconfig - это, конечно же, не настройка! :-)  И dhclient if_name тоже не настройка, которая берёт данные с предварительно настроенного DHCP-сервера, который настраивается несколько дольше, чем одной командой, но его настройка - это не настройка. :-)

> На этой ноте считаю для себя тред исчерпавшим себя, до новых встреч
> в эфире.

Да ради Бога!

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

34. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Bocha email(??) on 27-Май-11, 20:17 
Я тоже. Речь о том, что нет ничего такого в тюнинге перед бенчмарком, ибо в отличие от популярных дистрибутивов линукса фря поставляется в очень дефолтном состоянии, ну, скажем, ткнув пальцем в небо, флэшки автоматом не монтируются во фре по умолчанию, но это ж не значит, что фря этого не умеет, просто у линуксов и фри дефолты очень разные. Чтобы развернуть шлюз - конечно ничего менять и не надо, kldload-нуть пару модулей - и готово, и этим-то фря и хороша, что всё быстро и ничего лишнего, но тут речь про другое совсем.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

10. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 27-Май-11, 16:15 
при использовании geom_journal производительность падает раза в два (мерил скорость записи dd), для UFS+J (который в head) потери производительности незначительные, но сама работа как-то смущает
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

15. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:43 
> при использовании geom_journal производительность падает раза в два

Журнал, конечно же, лежал на том же физическом носителе, что и данные?

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

24. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 27-Май-11, 17:02 
>> при использовании geom_journal производительность падает раза в два
> Журнал, конечно же, лежал на том же физическом носителе, что и данные?

угу. но это был нетбук, поэтому расположить их где-то в другом месте не представлялось возможным.

а есть результаты, насколько сильно это помогает?


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 17:56 
>>> при использовании geom_journal производительность падает раза в два
>> Журнал, конечно же, лежал на том же физическом носителе, что и данные?
> угу. но это был нетбук, поэтому расположить их где-то в другом месте
> не представлялось возможным.

External USB Drive?

> а есть результаты, насколько сильно это помогает?

У меня, к сожалению, нет, только теоретические соображения и абстракции на тему параллелизма в дисковых контроллерах.

Можно попробовать в Интернете порыться на эту тему...

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

19. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 16:51 
dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения с однопоточным синхронным IO?
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

22. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:56 
> Часто ли встречаются серьезные приложения с однопоточным синхронным IO?

Бэкап?-)))

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

26. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 27-Май-11, 17:05 
> dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения
> с однопоточным синхронным IO?

что-то мне подсказывает, что в случае многопоточных приложений результат будет только хуже. и уж если однопоточная запись показывает такие результаты

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

17. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от oops (ok) on 27-Май-11, 16:46 
> geom_journal+UFS2+Journalled Soft-updates

с ума сошли)
или geom_journal+UFS2
или Journalled Soft-updates, он же SUJ, который сейчас только в 9-ке.

И да, ext4 будет быстрее, уже миллионы бенчмарков делали

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

20. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 16:55 
> с ума сошли)

Запросто. Я про UFS забыл уж года три, как. :) А новости про неё читаю "по диагонали", да.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 16:57 
Э... ZFS?
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 17:55 
> Э... ZFS?

Конечно.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

31. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 18:52 
> Конечно.

Кстати совсем не факт что он быстрее чем ext4 будет ;).Правда для честного сравнения надо ему полное журналирование врубить, и тогда ext4 может быть даже сольет, но это уже другой вопрос.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 19:59 
>> Конечно.
> Кстати совсем не факт что он быстрее чем 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". Просто быстрый дисковый контроллер, безо всяких там...

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

41. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от iZEN (ok) on 28-Май-11, 00:41 
ZIL на SLC-flash (сделать mirror из 32ГБ SSD)
L2ARC на MLC-flash (сделать mirror или raidz из 64ГБ SSD)
все данные на HDD (сделать raidz)
и порядок.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

42. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 28-Май-11, 00:57 
Да-да-да. И блэкджек. :) ARC, кстати, можно в ОЗУ положить -- 64 гектара не так и много.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

49. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от iZEN (ok) on 28-Май-11, 09:18 
> Да-да-да. И блэкджек. :) ARC, кстати, можно в ОЗУ положить -- 64 гектара не так и много.

ARC и так в ОЗУ.

http://blog.tigranav.ru/2010/11/obyasnenie-arc-i-l2arc/

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

44. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  –1 +/
Сообщение от Аноним (??) on 28-Май-11, 02:29 
>> Кстати совсем не факт что он быстрее чем 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ами для контролируемого шатдауна.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

46. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 28-Май-11, 03:56 
> > Понятное дело, если вынести ZIL на отдельный носитель (особенно если этот носитель будет SSD),
> Проблема только в том что вы вообще можете только гадать как ...
> > и гигов четырёх ОЗУ под ARC, и шахмат с поэтессами, тогда да. :)
> Если так рассуждать, рамдиск вообще всех

Простите друг, но вы, похоже, не рубите в ZFS. Причём тут ARC и рамдиск?

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

30. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 18:46 
> Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2
> -- нет, overhead на ведение журнала будет мешать честному сравнению.

У журнала который журналит только метаданные - оверхед по сравнению с совсем не журналирующей ФС довольно небольшой. А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная и шустрая получилась.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

32. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Andrew Kolchoogin on 27-Май-11, 19:52 
> У журнала который журналит только метаданные - оверхед по сравнению с совсем
> не журналирующей ФС довольно небольшой.

Смотря что делать -- 'tar xzvf linux-2.6.32.tar.gz' даже журналирование метаданных затормозит.

> А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная
> и шустрая получилась.

Ну, без тестов тут сложно говорить...

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

45. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 28-Май-11, 02:39 
> Смотря что делать -- '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 - это не ответ.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

40. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Карбофос (ok) on 28-Май-11, 00:40 
болезнь фороникса. потом также как результаты тестирования выглядят, как черный ящик
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

65. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 30-Май-11, 10:03 
Поддерживаю. Чтобы протестить только файловую систему, неплохо бы избавиться от остальных систем. ^_^ Неплохое (немного бородатое) руководство: http://wiki.freebsd.org/BenchmarkAdvice
Это ещё вдогонку следующей новости очередной от phoronix'а.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 27-Май-11, 16:01 
>> способов разбиения диска

Напомню, для тех кто пропустил, начиная с какого-то недавнего времени под var и / выделяется больше места, нежели прежде. Ну, это по дефолту.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от anonymous (??) on 27-Май-11, 16:35 
на 64-х битах при сборке ядра с дебагом не хватает места на kernel и kernel.old одновременно
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

51. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от iZEN (ok) on 28-Май-11, 12:15 
>>> способов разбиения диска
> Напомню, для тех кто пропустил, начиная с какого-то недавнего времени под 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 и так мало.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

56. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от odus (ok) on 28-Май-11, 22:36 
> Каталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы, так
> как для них достаточно переопределить переменные окружения и не быть зажатыми
> в конкретных размерах разделов, да и "букв" на MBR и так
> мало.

Перестань мучиться и используй ZFS
Там все что ты перечислил делается отдельными разделами
И кое-что что ты не перечислил :)

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

58. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от iZEN (ok) on 29-Май-11, 10:55 
> Перестань мучиться и используй ZFS

С 8.0-BETA использую.

> Там все что ты перечислил делается отдельными разделами

Чем-чем?

> И кое-что что ты не перечислил :)

Что?


Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

35. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +1 +/
Сообщение от Анори on 27-Май-11, 21:04 
Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по полчаса чекается. Разве это нормально?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от zazik (ok) on 27-Май-11, 21:42 
> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
> полчаса чекается. Разве это нормально?

Почему вам мешает проверка в фоне?

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

48. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от drTr0jan on 28-Май-11, 04:56 
Дисковая подсистема тормозит. :(
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

50. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от iZEN (ok) on 28-Май-11, 12:05 
> Дисковая подсистема тормозит. :(

Ну мы же с вами профессионалы! ;)
Запитайте компьютер через UPS (желательно с двойным преобразованием, младшие модели стоят от 15-20 тысяч рублей), чтобы корректно всё работало и не зависело от квалификации местных электриков.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

52. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 28-Май-11, 12:25 
>> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
>> полчаса чекается. Разве это нормально?
> Почему вам мешает проверка в фоне?

если мне память не изменяет, то проверка в фоне не приводит к исправлению ошибок - ибо том уже примонтирован на чтение-запись

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

53. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 28-Май-11, 13:39 
>если мне память не изменяет

изменяет

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

54. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 28-Май-11, 16:56 
>>если мне память не изменяет
> изменяет

прежде чем ляпнуть, надо самому попробовать - ребутнуть комп при записи в ufs, загрузиться без проверки, а потом запустить fsck -y и посмотерть, что именно скажет fsck

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

57. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Аноним (??) on 29-Май-11, 08:50 
когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и не таких самоуверенных бездарей выдерживал
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

59. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от arachnid (ok) on 29-Май-11, 11:03 
> когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и
> не таких самоуверенных бездарей выдерживал

сказал аноним. ага :)

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

61. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от fidaj (ok) on 29-Май-11, 21:00 
подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл моде...
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

76. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от universite email(ok) on 15-Июн-11, 22:02 
> подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл
> моде...

Почти всегда требует сингл мод, особенно при падениях на интенсивных операциях ввода-вывода.

P.S. ZFS рулит!

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

36. "Во FreeBSD увеличен размер блока по умолчанию в файловой сис..."  +/
Сообщение от Сергей (??) on 27-Май-11, 21:16 
Следующий релиз в ветке 8 будет именно такой, ну а если хотите из коробки zfc или журналирование, то берите последний дистрибутив pc-bsd и ставьте фрю, а не pc-bsd
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру