Компания Canonical объявила (https://insights.ubuntu.com/2016/02/16/zfs-is-the-fs-for-con.../) о включении поддержки менеджера логических томов и файловой системы ZFS в состав дистрибутива Ubuntu 16.04. Реализация основана на использовании проекта ZFSonLinux (https://www.opennet.dev/opennews/art.shtml?num=42948), работающего на уровне ядра Linux и демонстрирующего неплохую производительность и стабильность. Модуль zfs.ko будет входить в штатную поставку пакета с ядром, а инструментарий zfsutils-linux будет доступен из репозитория "main", с предоставлением обновлений и технической поддержкой от компании Canonical.
В качестве основного назначения ZFS в Ubuntu называется использование в качестве хранилища изолированных контейнеров. В инструментарий управления контейнерами lxd уже встроены команды, необходимые для создания пула ZFS, размещения на нём контейнеров, клонирования разделов ZFS и создания снапшотов.<font color="#461b7e">
$ sudo lxd init
Name of the storage backend to use (dir or zfs): zfs
Create a new ZFS pool (yes/no)? yes
Name of the new ZFS pool: lxd
Would you like to use an existing block device (yes/no)? no
Size in GB of the new loop device (1GB minimum): 2
Would you like LXD to be available over the network (yes/no)? no
LXD has been successfully configured.
</font>URL: https://insights.ubuntu.com/2016/02/16/zfs-is-the-fs-for-con.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=43896
Ну и здорово. Zfsonlinux умеет trim?
Да, как и желание сожрать всю оперативку. А еще ZFS конфликтует с zRAM. После чего скорость у SSD падает до уровня HDD и ниже.
Настраивать надо, а не гуньдеть. ZFS это комбайн.
а вот другие файловые системы настроек не требуют
> Настраивать надо, а не гуньдеть. ZFS это комбайн.Действительно, адаптивный размер кэша - слишком иновационно, вот прописывать его самому, как в DOSовом smartdrv.exe - самое оно.
И прибивать, когда не хватает памяти ))
В основной ветке не умеет, есть пулл-реквесты, с принятием которых тянут и тянут.
А корневой фс её можно будет сделать?
Как я понимаю, это полноценная ФС, просто из-за лицензии распространяющаяся отдельным модулем.
Просто из-за лицензии не интегрировано в ядро.
Просто эта штука чуть более чем полностью несовместима с подсистемами ядра, и приходиться делать, где wrapper, а и где дублирование функционала.
> Просто эта штука чуть более чем полностью несовместима с подсистемами ядра, и
> приходиться делать, где wrapper, а и где дублирование функционала.что-то мне это напоминает
oh, wait...
P.S. Шишкин задумчиво одобряет эту самую политику торвальдса по пропихиванию угодных ему подсистем
Ее уже давно можно корневой ФС, но придется поплясать с бубном.
Проблемы две:
1) инсталлятор ее не умеет, размечать придется ручками.
2) с Grub есть проблемы, хотя в убунте их вроде как сейчас решают.
- новые фишки zfs не сразу поддерживаются grub, так что /boot желательно держать отдельно.
- есть проблема с поиском дисков zfs - libzfs несовместима по лицензии с grub, а обходной вариант кривой. При этом апстрим grub говорит не сношайте нам моск и линкуйте с libzfs или ебитесь сами.А так оно у меня с момента появления корень на zfs и единственной проблемой было то, что я пул заапгрейдил неподумавши и пришлось grub с апстрима собирать.
Эх, вкатил бы им Оракл теперь иск... Ибо нефиг.
чо? оно открытое давно
А просто так. Чтоб не совали то, чего нет в мейнлайне.
Тот же aufs3 в Debian и Ubuntu был всегда, а в Mainline никогда не был.
иди ищи прошивки с андроид 5 на p970 - умны ты наш. Сам сказал что они есть.
Или просто балабол ?
и чо? суть нарушения патентов не в реализации, а в идее
> Эх, вкатил бы им Оракл теперь иск... Ибо нефиг.Эти с их патентами - могут :)
Есть бекап сервер, где хранятся бекапы виртуалок. Имеет ли смысл пробовать собрать под него ZFS с дедупликацией? Если ли профит от дедупликации не на критичном сервере.
Есть дедупликация, есть LZ4, а можно тупо сливать туда актуальные бекапы виртуалок и делать снапшот. Хранить например последних 30 снапшотов - места съедается только на дифы. Если ещё взять какой-нибудь WD Green, охлаждение и нормальный БП + ИБП - неубиваемая вещь в себе.
Одно печалит - шифрования нативного нет.
QuAzI, могли бы вы расписать use case.
Виртуалки у меня на KVM, делаются бекапы посредством LVM snapshot раздела, где лежит виртуалки, затем гзипается на стороне гипервизора и сливается по NFS на сервер бекапов.Что можно применить на сервере бекапов для лучшей утилизации диска.
Выглядело это примерно так#!/bin/sh
### rsync everywhere
dt=`date \+\%Y\%m\%d`
/sbin/zfs snapshot -r storage@$dtЯ рсинкал файлы с нескольких источников на один винт, потом делал снапшот. Любую версию любого файла можно сразу взять без плясок с распаковкой и монтированием разделов (хотя вроде некоторые тома и гзипнутые можно было монтировать, нужно рыть документацию). Ещё можно нечаянно удалить всё на винте, а вот удалить снапшот ZFS - это надо уже шаманить в консоли из под рута, случайно не получится. Снапшоты рулят.
В вашем случае всё самое интересное уже убито на стороне гипервизора. От дедупликации будет хороший выигрыш там же, где и от сжатия. Грубо говоря вы хотите архив сжать ещё раз. Я не уверен, что большой шанс на достаточно сильно нагруженных томах, что два их архива будут значительно совпадать непрерывными блоками по 256кб (или сколько там сейчас блок - могу ошибаться). Жамкать что-то на стороне гипервизора оправдано только если канал узкий (хотя это иногда решается rsync), иначе можно сильно удивляться диким и долгим провалам в производительности боевых серверов.
А ещё можно на лету зеркалить ZFS том по сети, но я не пробовал.
Я пробовал. Зеркалирование ЗФС-томов работает хорошо в чентоси7 и всех убунтах.
Напомните сколько ресурсов жрет сам zfs при таком активном использовании всех фич?
Для бекап-сервера вполне приемлемо жрёт. Без сжатия и дедупликации пользовал ZFS на десктопе - тоже вполне нормально бегает. От бекапов важнее надёжность, а не перфоманс. Но вы можете продолжать NTFS, если у вас игры показывают FPS немного ниже, мы не против.
> Напомните сколько ресурсов жрет сам zfs при таком активном использовании всех фич?Zfs не умеет cp --reflink, такая вот "поддержка" Linux и coreutils.
> Zfs не умеет cp --reflink, такая вот "поддержка" Linux и coreutils.Перекрывается дедупликацией же
> Перекрывается дедупликацией жеНе перекрывается, cp --reflink мгновенно создает мне кипу 20Гб виртуалок из темплейта. Без нагрузки на CPU и потребления RAM. Или какую-нибудь иерархию можно мгновенно "скопировать" для экспериментов.
>> Zfs не умеет cp --reflink, такая вот "поддержка" Linux и coreutils.
> Перекрывается дедупликацией жеКлонами же.
На FreeBSD можно использовать NullFS(5).
Архивы плохо дедуплицирует, это ожидаемо. Рекомендую использовать на ZFS LZ4+dedup, это не только сэкономит место, но и скорость на медленных винтах. При дедупликации рекомендуют использовать 1GB RAM на 1TB данных на диске Т.е. если у вас 40 одинаковых образов по 1ТБ то вам нужно около 1GB рамы дополнительно.
>затем гзипается на стороне гипервизораЭто несовместимо с последующей дедупликацией.
Возьмите rsync с патчем, позволяющим брать в качестве источника блочное устройство (в файле с исходниками rsync раньше был).
Хорошая шутка про WD Green, посмеялись, спасибо.
Дёшево и сердито для бюджетных решений. Вы бы свой вариант предложили для SOHO, мы бы тоже посмеялись. Промышленные NASы тут бессмысленно обсуждать, как и выбор ФС к ним.
> Одно печалит - шифрования нативного нет.по шифрованию сейчас в ML один товарищ развел бурную переписку и даже что-то реализовал уже, так что вполне возможно скоро будет.
От дедупликации есть нехилые тормоза. В зависимости от типа винтов и мощности сервера, упасть производительность может буквально в разы. Профит примерно такой же, как и от сжатия, редко когда сильно больше, но сжатие, как правило, далеко не так сильно снижает скорость и не требует настолько много памяти, как дедупликация.
Если сливать туда уже сжатые образы, то профита может не получиться совсем.
Вот тут человек подписался в полном незнании того, как это работает.Chunks of data are remembered in a table of some sort that maps the data's checksum to its storage location and reference count. When you store another copy of existing data, instead of allocating new space on disk, the dedup code just increments the reference count on the existing data. When data is highly replicated, which is typical of backup servers, virtual machine images, and source code repositories, deduplication can reduce space consumption not just by percentages, but by multiples.
Профит может быть такой как от сжатия, если входные данные - разношёрстный зоопарк. И в разы лучше, если это например ежедневные бекапы компании за последний год.
...
Most dedup solutions only work on a limited amount of data -- a handful of terabytes -- because they require their dedup tables to be resident in memory.
ZFS places no restrictions on your ability to dedup. You can dedup a petabyte if you're so inclined. The performace of ZFS dedup will follow the obvious trajectory: it will be fastest when the DDTs (dedup tables) fit in memory, a little slower when they spill over into the L2ARC, and much slower when they have to be read from disk. The topic of dedup performance could easily fill many blog entries -- and it will over time -- but the point I want to emphasize here is that there are no limits in ZFS dedup. ZFS dedup scales to any capacity on any platform, even a laptop; it just goes faster as you give it more hardware.
Расходы - на посчитать чексум, найти копию в таблице (при условии что таблица не вытеснена из ОЗУ - копейки), сделать запись о дубле - сами дублируемые данные при этом не пишутся (если конечно ты сам не настроил делать несколько копий блоков, чтобы исключить bad blocks - что не есть хорошо, для этого лучше делать зеркало средствами ZFS на другой винт)
Надо считать размер DDT и влезет ли она в память. Если не влезет, то лучше dedup не включать. Расчет памяти есть в интернетах.
Если перфоманс бекапов поднимаемых раз в году для вас важнее износа и экономии места, то можно и позаморачиваться. Хотя если уж на то пошло - ОЗУ нынче стоит сравнительно дёшево, особенно если искать не антиквариат типа DDR1/DDR2 для старых серверов. Кэш можно вынести на SSD, опять же.
> Если перфоманс бекапов поднимаемых раз в году для вас важнее износа и
> экономии места, то можно и позаморачиваться. Хотя если уж на то
> пошло - ОЗУ нынче стоит сравнительно дёшево, особенно если искать не
> антиквариат типа DDR1/DDR2 для старых серверов. Кэш можно вынести на SSD,
> опять же.Да, только если бакапов много, а перфоманс падает настолько, что бакапится/восстанавливаться начинает по пол дня - это уже никуда не годится.
И расчет памяти DDT:
http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupeНа каждый TB данных нужно 5 GB памяти под DDT, если предположить что средний размер блока 64K. В целом это означает что вам потребуется 20GB* памяти на TB данных, если вы хотите уместить DDT и метаданные, плюс память для самой ОС и приложений.
(* 20 потому что DDT не может занимать более 1/4 памяти выделенной под ARC.)Если столько нет, то есть вариант с L2ARC на SSD, но оно уже медленнее, хотя для бакапов сойдет. Без SSD все может быть совсем печально.
Другими словами, если вы запускаете анализ (zdb -S tank) и оно говорит вам, что экономия будет от 20%, можно задуматься о dedup c SSD. Реальная экономия начинается когда дедупликация позволяет экономить место более чем двукратно. Если предположить что у вас куча контейнеров и они все почти одинаковые, при этом они обычно небольшие, то экономия может быть очень существенная - в этом и есть план canonical.
> Вот тут человек подписался в полном незнании того, как это работает.Неуважаемый, а слабо высказывать точку зрения, не пытаясь аппелировать к чьим-то знаниям? Ведь откуда ты знаешь что я знаю, а что я не знаю?
Да будет тебе известно, дедупликацию я именно для бэкапов использовал еще на заре внедрения этой технологии, еще Avamar от EMC крутил. Как говорится, когда дедупликация еще не была мэйнстримом.
И говорил я об общем случае, а не частных, которых может быть вагон и маленькая тележка, с теми, или иными условиями и результатами. Человек спросил про ZFS - я ответил про ZFS, тем более учтя комментарий про то, что на сторадж выкладываются уже сжатые файлы.
Но зачем нам читать и понимать написанное? Поумничать-то - оно завсегда важнее и первостепеннее.Дедупликация до сих пор не получила широкого распространения, потому что эта технология идеальна лишь на бумаге, а на практике имеет весьма немало минусов и подводных камней, главным из которых как было, так и остается огромное потребление ресурсов и весьма ограниченное количество сценариев с реально высокой эффективностью. Плюс, есть немало способов добиться схожего эффекта при куда меньших затратах. Например, те же снапшоты, про которые выше упоминалось.
А что ты знаешь? Как у Avamar сделана дедупликация? Что там внутри? Дай хоть один повод усомнится, что твой опыт - это твой опыт не говорящий о самой технологии ничего? Вот когда человек пишет "Надо считать размер DDT и влезет ли она в память" - видно, что человек понимает, как это работает и о чём он говорит. А когда "ну хз, мне не нравица" - это как-то не очень объективно, не очень аргументировано и ни слова по делу о реальном опыте не предоставляет.
Пользовал ZFS с 2008-го года - вполне нормально шуршит, если понимать, что происходит и немного читать. Странно например включать сжатие, дедупликацию и ещё стопицот фич и надеяться, что всё это влезет в каких-нибудь 256Мб какой-нибудь эмбеддовки для винта забитого мелким файлом на 8Тб.
> Дай хоть один повод усомнится, что твой опыт - это твой
> опыт не говорящий о самой технологии ничего?Почему ты решил, что я должен тебе что-то доказывать? Более-менее близко я с этим работал отнюдь не вчера, поэтому деталей уже банально не помню. Помню общее впечатление, которое и озвучил.
> Пользовал ZFS с 2008-го года - вполне нормально шуршит, если понимать, что
> происходит и немного читать. Странно например включать сжатие, дедупликацию и ещё
> стопицот фич и надеяться, что всё это влезет в каких-нибудь 256Мб
> какой-нибудь эмбеддовки для винта забитого мелким файлом на 8Тб.Это понятно. Включали на Sun Fire X4500. Можешь загуглить и "почитать", как ты любишь, поняв какой мощности эта железка, что там отнюдь не 256MB памяти и примерно как давно это было.
Если учесть, что изначальная версия ZFS, которая сейчас с минорными доработками используется в Linux, взята примерно из того времени, пока Solaris еще имел открытые исходники, то едва ли там с тех пор что-то кардинально поменялось как в производительности, так и в потребляемых ресурсах.
Я бы не сказал, что ZFS здесь непременно будет лучшим решением. Посмотрите такие дедуплицирующие бекаперы как ZBackup и ZPAQ, думаю они больше подойдут под ваши задачи.
Дедуп — нет, он только для файлопомоек адекватен. Но есть "финт ушами": блочный rsync в сторону zfz|btrfs + снапшоты.contra: rsync KC в rc4 считает до сих пор. См. таблицы с вероятностями коллизий.
> contra: rsync KC в rc4 считает до сих пор. См. таблицы с
> вероятностями коллизий.Если речь про нативный rsync, то rsync проверяет имя файла, его таймстамп, размер, затем уже, если включена опция - контрольную сумму. Для синхронизации пофайлово этого более чем достаточно для надёжности. Невозможно создать файл, а потом вменяемыми правками сохранить его размер, таймстамп и хэш.
Если речь про всякие костыльные форки, то сомнительно считать такие решения хорошим выбором, ИМХО.
Блочные устройства → ФС. Поблочно. Вот так примерно:
/usr/bin/rsync --copy-devices --copy-links --times --partial --inplace ${user}@${host}:"/dev/mapper/${lv[0]}-${lv[1]}.snap" "${p}/${lv[1]}"кс тоже по блокам считается, см. исходники rsync.
"--copy-devices" — да, патч. Тупо разрешающий оно самое, запрещённое "из коробки" велением левой пятки авторов. Применен в большинстве современных дистрибутивов. Например, пожилая centos 6:
#rsync --version
rsync version 3.1.1 protocol version 31
...
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes, prealloc
Ты уверен, что велением левой пятки? Они на этом деле не одну упряжку собак съели.
Для таких вещей есть сетевая репликация ФС. В том числе сабж её умеет прекрасно без приколов с коллизиями, без костылей, бесплатно и без смс.
> Для таких вещей есть сетевая репликация ФС. В том числе сабж её
> умеет прекрасно без приколов с коллизиями, без костылей, бесплатно и без
> смс.Не, бэкэнд для виртуалок на zvol создаёт больше проблем, чем решает (на мой вкус). Потому что миграции становятся ещё менее тривиальными, чем на qcow over ext-fs.
> решает (на мой вкус). Потому что миграции становятся ещё менее тривиальными,
> чем на qcow over ext-fs.Можно узнать детальнее, как у вас это сделано и где в этом месте проблемы с ZVOL ?
> Можно узнать детальнее, как у вас это сделано и где в этом
> месте проблемы с ZVOL ?У нас оно было задизайнено на lvm по фибре + свои скрипты на предмет "lvchange -a[yn]" etc. (т.к. clvm не вариант для гипервизоров). Геморрой от такого решения окупается нулевым оверхедом на обслуживание/миграцию томов между гипервизорами.
С ZVOL так нельзя. Нужно поступать аналогично qcow, а там заметный провал на перетаскивание последнего журнала. Не считая дурацкой фрагментации дискового пространства между гипервизорами. Ну и как таковое "переливание из пустого в порожнее". Нагружать сеть идиотскими io, когда задача — просто "перещёлкнуть" раздел на соседний хост…Предупреждая след. вопрос "а почему дизайн такой неправильный":
— С ceph связываться пока боязно ("из коробки" не взлетит в силу нюансов с выделением памяти в linux (buddy), время на доводку неясно), люстра стóит небюджетно, gluster по скорости только на оффлайн тянет.
Какая в ж стабильность!?
В проксмоксе ядро бубунте с zfs, ещё как падает.
Полковнику Табуретке
В Проксмоксе Редхатовское ядро с патчами от проксмоксовцев, репозиторий их с фирменным софтом, всё остальное от дебиана. Убунты нет
> Полковнику Табуретке
> В Проксмоксе Редхатовское ядро с патчами от проксмоксовцев, репозиторий их с фирменным
> софтом, всё остальное от дебиана. Убунты нетС разморозкой, в changelog заглядывал?
На просветись http://download.proxmox.com/debian/dists/jessie/pve-no-subsc...Редхатовское там было до 4 версии проксмокса
exFAT бы включили "искаропки" - вот это было бы клёво.
> exFAT бы включили "искаропки" - вот это было бы клёво.А она где-то применяется потому что нужна, а не маркетинг? В чём её фичастость хоть по сравнению с FAT32 на сегодняшний день? Я вот не вижу в фотокамерах и смартфонах карточек на 2Тб. Износ давно решается аппаратно. Проблемы с фрагментацией на SD-карточках тоже не видать. ACL'и там нафиг не нужны. Пусть лучше производители эмбеддовки озаботятся поддержкой нормальных ФС, чем этого шита.
> В чём её фичастость хоть по сравнению с FAT32 на сегодняшний день?Файлы больше двух Гб. Я вот флешку сделал, чтобы и в убунте и в винде работала — работает-таки, но телефон её не видит. Пришлось делать в EXT4, на винду драйвер, телефон умеет.
> Файлы больше двух Гб. Я вот флешку сделал, чтобы и в убунте
> и в винде работала — работает-таки, но телефон её не видит.
> Пришлось делать в EXT4, на винду драйвер, телефон умеет.До 4 Гб влезает нормально и давно.
Я считаю что Ext2/3/4 тут гораздо правильнее использовать, чем тащить и поддерживать всякий левый exFAT, а потом ещё огребать на нём поборы за уродское лицензирование.
Тем более это уже работает, а exFAT в половине устройств фиг распознается.
> До 4 Гб влезает нормально и давно.
> Я считаю что Ext2/3/4 тут гораздо правильнее использовать
> Тем более это уже работает, а exFAT в половине устройств фиг распознается.У меня телевизор даже понимает exFAT.
А ext на флешке - это для какой-то другой вселенной, где десктопных линуксов не 1-2%
> У меня телевизор даже понимает exFAT.С вероятностью 99% он сделан на линухе, поэтому с вероятностью 95% он понимает и EXT-ы, как минимум 2 и 3.
Ну и для того, чтобы не "огребать на нём поборы за уродское лицензирование"
придумали F2FS, которая поддерживается линуксовым ядром с версиии 3.8, но оно ещё не готово до стабильного уровня, а ext* на флешке только извращенец подумает использовать.
F2FS - это такой мифический зверь в вакууме.
Чем ext* на флешке хуже exFAT? Кроме того, что ext* уже давно и упорно поддерживаются всем, включая NASы, ранние заумные телевизоры, Android всех версий и вплоть до SOHO-роутеров (от родных прошивок к некогда легендарному Asus WL500 до OpenWRT и прочих кастомов), плюс можно смонтировать на любой актуальной ОС (и не актуальной, ext2 можно даже в DOS смонтировать), плюс полно инструмента которым можно вытащить данные в случае повреждения ФС (а съёмные устройства это ой как любят).
> Кроме того, что ext* уже давно и упорно поддерживаются всем Android всех версийАга, так упорно. Если вставишь SD карту с ext* в агрегат с Android, который без прошивки 'я у мамы хакер', и без рутованных хаков, то получишь дулю. (не надо мне говорить про его корень работающий в ext* - я всё отлично это знаю). Ну и штатных средств для форматирования SD карты в ext* тоже нет по понятным причинам (у разработчиков логика то есть).
f2fs даже MIUI не поддерживает. В то время, как exFAT поддерживают все андроиды (4+?). Буквально на этой неделе решал чем форматить сд-карточку на 64 Гб. С f2fs ситуация оказалась просто плачевной.
И да, на карточку часто закидываются фильмаки по 7-12 Гб. Ограничение в 4 Гб это какая-то нездоровая инвалидность.
>> exFAT бы включили "искаропки" - вот это было бы клёво.
> А она где-то применяется потому что нужна, а не маркетинг? В чём её фичастость хоть по сравнению с FAT32 на сегодняшний день?У меня в Lumia 735 карточка в ней отформатирована. Фичасточть в том, что можно держать файлы размером больше 4 ГБ, полновесные фильмы в формате MKV720p/1080p, например.
iZEN, вот только ты можешь хвастаться убогим виндофоном (и удивляться, почему виндофон форматает в этот унылый формат, ведь если не MS, то кто же) и пытаться смотреть с телефона видео, которое он всё равно не тянет нормально.
Вот как-то до того как DVD-ромы не вымерли, прекрасно обходились без extFAT даже с переносом iso-шек. А сегодня она и подавно нафиг не нужна. Купленные фильмы на флешках не гуляют, для всего остального есть внешние диски, сетевые шары и прочий вагон вариантов.
> вот только ты можешь хвастаться убогим виндофоном (и удивляться, почему виндофон форматает в этот унылый формат, ведь если не MS, то кто же)А я вот взял щас в руки устройство с android 5 одной такой очень популярной корейской фирмы в Этой Стране.
Угадай какую ФС оно использует на SD флешках по умолчанию. Правильно - exFAT.
Это типично и для других ведроидов.
> iZEN, вот только ты можешь хвастаться убогим виндофоном (и удивляться, почему виндофон
> форматает в этот унылый формат, ведь если не MS, то кто
> же)
> и пытаться смотреть с телефона видео, которое он всё равно не тянет нормально.Что, больше меня знаешь про мой телефон, который и в руках даже не держал? :))
> Вот как-то до того как DVD-ромы не вымерли, прекрасно обходились без extFAT
Объёмы флэшатины перевалили за 32 ГБ. Вот там и применяются более современные файловые системы. Lumia поддерживает microSD до 128 ГБ, а твой Android?
> даже с переносом iso-шек. А сегодня она и подавно нафиг не
> нужна. Купленные фильмы на флешках не гуляют, для всего остального есть
> внешние диски, сетевые шары и прочий вагон вариантов.Вагон вариантов есть, но у нас ещё и маленькая тележка пристроена. ;)
> exFAT бы включили "искаропки" - вот это было бы клёво."Клёво" сильное слово. Тем кто использует ubuntu (1% гиков) и так не трудно будет набрать apt-get install exfat-fuse
Кстати, баг в багтрекере на эту тему https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1...
> Тем кто использует ubuntu (1% гиков)У Убунту серьезная пользовательская база и я даю 100%, что это далеко не 1%.
Кто я такой?
С технической точки зрения exFAT - это просто ещё один навязанный буллшит, как например неотключаемый Secure Boot умеющий грузить только винду или микрокод новых процессоров который "эффективно работает только под виндой" потому что на свободу выбора остальных тупо положили болт в тот момент, когда проплатили кому следует.
Продолжайте требовать больше кактусов вместо годных технологий.
Что то мне это напоминает обещания пятилетней давности о включении в поставку дисплейного сервера Wayland. Не?
>полноценной поддержки графического API VulkanНедавно только апи релизнулась, еще библиотек толком нет, а космонавт уже обещает включить в следующей версии. Которая LTS. Готовим попкорн, обещается очередная трагикомедия.
Включить-то можно. все равно им пользоваться не будут еще года 2.
SDK есть, дрова почти для всех производителей есть - что вам еще надо?
Компания Canonical объявила о своей дурости. Модуль ZFS используют единицы, зачем его пихать в штатное ядро?
> Компания Canonical объявила о своей дурости. Модуль ZFS используют единицы, зачем его
> пихать в штатное ядро?В стандартной поставке очень много модулей, которые используют единицы, они лежат на диске и только место занимают. Линус поддержку EISA в ядре вообще ради одного человека оставил.
Не кормите тролля. Он уже вычитал, что ZFS в ядре (а не отдельным модулем) и сразу стал аналитиком, который знает, что нужно всем людям лучше их самих.
И да, это не первый и не последний дистрибутив Linux, который хочет поддержку ZFS из коробки.
> В качестве основного назначения ZFS в Ubuntu называется использование в качестве хранилища изолированных контейнеров.А btrfs, нормально интернированной в ядро, для этих целей им мало?
>> В качестве основного назначения ZFS в Ubuntu называется использование в качестве хранилища изолированных контейнеров.
> А btrfs, нормально интернированной в ядро, для этих целей им мало?А где она нормально интегрирована?
Скажите кто-то как работает и включается trim на ZFSLinux? не могу найти пока
Судя по http://open-zfs.org/wiki/Features#TRIM_Support поддержка TRIM есть только во FreeBSD пока.
> Скажите кто-то как работает и включается trim на ZFSLinux? не могу найти
> покаВ некрологах искал?
> Скажите кто-то как работает и включается trim на ZFSLinux? не могу найти покаЕсть патч от Nexenta, но в апстрим пока не принят. Особо отважные могут пробовать.
Проблема у trim+cow в том, что cow в принципе работает так, чтобы не затирать старые данные(тогда есть возможность отката транзакций), а trim как раз нужен для обратного - чистить "не используемые" сектора.
В итоге делают некий буфер, который будет ждать н-ное количество транзакций и только потом тримать сектора. В остальных случаях все достаточно тривиально - потримать zvol при создании и весь диск перед разметкой zpool не сложно, но встает вопрос необходимости в принципе, т.к. это дополнительное действие, которое не факт что нужно делать всегда.
Наверняка это связано как-то с новостью о AT&T, в которой говорилось о серверах на Ubuntu.