1.1, vi_m (ok), 15:52, 27/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному использованию?
| |
|
2.2, Аноним (-), 15:59, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
ХЗ, сижу на ней. Просто всё нормально. Вроде. Вы подали мысль... Можно по бенчмаркить.
Если касательно десктопа: с другой стороны, ну что вам от производительности файловой системы?
| |
|
3.6, Andrew Kolchoogin (?), 16:04, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
> системы?
Ну как же ж.
DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
| |
|
4.7, Аноним (-), 16:08, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
А, ну это полюбому. :)
У меня отдельный девайс файлы качает. :)
| |
4.13, XoRe (ok), 16:31, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>> системы?
> Ну как же ж.
> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
10 метров в секунду?)
| |
|
5.18, Andrew Kolchoogin (?), 16:48, 27/05/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> Если касательно десктопа: с другой стороны, ну что вам от производительности файловой
>>> системы?
>> Ну как же ж.
>> DC++ на стамегабитной локалке. :) Можно и в производительность диска упереться. :)
> 10 метров в секунду?)
Да легко! :)
Не каждый диск такое выдержит (просьба не апеллировать к заявленной производителем пропускной способности: мы же не посекторно на HDD информацию заливаем).
| |
|
6.43, Аноним (-), 01:51, 28/05/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Не каждый диск такое выдержит
Типовая линейная скорость чтения современного диска - около 100-150Мб/сек. Затормозить его до 10Мб/сек еще постараться надо. Для этого операционка, ФС и остальные должны ну совсем никак не пытаться оптимизировать доступ к диску.
| |
|
7.55, Stax (ok), 21:09, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
К примеру, если вы посмотрите на работу торрент-клинтов, то увидите, что они обычно читают блоками по 128kb. Типичный блок, отдаваемый в торренте за раз - 32k. Хотя иногда получается читать большими блоками, но обычно при увеличении объема и количество раздач все переходит к тем самым 128k чтениями (писать, при хорошей буферизации, получается большими блоками, вплоть до мегабайта). Зависимость блоков чтения от объема раздач хорошо видно по статистике azureus. В utorrent чтение всегда по 128kb, а в остальных типа transmission можете помониторить iostat'ом и аналогичными.
Теперь представьте, у вас 100 гб раздач (а бывает и куда больше). В целом это раздается нескольким сотням клиентов. И с какой скоростью ЖД способен отдавать данные в полностью случайных чтениях (100 гб и много клиентов => запросы идут все время в разные части диска) блоками по 128 кб? 10 Мб/сек - это примерно на пределе возможностей одиночного диска, на самом деле, в таких условиях. С доп. нагрузкой диск уже не справится.
А операционка и фс вам никак не помогут ускорить случайные чтения, размазанные по сотне гигов. Группировка чтений по 128к при отдаваемых 32к блоках - это максимум, на что можно рассчитывать.
| |
|
|
|
|
|
2.4, Andrew Kolchoogin (?), 16:02, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Как она по сравнению с ext4, только не по форониксовским бенчмаркам, а по реальному
> использованию?
Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2 -- нет, overhead на ведение журнала будет мешать честному сравнению.
А что касается сравнения связки geom_journal+UFS2+Journalled Soft-updates vs. EXT4 -- мне неизвестны результаты ни одних толковых тестов.
И вот почему: большинство "тестеров" помешаны на "искаропки". Типа, мы ничего не тюним, вот, как вендор настроил, так и тестируем.
Но в UFS2 по умолчанию не используется журналирование, так что "начинаем ходить по кругу".
| |
|
3.9, Bocha (??), 16:09, 27/05/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки. Она много на что годна в таком виде, но всё же она тем и интересна многим юзерам, что в ней почти ничего по умолчанию за вас не решено, и вы можете сделать из неё то, что вам в итоге и нужно. Я с первых дней знакомства с ней много лет назад начал первым делом после установки собирать нужное мне ядро, а ядро Линукс я пересобирал за этот же срок, ну, может, раза два, причем для каких-то маловажных мелочей. Не говоря уже о десктопном применении фри и линукса. Считается, опять же, что фря - не десктопный дистриб, но, опять таки, затюнив и настроив всё, что нужно, в итоге можно получить точно такой же десктоп, как и из коробочного Линукса. The point is: фрю не зазорно тестировать после некоего тюнинга, а не из коробки.
| |
|
4.12, crypt (??), 16:21, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
"Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки."
Ну тут кому что. Кому-то может и нравится разбираться с флагами компиляции terminfo, находить баг с невозможностью использования шифрованного раздела и проч.
Я вот лично до сих пор не могу понять, почему в sysinstall функция Exit-Cancel сделана тремя (!) разными способами: "Q", ">>>Exit" и что-то там еще.
| |
|
5.38, 1 (??), 21:49, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
кстати, sysinstall уже выпилен из -current, т.ч. о мертвых либо хорошо, либо ничего :).
а так вообще sysinstall на своем ноуте последний раз использовал года три назад, с тех пор только обновляю систему и порты.
| |
|
4.16, Andrew Kolchoogin (?), 16:46, 27/05/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
> The point is: фрю не зазорно тестировать после некоего тюнинга,
> а не из коробки.
Ну да, только для _честного_ тестирования Линукс тоже неплохо было бы оттюнить, причём тем же самым человеком, который тюнил Фрю, дабы исключить ситуации "я забыл" и разный уровень квалификации, но он должен хорошо разбираться и в тюнинге Фри, и в тюнинге Линукса, что встречается в современном мире крайне редко.
Ввиду чего соревнования оттюненых операционок -- это соревнования людей, которые их тюнили, что, конечно же, не прибавляет им объективности.
| |
4.25, Ян Злобин (ok), 17:04, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.
Ух ты! Как же я её юзаю тогда столько лет??? И мужики-то не знают...
| |
|
5.29, Andrew Kolchoogin (?), 17:57, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Ну с другой стороны фря - не совсем та система, которую следуют юзать прям из коробки.
> Ух ты! Как же я её юзаю тогда столько лет???
> И мужики-то не знают...
ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае, мне непонятно...
| |
|
6.47, Ян Злобин (ok), 04:44, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> ALTQ, сабака, фкаропке не поставляется. Совершенно непонятно, почему, во всяком случае,
> мне непонятно...
Это в том смысле, что в ядро не вкомпилировано? Это и нормально - если бы ядро собиралось со всеми возможными опциями, это было бы что монстроидальное. А в поставке ALTQ идет изкаропки, не надо выдумывать.
| |
|
7.62, mr_gfd (?), 00:27, 30/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> 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. Тянуть сорцы не вопрос, но всяко не нужно преувеличивать.
| |
|
|
9.67, mr_gfd (?), 15:06, 30/05/2011 [^] [^^] [^^^] [ответить] | +/– | Добавлю, In order to use a certain discipline you have to build it into a custo... текст свёрнут, показать | |
|
|
|
|
13.74, mr_gfd (?), 16:18, 30/05/2011 [^] [^^] [^^^] [ответить] | +/– | Пересобираю ядро только там, где это действительно нужно BRAS, к примеру 1 раз... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
5.34, Bocha (??), 20:17, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
Я тоже. Речь о том, что нет ничего такого в тюнинге перед бенчмарком, ибо в отличие от популярных дистрибутивов линукса фря поставляется в очень дефолтном состоянии, ну, скажем, ткнув пальцем в небо, флэшки автоматом не монтируются во фре по умолчанию, но это ж не значит, что фря этого не умеет, просто у линуксов и фри дефолты очень разные. Чтобы развернуть шлюз - конечно ничего менять и не надо, kldload-нуть пару модулей - и готово, и этим-то фря и хороша, что всё быстро и ничего лишнего, но тут речь про другое совсем.
| |
|
|
3.10, arachnid (ok), 16:15, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
при использовании geom_journal производительность падает раза в два (мерил скорость записи dd), для UFS+J (который в head) потери производительности незначительные, но сама работа как-то смущает
| |
|
4.15, Andrew Kolchoogin (?), 16:43, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> при использовании geom_journal производительность падает раза в два
Журнал, конечно же, лежал на том же физическом носителе, что и данные?
| |
|
5.24, arachnid (ok), 17:02, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> при использовании geom_journal производительность падает раза в два
> Журнал, конечно же, лежал на том же физическом носителе, что и данные?
угу. но это был нетбук, поэтому расположить их где-то в другом месте не представлялось возможным.
а есть результаты, насколько сильно это помогает?
| |
|
6.28, Andrew Kolchoogin (?), 17:56, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>> при использовании geom_journal производительность падает раза в два
>> Журнал, конечно же, лежал на том же физическом носителе, что и данные?
> угу. но это был нетбук, поэтому расположить их где-то в другом месте
> не представлялось возможным.
External USB Drive?
> а есть результаты, насколько сильно это помогает?
У меня, к сожалению, нет, только теоретические соображения и абстракции на тему параллелизма в дисковых контроллерах.
Можно попробовать в Интернете порыться на эту тему...
| |
|
|
4.19, Аноним (-), 16:51, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения с однопоточным синхронным IO?
| |
|
5.26, arachnid (ok), 17:05, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> dd, конечно-же, очень реалистичный IO-тест, правда? Часто ли встречаются серьезные приложения
> с однопоточным синхронным IO?
что-то мне подсказывает, что в случае многопоточных приложений результат будет только хуже. и уж если однопоточная запись показывает такие результаты
| |
|
|
3.17, oops (ok), 16:46, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> geom_journal+UFS2+Journalled Soft-updates
с ума сошли)
или geom_journal+UFS2
или Journalled Soft-updates, он же SUJ, который сейчас только в 9-ке.
И да, ext4 будет быстрее, уже миллионы бенчмарков делали
| |
|
|
|
|
7.31, Аноним (-), 18:52, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Конечно.
Кстати совсем не факт что он быстрее чем ext4 будет ;).Правда для честного сравнения надо ему полное журналирование врубить, и тогда ext4 может быть даже сольет, но это уже другой вопрос.
| |
|
|
9.41, iZEN (ok), 00:41, 28/05/2011 [^] [^^] [^^^] [ответить] | +/– | ZIL на SLC-flash сделать mirror из 32ГБ SSD L2ARC на MLC-flash сделать mirror... текст свёрнут, показать | |
9.44, Аноним (-), 02:29, 28/05/2011 [^] [^^] [^^^] [ответить] | –1 +/– | Конечно Ну для честного сравнения EXT4 надо включить полный журналинг, как раз... большой текст свёрнут, показать | |
|
|
|
|
|
|
3.30, Аноним (-), 18:46, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Сравнивать UFS2 и EXT4 "вот так вот просто" некорректно: EXT4 журналируемая, UFS2
> -- нет, overhead на ведение журнала будет мешать честному сравнению.
У журнала который журналит только метаданные - оверхед по сравнению с совсем не журналирующей ФС довольно небольшой. А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная и шустрая получилась.
| |
|
4.32, Andrew Kolchoogin (?), 19:52, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> У журнала который журналит только метаданные - оверхед по сравнению с совсем
> не журналирующей ФС довольно небольшой.
Смотря что делать -- 'tar xzvf linux-2.6.32.tar.gz' даже журналирование метаданных затормозит.
> А за счет экстентов у EXT4 еще и фора будет. Она вообще довольно приятная
> и шустрая получилась.
Ну, без тестов тут сложно говорить...
| |
|
5.45, Аноним (-), 02:39, 28/05/2011 [^] [^^] [^^^] [ответить] | +/– | На сколько то конечно затормозит, но не настолько насколько журналирование данны... большой текст свёрнут, показать | |
|
|
3.40, Карбофос (ok), 00:40, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
болезнь фороникса. потом также как результаты тестирования выглядят, как черный ящик
| |
|
|
1.3, Аноним (-), 16:01, 27/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>> способов разбиения диска
Напомню, для тех кто пропустил, начиная с какого-то недавнего времени под var и / выделяется больше места, нежели прежде. Ну, это по дефолту.
| |
|
|
Часть нити удалена модератором |
3.14, anonymous (??), 16:35, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
на 64-х битах при сборке ядра с дебагом не хватает места на kernel и kernel.old одновременно
| |
|
2.51, iZEN (ok), 12:15, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>> способов разбиения диска
> Напомню, для тех кто пропустил, начиная с какого-то недавнего времени под 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.56, odus (ok), 22:36, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Каталоги /usr/obj, /usr/ports и /usr/ports/distfiles не выношу на отдельные разделы, так
> как для них достаточно переопределить переменные окружения и не быть зажатыми
> в конкретных размерах разделов, да и "букв" на MBR и так
> мало.
Перестань мучиться и используй ZFS
Там все что ты перечислил делается отдельными разделами
И кое-что что ты не перечислил :)
| |
|
4.58, iZEN (ok), 10:55, 29/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Перестань мучиться и используй ZFS
С 8.0-BETA использую.
> Там все что ты перечислил делается отдельными разделами
Чем-чем?
> И кое-что что ты не перечислил :)
Что?
| |
|
|
|
1.35, Анори (?), 21:04, 27/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по полчаса чекается. Разве это нормально?
| |
|
2.37, zazik (ok), 21:42, 27/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
> полчаса чекается. Разве это нормально?
Почему вам мешает проверка в фоне?
| |
|
|
4.50, iZEN (ok), 12:05, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Дисковая подсистема тормозит. :(
Ну мы же с вами профессионалы! ;)
Запитайте компьютер через UPS (желательно с двойным преобразованием, младшие модели стоят от 15-20 тысяч рублей), чтобы корректно всё работало и не зависело от квалификации местных электриков.
| |
|
3.52, arachnid (ok), 12:25, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Гы, когда FreeBSD журналирование сделают по-умолчанию из коробки? После креша диск по
>> полчаса чекается. Разве это нормально?
> Почему вам мешает проверка в фоне?
если мне память не изменяет, то проверка в фоне не приводит к исправлению ошибок - ибо том уже примонтирован на чтение-запись
| |
|
|
5.54, arachnid (ok), 16:56, 28/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>если мне память не изменяет
> изменяет
прежде чем ляпнуть, надо самому попробовать - ребутнуть комп при записи в ufs, загрузиться без проверки, а потом запустить fsck -y и посмотерть, что именно скажет fsck
| |
|
6.57, Аноним (-), 08:50, 29/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и не таких самоуверенных бездарей выдерживал
| |
|
7.59, arachnid (ok), 11:03, 29/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> когда вы что-то не знаете точно - пишите анонимно, этот гранфаллон и
> не таких самоуверенных бездарей выдерживал
сказал аноним. ага :)
| |
|
|
|
4.61, fidaj (ok), 21:00, 29/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл моде...
| |
|
5.76, universite (ok), 22:02, 15/06/2011 [^] [^^] [^^^] [ответить]
| +/– |
> подтверждаю. не всегда приводит к исправлению... иногда (в тяжёлых случаях) требует сингл
> моде...
Почти всегда требует сингл мод, особенно при падениях на интенсивных операциях ввода-вывода.
P.S. ZFS рулит!
| |
|
|
|
|
1.36, Сергей (??), 21:16, 27/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Следующий релиз в ветке 8 будет именно такой, ну а если хотите из коробки zfc или журналирование, то берите последний дистрибутив pc-bsd и ставьте фрю, а не pc-bsd
| |
|