ZFS on FreeBSD desktop

за что меня бесила фри несколько лет назад, когда я использовал ее как десктоп:

проблема с неотмонтированными флешками; проблема с записью болванок на SATA CDRW приводе (запись на IDE работала); приходилось компилить из портов linux-firefox, linux-thunderbird, linux-something потому что были проблемы с флешами, жаба плагинами под простой фришный фаерфокс etc; компилить под бсд линуксовые порты совсем не доставляло. не было нормального штатного инструмента для полного апдейта системы без участия человека. например я поставил make upgrade и ушел спать. утром встаю, а там комп показывает sysinstall с выбором каких-то очередных опций сборки. соответственно, полночи он стоял без дела и требовал моего участия. необходимость компилить свое ядро для всякой чепушни, типа возможности записывать болванки. хреновая работа с USB - приходилось вручная править конфиги для автомонтирования, а также низкая скорость записи на флешки (не более 2 MB/s) отсутствие софта для виртуализации.

все остальное вроде устраивало.

как сейчас обстоят дела? решили вышеописанные косяки?

Это я уже путаю. Впрочем я и не его имел в виду. Имелось в виду ifconfig iwi0 scan или что-то в таком духе.

как сейчас обстоят дела? решили вышеописанные косяки?

Диски на SATA DVDRW пишутся (я пишу с root-правами, во избежание косяков в Xfburn).

linux-* не использую. Разве что для J2ME WTK.

Flash не смотрю.

Java Plug-in идёт только в Sun JDK и не работает в Firefox v.>3.5.

Апдейт системы и установленных пакетов — раные вещи. Для обновления установленных пакетов есть portmaster, он задаёт вопросы только в самом начале установки/обновления. У portupgrade и portmaster есь опции предварительного конфигурирования устанавливаемых портов и всех их зависимостей.

Ядра GENERIC достаточно для 99,999% применений FreeBSD на десктопе.

USB до сих пор нужно конфигурировать для нормального монтирования через devfs.*/HAL/PolicyKit (и mount.rc для поддержки национальных кодировок в именах файлов). Четыре файла конфигурации не трудно скопировать.

Скорость записи на флэшки под FreeBSD хорошая — во всяком случае не отличается от таковой под WindowsXP.

Виртуализацией кроме Java не занимался.

[code]du -sh /usr/ports[/code]
1. Мы не видим что внутри, что наводит на определенные мысли.
2. Даже если каталоги действительно идентичны, файловая система должна показывать точный вес файлов (без сжатия). А то получится так: качаешь 700-метровый фильм, а он в два раза меньше весит. Фигня какая-то.

В общем, незачет. Не думал, что zfs во FreeBSD реализована так аляповато.

du -sh /usr/ports

Ну вы поняли.

[code]du -sh /usr/ports[/code]

1. Мы не видим что внутри, что наводит на определенные мысли.

man du:

-s Display an entry for each specified file. (Equivalent to -d 0)

> man du

       -s, --summarize
              display only a total for each argument

И все же я немного не о том писал.

> В общем, незачет. Не думал, что zfs во FreeBSD реализована так аляповато.

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

В ZFSv14 дедупликация не поддерживается.

> Приходи, когда в линуксовых ФС появится возможность включать и выключать на лету фишки типа сжатия, дедупликации и т.д., тогда поговорим.

Дедупликации во фряхе нет. А e2compr (это сжималка ext2) уже лет 7 отроду, если не больше.

Про то, что zfs уже реализована в качестве модуля fuse, я даже не упоминаю. Также не буду говорить про другие fs, поддерживающие сжатие.

> > Приходи, когда в линуксовых ФС появится возможность включать и выключать на лету фишки типа сжатия, дедупликации и т.д., тогда поговорим.

Дедупликации во фряхе нет. А e2compr (это сжималка ext2) уже лет 7 отроду, если не больше.

Про то, что zfs уже реализована в качестве модуля fuse, я даже не упоминаю. Также не буду говорить про другие fs, поддерживающие сжатие.

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

А теперь подумай, какой смысл в названии команды du имеет каждая буква? И как это может быть связано с возможностью включения/выключения сжатия на лету.

Дедупликацию пока трограть не будем, раз уж ее нету. Хотя, если уж на то пошло, то в упомянутом ZFS-FUSE она таки есть, но ZFS-FUSE - это не Линукс, строго говоря. Впрочем, как и e2compr - не линуксовая ФС, а какой-то левый патч.

> 2. Даже если каталоги действительно идентичны, файловая система должна показывать точный вес файлов (без сжатия). А то получится так: качаешь 700-метровый фильм, а он в два раза меньше весит. Фигня какая-то.

В общем, незачет. Не думал, что zfs во FreeBSD реализована так аляповато.

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

> Можно вобщем далеко не ходить. Согласно такой логике, ФС должна и дырявые файлы показывать с точным весом, без учета дырок. Только вот смысл в этом какой? ФС, которая изнутри во много раз больше чем снаружи?

Удобней, на мой взгляд: качнул образ, и сразу видно, что он полностью слился. Для десктопа явно в некоторых случаях не лишним будет. Кстати, та же windows в свойствах файла пишет оба размера.

Ну или на крайний случай при монтировании опция какая-нибудь должна быть: показывать «реальный» вес или занимаемый.

> Дедупликацию пока трограть не будем, раз уж ее нету. Хотя, если уж на то пошло, то в упомянутом ZFS-FUSE она таки есть, но ZFS-FUSE - это не Линукс, строго говоря. Впрочем, как и e2compr - не линуксовая ФС, а какой-то левый патч.

Если продолжать развивать эту мысль, ZFS - это не FreeBSD. UFS - вот что есть у FreeBSD. Демагогия, короче.

PS. Я не против zfs и новых плюшек, я обеими руками за. Но не надо приносить это как безоговорочное преимущество: у линуксов, как оказалось, тоже есть подобные технологии.

Удобней, на мой взгляд: качнул образ, и сразу видно, что он полностью слился. Для десктопа явно в некоторых случаях не лишним будет.

Надо тогда определиться о чем идет речь - об отдельном файле или о файловой системе.

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

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

Кстати, та же windows в свойствах файла пишет оба размера.

С выводом информации о файле в Unix и подобных системах тоже особых проблем нет (даже как-то странно видеть отсылки к тому, что делает Windows, на ресурсе, посвященном Линуксу)

bash-4.0# stat --printf="%25n: Size %s, IO Block Size %o, Block Size %B, Blocks %b\n" /rpool/test/solid /rpool/test/sparse /rpool/test/solid.nocomp /rpool/test/sparse.nocomp         /rpool/test/solid: Size 1048576, IO Block Size 131072, Block Size 512, Blocks 1
       /rpool/test/sparse: Size 1048576, IO Block Size 131072, Block Size 512, Blocks 1
 /rpool/test/solid.nocomp: Size 1048576, IO Block Size 131072, Block Size 512, Blocks 2053
/rpool/test/sparse.nocomp: Size 1048576, IO Block Size 131072, Block Size 512, Blocks 261

Выше - пример вывода для 4 файлов в ZFS, первые два из которых созданы при включенном сжатии, а вторые - при выключенном.

Ну или на крайний случай при монтировании опция какая-нибудь должна быть: показывать «реальный» вес или занимаемый.

Еще раз предлагаю подумать на тему осмысленности этого для файловой системы в целом.

> Если продолжать развивать эту мысль, ZFS - это не FreeBSD.

Ну почему-же? Вполне себе полноценная часть FreeBSD

UFS - вот что есть у FreeBSD. Демагогия, короче.

А вот это уже и есть демагогия.

PS. Я не против zfs и новых плюшек, я обеими руками за. Но не надо приносить это как безоговорочное преимущество: у линуксов, как оказалось, тоже есть подобные технологии.

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

чото меня аж на попкорн пробило.
Такой ярый.
Чую в линуксах всё гладко и чисто, прям по феншую и GPL v3 без блобов и прочей пропитарщины

кстати где моя вторая звездочка за скрин ???? =)

Неожиданно нравится)

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

По-моему все так и определяют. Слил файл — посмотрел размер, проверил md5.

С выводом информации о файле в Unix и подобных системах тоже особых проблем нет (даже как-то странно видеть отсылки к тому, что делает Windows, на ресурсе, посвященном Линуксу)

stat --printf=«%25n: Size %s, IO Block Size %o, Block Size %B, Blocks %b\n» [...]

No comments, как говорится :)

Годная картинка, даже несмотря на КДЕфилию. Последнее время только школьники со своими юбунтами спамят галерею