Чего под FreeBSD делать не стоит?

бинарные дистры (типа бубунты) такого не позволяют сделать они в лучшем случае позволяют выжать из железа половину его мощности.

И никаких доказательств этого утверждения у вас, конечно, нет.

Сбрасывать железные проблемы на софт - это очень просто и полезно.

битый образ фряхи

Вот так потом и распространяются слухи.
Ещё когда установщиком был сисинстолл, проверка чексумм была в фре при установке.

*facepalm*

zfs, устойчивая, надежная

Ну нельзя эти слова в одном предложении без отрицания использовать, нельзя.

Уровень вхождения в каждом юниксе плюс-минус одинаковый.

Лол, ты искать плохие отзывы где пробовал? В /dev/zero?

Эта ось использует железо более в полной мере, чем Linux, раз лишь под ней проблемы

больше жира, больше!

ООООооооочччееень толсто, но есть вероятность, что ты что то неверно собрал, то есть таки твои руки действительно кривы.

5 лет со фряхой на десктопе, первый раз слышу про какой-то там авторестарт и проблемы с ntfs-3g (правда, я его редко использую)

Плюсую, на десктопе фряха намного круче линакса, весь софт собирает под твое железо, все это делается намного проще чем в генте, да и сама система очень простая и хорошо документирована, плюс годная лицензия BSD свободнее для пользователя, нежели GPL.

Не стоит делать из FreeBSD линукс, и тогда не будет описанных выше проблем.

Столько жира в одном сообщении.

А люди, характеризующие ПО словом «круче», с потрохами выдают в себе школьника.

И в каком же месте автор делал из фряшки GNU/Linux?

Люди детектирующие школьника выдают с потрохами в себе школьника, так же как и люди фанатично относящиеся к ПО, постельному белью, рабочим инструментам, политическим идеям выдают с потрохами в себе долбо-бов.

ООООооооочччееень толсто, но есть вероятность, что ты что то неверно собрал, то есть таки твои руки действительно кривы.

хорошо. как, тогда, так правильно собирать ntfs-3g, что бы можно было сказать, что у человека руки выпрямлены об батарею - «ничего не падает»?
твики, чистилки реестра не использую. делаю все стандартно. чего еще может быть?

Не стоит делать из FreeBSD линукс, и тогда не будет описанных выше проблем.

Не использовать samba, или transmission? что из этих двух вещей? или и то и другое?
i2p хотел ставить. как понял, вообще нельзя.

и снова получается, что я иронизирую...

Вообще походит на то, что у вас «сыпется» диск, проверьте его на наличие плохих секторов, посмотрите отчет смарт. О результатах доложите в тред, возможно вам помогут советом.

Вообще походит на то, что у вас «сыпется» диск, проверьте его на наличие плохих секторов, посмотрите отчет смарт. О результатах доложите в тред, возможно вам помогут советом.

как я понял, тут видны не все мои посты, ибо говорил и про мемтест и про викторию.

ответы могу выкладывать в pastebin, и туда давать ссылки. другое дело, это может как-то оскорбить людей, кто любит этот форум.

Как правильно отвечать? Прочитал LOR faq. Мне нужны были лишь мнения людей. Кто какие пункты по FreeBSD может добавить. В смысле, что не стоит под ней делать. Устанавливать.

И да - я верю, что под ней можно и все и что она самая лучшая из серверных ОС.

Хорошо. Чего обычно люди под ней не устанавливают, если используют ее дома? Ну... как бы по привычке.

Люди детектирующие школьника выдают с потрохами в себе школьника

Segmentation fault

Вы это, осторожнее с рекурсией.

*facepalm*

zfs, устойчивая, надежная

Ну нельзя эти слова в одном предложении без отрицания использовать, нельзя.

О, еще один толстенький пожаловал.. Давай, еще и ссылку на тему топикстартера про ZFS в качестве аргумента кинь!

Прошу прощения, что влезаю в дискуссию, но. Что плохого в том, если человек есть школьник? Мне FreeBSD и раньше нравилась, ибо имя. Падала иногда из-за модема спортсетара роботикс, - он висел на последовательном com порту. Но, опять же - я ставил пятерку, а не обкатанную четверку, тогда. А пятерка только,, только тогда вышла. всего год ей был. И тоже нравилось то, что под ней можно было собрать все «как нравится». Может стоит откатиться на восьмую версию? Девятка - как бы не четная.

Что каникулы кончились - начался тупняк? Удалите эти бредни с лора.

2 bhfq

можете посоветовать фирму, оказывающую платную поддержку?

А винмодемом, винмодемом то вы пользовались, чтобы в федо заходить? :)

Фидо особо не любил, но и словом федо не назвал бы. Софтмодемом пользовался из-за безденежья. 97й/glasnet. было.
Но ваш юмор не понял.

Фидо особо не любил

А кушать плов и танцевать под радиолу вы любили?

А кушать плов и танцевать под радиолу вы любили?

да, не подружимся мы. Разный мир у нас. Ни плов кушьать, ни винмодемы я не люблю.

ZFS, конечно, неустойчивой и ненадёжной величать всё же не стоит - есть много и похуже ФС - но эпитеты, которыми её наделяют фанатики (сверхнадёжная, неубиваемая, невероятно устойчивая), тоже излишни.

Надёжность данных необходимо обеспечивать прежде всего на физическом уровне. В условиях ненадёжности носителей ни одна ФС не спасёт.

Если же считать носители достаточно надёжными, то здесь рецепт надёжности по данным прост: чем меньше среднее время отложенной записи, тем меньше вероятность потери при сбое. Но при этом снижается и эффект от буферизации и, соответственно, падает скорость, поэтому так не делают. Таким образом, записываемые данные в любой ФС под угрозой.

Что касается надёжности по метаданным (структуре), то современные ФС с журналированием достаточно надёжны.

ZFS не волшебная, и фундаментальные проблемы решить не в состоянии. По надёжности по метаданным она не сильно отличается от, скажем, ext4, но проигрывает ей по скорости из-за дикой фрагментации со временем.

Вообще, программная архитектура этой ФС поражает: как можно в наше-то время делать такой монолитный кусок кода? Куча внутренних связей и отсутствие чёткого деления на слои превращает её в этакий GCC среди ФС.

на zfs файлы не фрагментируются же.

Если так, то грустно. ntfs пофиг, а вот нагрузку на сеть и диски должен выдерживать.

Хотя на практике у меня произвольных рестартов с нормальным оборудованием не было.

на zfs файлы не фрагментируются же.

НаВ ZFS используется CoW (Copy on Write), то есть при записи данных они размещаются не в той области, в которой располагались старые, а в новой. И так при каждой записи. Естественно, новый фрагмент при этом уже не будет располагаться на своём (относительно остальных фрагментов) месте. В результате со временем вся ФС оказывается нашпигованной кусками файлов, а сами они всё больше «размазываются» по диску по мере уменьшения свободного пространства.

У ext4, например, есть несколько приёмов, уменьшающих фрагментацию. Например, блоки объединяются в группы (128 МБ для размера блока 4 КБ), и аллокатор старается располагать фрагменты файла в пределах одной группы. Таблица inode у каждого блока своя (не приватная!), и аллокатор старается разместить все блоки файла в той же группе, что его inode. Кроме того, используется отложенная аллокация: решение о том, сколько блоков выделить файлу, принимается не при создании файла, а при отложенной записи буфера на диск, что позволяет точнее предугадать размер получающегося файла и потому избежать дробления на фрагменты. А ещё inode файлов стараются размещать в той же группе, в которой располагается «содержащий» их каталог.

Вообще, программная архитектура этой ФС поражает: как можно в наше-то время делать такой монолитный кусок кода? Куча внутренних связей и отсутствие чёткого деления на слои превращает её в этакий GCC среди ФС.

Это расхожее мнение широко распространено среди тех, кто в код никогда не заглядывал.

Надёжность данных необходимо обеспечивать прежде всего на физическом уровне. В условиях ненадёжности носителей ни одна ФС не спасёт.

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

Если же считать носители достаточно надёжными, то здесь рецепт надёжности по данным прост: чем меньше среднее время отложенной записи, тем меньше вероятность потери при сбое. Но при этом снижается и эффект от буферизации и, соответственно, падает скорость, поэтому так не делают. Таким образом, записываемые данные в любой ФС под угрозой.

Отучаемся говорить за любые ФС, это во-первых. Во-вторых, что там будет с данными в кэше - абсолютно фиолетово, ибо никто насчет данных в кэше никаких гарантий не давал. Тем кому надо гарантии - используют синхронную семантику. И вот если синхронно записанные данные теряются - вот это уже реальная проблема.

Что касается надёжности по метаданным (структуре), то современные ФС с журналированием достаточно надёжны.

Пусть даже и так. Но нужно помнить и о том, что с ростом размера дисков все более важным становится время проверки и восстановления после сбоя. Как традиционные ФС себя показывают в этом плане?

ZFS не волшебная, и фундаментальные проблемы решить не в состоянии. По надёжности по метаданным она не сильно отличается от, скажем, ext4, но проигрывает ей по скорости из-за дикой фрагментации со временем.

По надежности метаданных ext4 до zfs как пешком до Китая. А насчет фрагментации со временем... Вы так говорите, как будто бы для ext4 со временем и по мере заполнения не испытывает никаких проблем :)

Это расхожее мнение широко распространено среди тех, кто в код никогда не заглядывал.

Вы заглядывали? А я заглядывал. Правда, ещё на заре её включения в FreeBSD, но не думаю, что там что-то в этом плане поменялось.

Я, разумеется, не собираюсь утверждать, что там сплошь макаронный код. Но чётко разграниченных документированных и стабильных интерфейсов между слоями таки нет. И как следствие - повальный велосипедизм, когда вместо использования существующей проверенной, оттестированной и отлаженной подсистемы сбоку приделывается ZFS'шный велосипед, ибо оторвать его от остальной части кода слишком сложно.

Если у вас иные данные, прошу поделиться ссылкой, и я с радостью признаю, что был неправ.

Ты бы лучше вбросил бы реальной инфы и логов, а то потрут. Тут такая интересная дискуссия анонимусов. Не обламывай кайф, плиз.

По надежности метаданных ext4 до zfs как пешком до Китая.

За счёт чего?

А насчет фрагментации со временем... Вы так говорите, как будто бы для ext4 со временем и по мере заполнения не испытывает никаких проблем :)

Если в ZFS присутствует фактор, многократно её увеличивающий, причём даже в условиях слабой заполненности данными, то в ext4 наоборот применяются техники её уменьшения, которые я кратко описал в сообщении выше.

Вы заглядывали? А я заглядывал. Правда, ещё на заре её включения в FreeBSD, но не думаю, что там что-то в этом плане поменялось.

Ну да, судя по цитате ниже действительно заглядывали :)

И как следствие - повальный велосипедизм, когда вместо использования существующей проверенной, оттестированной и отлаженной подсистемы сбоку приделывается ZFS'шный велосипед, ибо оторвать его от остальной части кода слишком сложно.

Если у вас иные данные, прошу поделиться ссылкой, и я с радостью признаю, что был неправ.

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

По надежности метаданных ext4 до zfs как пешком до Китая.

За счёт чего?

За счет того, что система изначально проектировалась по-другому. CoW, контрольные суммы, дитто-блоки (обеспечивающие избыточность метаданных даже на одном диске).

Если в ZFS присутствует фактор, многократно её увеличивающий, причём даже в условиях слабой заполненности данными

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

то в ext4 наоборот применяются техники её уменьшения, которые я кратко описал в сообщении выше.

Это все, конечно, хорошо, но эти техники приводят к тому, что для записи данных приходится много двигать головками, что не помогает скорости записи. Конечно, это поможет чтению... если эти данные реально будут все время читаться с диска, если читаться вообще. Часто читаемые данные все равно попадут в кэш, и как там они разложены на диске, не будет играть особой роли. Как разложены блоки файлов, которые никому не нужны, так же не играет никакой роли. Ну а те, которые нужны время от времени - ну придется чуть больше подвигать головками, при этом необходимые метаданные вполне могут оказаться и в кэше.

Конечно, для кэша нужна память или SSD-диски (для L2ARC), но с этим сейчас проблем нет, а объемы памяти только растут. Проблемы машин из 20 века никого не интересуют.

По надежности метаданных ext4 до zfs как пешком до Китая.

За счёт чего?

Вопрос, кстати, с головой выдает, что вы документацию-то если и читали, то по-диагонали. Так что насчет того, чего вы там уяснили из заглядывания в исходники лет пять назад, я никаких иллюзий не испытываю :)

Прошу прощения, что влезаю в дискуссию, но. Что плохого в том, если человек есть школьник?

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

Может стоит откатиться на восьмую версию? Девятка - как бы не четная.

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

В ZFS используется CoW (Copy on Write), то есть при записи данных они размещаются не в той области, в которой располагались старые, а в новой. И так при каждой записи. Естественно, новый фрагмент при этом уже не будет располагаться на своём (относительно остальных фрагментов) месте.

В ZFS, если что, нет понятия «фрагмент», есть понятие блок, который может быть разных размеров.

Если не менять свойство recordsize, задающее максимальный размер блока, то это будет 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают ровно столько секторов, сколько требуется для их сохранения. При их модификации происходит выделение нового блока, так что файлы размером до максимального размера блока всегда остаются непрерывными. Если файл перерастает максимальный размер блока, то его размер блока фиксируется, и все его блоки в дальнейшем занимают 128 килобайт каждый (при значении recordsize по умолчанию).

В ext4 4 размер блока равен странице, так что при фрагментации файла на блоки размером 4 килобайта эффект от фрагментации может оказаться гораздо печальнее, нежели от фрагментации на блоки размеров 128К.

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

Свой собственный кэш (не L2).

Однако вы придрались к не основному посылу фразы. ZFS следовало бы разделить на независимые компоненты с публичным стабильным интерфейсом.

За счет того, что система изначально проектировалась по-другому. CoW, контрольные суммы, дитто-блоки (обеспечивающие избыточность метаданных даже на одном диске).

Напоминаю, что речь шла в предположении о достаточной надёжности носителя. Ничто из перечисленного при этом условии погоды не делает.

А так что ZIL, что jbd2.

Ну фактор-то действительно присутствует, но с фрагментацией все далеко не так ужасно, как вы пытаетесь нарисовать

Зависит от использования, конечно. Простое копирование на пустой том большого количества неизменяемых данных к росту фрагментации не приведёт. Другое дело DB.

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

Не намного больше обычного.

В ext4 4 размер блока равен странице, так что при фрагментации файла на блоки размером 4 килобайта

Во-первых, не равен, а не превышает.

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

Свой собственный кэш (не L2).

Отлично! А теперь потрудитесь еще объяснить, почему же это велосипед и как вы представляете себе использование обычного кэша страниц для этих целей.

Однако вы придрались к не основному посылу фразы.

Ага, не так просто оказывается доказывать свои утверждения :)

ZFS следовало бы разделить на независимые компоненты с публичным стабильным интерфейсом.

Может быть и компоненты назовете и нестабильные интерфейсы?

Напоминаю, что речь шла в предположении о достаточной надёжности носителя. Ничто из перечисленного при этом условии погоды не делает.

Конечно-конечно. Только вот все носители делятся на два класса - на те, что уже сломались, и те, которые скоро сломаются.

А так что ZIL, что jbd2.

И то, и другое есть механизмы поддержки синхронной семантики. Метаданные ими не ограничиваются. Так как там в ext4 со сквозным контролем целостности метаданных и их избыточностью?

Не намного больше обычного.

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

В ext4 размер блока равен странице, так что при фрагментации файла на блоки размером 4 килобайта

Во-первых, не равен, а не превышает.

Да, действительно, не превышает. И даже на сегодня может быть до 64К. Важно то, что этот размер, насколько я понимаю, фиксирован. Хотя могу и ошибаться.

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

Это если его сразу создать нужного размера при условии наличия больших объемов нефрагментированного свободного пространства. При таких условиях конечно фрагментация будет минимальной. Но такие идеальные условия не вечны :)

Ну и как я там выше объяснял, для небольших файлов в ZFS это не проблема, ибо они занимают один блок.

Не будем забывать еще и про то, что CoW, конечно, приводит к фрагментированию свободного пространства и разбрасывает блоки по дискам, но при этом позволяет иметь массу полезных плюшек, типа снимков, клонов, эффективной репликации и так далее.

Напоминаю, что речь шла в предположении о достаточной надёжности носителя. Ничто из перечисленного при этом условии погоды не делает.

Помимо надежности носителя есть еще такая штука как человеческий фактор. Вот тебе примерчик, как дитто-блоки могут сделать таки погоду.

ZFS следовало бы разделить на независимые компоненты с публичным стабильным интерфейсом.

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