Компания Canonical сообщила (https://ubuntu.com/blog/enhancing-our-zfs-support-on-ubuntu-...) о предоставлении в Ubuntu 19.10 возможности установки дистрибутива с использованием файловой системы ZFS на корневом разделе. Реализация основана на использовании проекта ZFS on Linux (http://zfsonlinux.org/), поставляемого в виде модуля для ядра Linux, который начиная с Ubuntu 16.04 входит в штатную поставку пакета с ядром.
В Ubuntu 19.10 поддержка ZFS будет обновлена до версии 0.8.1 (https://www.opennet.me/opennews/art.shtml?num=50730), а в инсталлятор десктоп-редакции добавлена экспериментальная опция для применения ZFS для всех разделов, включая корневой. Соответствующие изменения будут внесены в GRUB, в том числе в загрузочном меню появится опция для отката изменений с использованием снапшотов ZFS.
Для управления ZFS в разработке находится новый демон zsys (https://github.com/ubuntu/zsys), который позволит запускать несколько параллельных систем с ZFS на одном компьютере, автоматизирует создание снапштов и управляет разнесением системных и изменяемых в процессе пользовательского сеанса данных. Основная идея в том, что в разных снапшотах можно содержать разные состояния системы и переключаться между ними. Например, в случае проблем после установки обновлений можно будет вернуться к старому стабильному состоянию, выбрав прошлый снапшот. Снапшоты также будут использованы для прозрачного автоматического создания резервных копий пользовательских данных.
URL: https://ubuntu.com/blog/enhancing-our-zfs-support-on-ubuntu-...
Новость: https://www.opennet.me/opennews/art.shtml?num=51270
Для десктопа есть профиты относительно btrfs?
Спрашиваю серьезно, не ради ср^W нездоровой дискуссии.
для десктопа - навряд ли, во всяком случае, в текущий момент. Но убунта смотрит в будущее, и явно не видит там места для btrfs'а.А для недесктопа вам эти профиты, типа, известны?
Вообщета убунта смотрит не в будущее, а в редхат, уж тебе ли не знать.
Вряд ли они станут прямо таки выпиливать btrfs, ведь получится что в дебиане есть, а в убунте нет.
в будущее смотрит только федора, но никак не ваша убунта
Ну тогда уж Арчик :-Р
нет, не арчик
Согласен.
Пока федора только смотрит, Арчик уже там находится
это жопа.
в *аднице арчик находится
btrfs лучше работает с дисками какие были в наличии, когда нет специально купленых одинаковых. Проблема в том, что отладить не могут.
https://www.youtube.com/watch?v=YSsKw8gRVlY
https://www.youtube.com/watch?v=yIIO7gxOAiY
Снепшоты, онлайн-дефрагментация (для HDD), сжатие с различными алгоритмами на выбор. Какой ещё профит нужен? Мне достаточно первого и второго.
>онлайн-дефрагментация (для HDD), сжатие с различными алгоритмами на выбор. Какой ещё профит нужен? Мне достаточно первого и второго.Есть в NTFS.
Ты полностью овладел искусством фигурного цитирования, юный подаван.
fixed: продаван
>>онлайн-дефрагментация (для HDD), сжатие с различными алгоритмами на выбор. Какой ещё профит нужен? Мне достаточно первого и второго.
> Есть в NTFS.Остроумно, да. Почти.
Второе меня как предпочитающего ext4 на HDD не интересует, а остальное итак есть в btrfs.
ext4 и btrfs/zfs не являются взаимозаменимыми.
зато в спорах можно приводить то одну то другую когда выгодно. У него наверняка 2 корня на разных фс и по потребностям юзает один из них =)
А дефрагментация для Ext4 и не нужна, она не COW-принципах построена.
>А дефрагментация для Ext4 и не нужна,А e4defrag от нечего делать липили? Нужна дефрагментация, всё-таки хоть алгоритм резервирования места уже давно включён в ядро с мелкими файлами
он не поможет.Да диск загаживаеться дольше чем на нтфс, но при домашнем использование по крайне мере раз в полгода точно нужно проводить, у меня выходило до 30% фрагментированных файлов.Но это относится только к жёстким дискам.К флэш-памяти на навороченных дисках
не знаю даже как относится, все дело в автоматической переназначения блоков, иногда это приводит к интересным эффектам.
> А e4defrag от нечего делать липили?в целом - да. Точнее, нечего делать было людям с привычками мсдоса и полным непониманием работы современных систем.
дефрагментация в многопользовательской и многозадачной системе в общем-то не особенно нужна (скорей уж правильная фрагментация), пока не начинает расти метаинформация и ее не приходится собирать по всему диску гигабайтами, прежде чем удается достучаться до байтов данных - но с этим у ext4 все не так уж плохо, а у zfs - приемлемо.
> но при домашнем использование по крайне мере раз в полгода точно нужно проводить, у меня
> выходило до 30% фрагментированных файловйуный п...ну пусть падаван - ты сделал совершенно неверный вывод из верного сообщения. Ничего ужасного и вредного в этой фрагментации нет.
>но с этим у ext4 все не так уж плохо,Не реальное подение производительности жёсткого в каталогах с мелкими файлами.Я книгоман, и поверье не всегда книжки можно упаковать в каталог zip .И на двух милионнах файлов не дефрагментированая ext4 реально тупит.Те же фильмы скачанные через многопоточку (надеюсь обьеснять не нужно что за программа) частенько тормозят систему(конечно можно поставить в программе просмотра кэш побольше, но если что то потом скопировать на резервный носитель то и копирование происходит быстрей.), и дефрагментация нужного каталога реально помогает.
если у тебя фрагментирован _каталог_ (что гораздо вероятнее чем факт фрагментации мелких файлов) в котором лежит миллион файлов - это безусловно будет влиять на производительность.Ну и рецпет простой - не надо их в зип, распихай по главам в подкаталоги, хотя бы.
>фрагментирован _каталогПапка,каталог- это логический уровень, он не может быть фрагментирован .Фрагментированые файлы в нем содержащие, но выше вы утверждали что фрагментация не вредит.При последовательном доступе -вредит ,при большом кол-ве файлов это вылазит наглядно,и кэширование не спасает.Разбивка на более мелкое размещение файлов лишь сглаживает проблему,дерево файлов просто в большенство случаев вмещаеться в кэш.Потому что вы забываете про перемещение головок жёсткого,это время на поиск дорожек.У твердотельных жестких согласен-там сейчас так наворочено, что срывает крышу у утилит статистики, там все сложно и частенько логическое расположение файлов полностью эмулировано.
>>фрагментирован _каталог
> Папка,каталог- это логический уровень, он не может быть фрагментирован.То есть, по-вашему, список файлов и их имён в директории из воздуха берётся?
> но выше вы утверждали что фрагментация не вредит
Фрагментация разная бывает. Вы попробуйте в следующий раз вместо дефрагментирования файлов просто перенести их из одной мегадиректории в другую, не удивлюсь, если вам даже станет чуть быстрее.
> дерево файлов просто в большенство случаев вмещаеться в кэш
На его сортировку нужно время. Сравните ls -1 и ls -1f на досуге.
откуда берутся снЕпшоты?https://translate.google.com/#view=home&op=translate&sl=auto...
> откуда берутся снЕпшоты?
> https://translate.google.com/#view=home&op=translate&sl=auto...А тебе там слышится звук "а", да?
У меня бтр фрагментировался дико, даже на ссд.
И чем это грозит скорости чтения с ссд?
> И чем это грозит скорости чтения с ссд?В случае btrfs это влияет на скорость получения ENOSPC.
>У меня бтр фрагментировался дико, даже на ссд.так и должно быть, любая cow так себя ведёт.
btrfs умеет autodefrag, если эта фича включена, фрагментация и производительность приемлимы даже при работе с qcow2 и БД.
Не помогло
>Не помоглоНа давно сильно фрагментированной системе и не поможет. Когда последний раз выполнялась оффлайновая дефрагментация? Очевидно, с этого надо начинать, не?
> У меня бтр фрагментировался дико, даже на ссд.Каким способом определял?
Косвенно, по деградации скорости загрузки и скорости запуска хрениума. Более 2-х раз ра 2 месяца. Напоминает поведение некрософт вантуза очень.
> Более 2-х разБолее, чем в два раза. Используйте годный слог, пожалуйста. Ни к чему это маркетингово-рекламная формулировка.
и это точно никак и ни в коем случае не может быть связано с, эээ, деградацией самих DB в профиле сей обывательской паматежорки? И многочисленные автоапдэйты расширений - тоже чесно-пречесно не при чём?...Другими словами - Ваш подход антинаучен; если серьёзно похожими методами тестировать - то надо автоматизировать тэсткэйс, при чём так, чтобы между запусками ВСЕ кэши сбрасывало. А вообще это не так сложно тестануть, например я могу - но бесплатно этого делать не буду, смысла лично мне за бесплатно с хромым заниматься - нет, я же его не использую.
> Для десктопа есть профиты относительно btrfs?Юзаю btrfs больше года на SSD под непрерывно обновляющуюся Manjaro.
Перед каждым обновлением ОС делаю снапшот. Со временем старые снапшоты переношу на HDD с резервной кубунтой (переношу именно разницу между старее и новее снапшотом).Несколько раз спасало от неспособности ОС запуститься (кривое обновление)... или поломки профиля браузера (возможно по вине ФС при жестоком ребуте).
К стати при TBW 100 Tб ресурс SSD 250 Гб за год снизился до 90%.
У btrfs есть сжатие и новое сжатие zstd не помню в какой версии ядра появилось сжатие zstd в 5 ядре точно есть.
К стати думаю можна отказаться от COW в пользу зжатия.
Сжатие без COW? А так можно?
Так сжатие нивелирует преимущество COW.
http://www.thg.ru/storage/ntfs_osvobozhdaem_mesto_na_ssd/pri...Вот что мне попалось. Раньше не интересовался сжатием на SSD средствами файловых ситем. Это о NTFS и Win. "Стоит отметить ещё кое-что. Информация, сжимаемая на лету, требует больше циклов записи на SSD, чем не сжатая. Это может негативно повлиять на долговечность привода. Мы не говорим о больших SSD, напротив, модели с меньшим объёмом памяти имеют более низкий уровень долговечности. Таким образом, NTFS-сжатие может значительно повлиять на их срок службы"
> http://www.thg.ru/storage/ntfs_osvobozhdaem_mesto_na_ssd/pri...
> "Стоит отметить ещё кое-что. Информация,
> сжимаемая на лету, требует больше циклов записи на SSD, чем не
> сжатая.Ну это понятно, при смене 1 бита в несжатом нада сменить 1 бит, а в сжатом перезаписать целый блок, или даже файл (зависит как сжата инфа).
Вот токо при COW ты не меняеш бит, а пишеш ещо один.
а один хрен - тебе надо распаковать ненужно, поменять бит, запаковать ненужно (без гарантии неизменности размера, что добавляет оптимизма) и теперь записать ненужно вместе с измененным битом.
В zfs добавляется еще очень интересный механизм кэширования, с удивлением смотрящий на всю эту вакханалию (потому что его писали и свои phd получали во времена, когда в пределах fs блок был фиксированного размера)типа утверждается, что мега-супер-современные-процессоры-с-прекрасной-новой-уязвимостью-забылкактамее делают это настолько быстро, что потери незаметны а выигрыш офигенен.
Реальные замеры на чуть менее супер и чуть менее быстрых показывают явный просер производительности даже на hdd (!) - но кого это, действительно, колебет-то?
> Ну это понятно, при смене 1 бита в несжатом нада сменить 1
> бит, а в сжатом перезаписать целый блок, или даже файл (зависит
> как сжата инфа).Это как раз непонятно. При поблоковом сжатии и правильно подобранном размере блока ФС количество занятых блоков будет ощутимо меньше, а количество записей максимум ± таким же (если ранее приходилось переписывать, условно, 2 блока по одному разу, то теперь, из-за сжатия, то же самое потребует перезаписи 1 блока 2 раза).
> при смене 1 бита в несжатом нада сменить 1 бит,
Угу, надо сменить 1 бит, но перезаписать все равно придется минимально доступный на запись размер, причем тут будет что-то типа MAX(page_size(flash), min_block_size(FS)) и это уже будут килобайты.
> Вот токо при COW ты не меняеш бит, а пишеш ещо один.
А для SSD есть разница?
Сжатие уменьшает количество записей на накопитель и продлевает его службу, если оно реализовано правильно. В NTFS используется отложенное сжатие, которое хорошо для производительности на HDD и плохо для долговечности SSD (NTFS была придумана когда были в основном HDD).
Большинство других ФС, в том числе ZFS, использует немедленное сжатие, что плохо для производительности, но хорошо для всего остального, включая компактность данных и долговечность накопителя (любого ныне поддерживаемого).
CoW вообще — разновидность сжатия, но в ФС всегда пишется отдельным пунктом, а сжатием в ФС называется сжатие диапазонов блоков одного файла. В ФС и CoW и сжатие блоков дописывают и перезаписывают только блоками, а не битами, так что в количестве перезаписей между ними разницы почти нет. Разница между ними только в алгоритме поиска способа уменьшить размер данных. Они никак не заменяют друг друга, но хорошо дополняют друг друга. Это особенно заметно по глюкам и тормозам программ, пишущих сжимаемые дедублицируемые многокопийные шифрованные файлы с CoW при фоновом удалении снимков ФС у бедных пользователей, которым не хватает денег на быстрое надёжное оборудование (как у меня).
Стоило поставить ext4 и отключить журнал + использовать timeshift.
Зачем эти костыли?
> Зачем эти костыли?журнал на ext4 (на ssd в аж 250 гиг) ? Именно что низачем этот вредный костыль не нужен.
Чем он вреден кроме того, что есть? Вообще об этом не задумывался, когда родителям отдавал свой старый Intel на 60 гигов. Жив до сих пор, работает под минтом в дефолтной конфигурации и отказывать не собирается.
> Чем он вреден кроме того, что есть?тормозами и лишним износом, вестимо. Особенно качественными и приятными при 64 или 128k размере страницы ssd.
Я, в общем-то, именно кривому журналу вменяю подозрения на 12309, ну то есть - бесовщину в этом именно месте чую, хотя обосновать не могу. (точнее так - меня эта проблема покинула вместе с журналом, но там одновременно поменялось много чего, и нет гарантии что журнал просто не вскрывал ее наиболее очевидным образом)
Я вот вообще не задумываюсь на ^has_journal - ни разу об этом не жалел.
понятно, что если компьютером раз в неделю пользуется бабушка посмотреть по скайпу на внука, ее эти проблемы не волнуют.
>Юзаю btrfs больше года на SSD под непрерывно обновляющуюся Manjaro.
>Перед каждым обновлением ОС делаю снапшот. Со временем старые снапшоты переношу на HDD с резервной кубунтой >(переношу именно разницу между старее и новее снапшотом).
>Несколько раз спасало от неспособности ОС запуститься (кривое обновление)... или поломки профиля браузера >(возможно по вине ФС при жестоком ребуте).В золотой фонд цитат ОПН. Всё что вам надо знать о Manjaro.
все что надо знать о линухе. Мажоры не виноваты - слепили из того что было.
У всех остальных ни разу вот не лучше и не надежней.
Мне кажется Debian понадёжнее Manjaro. Мой опыт использования Манджаро ограничился установкой на чистый диск, обновлением, перезагрузкой, отказом загружаться. И так 2 рада. С Дебианом не возникало никаких проблем.
>Манджаро ограничился установкой на чистый диск, обновлением, перезагрузкой, отказом загружатьсяУдваиваю
>>Манджаро ограничился установкой на чистый диск, обновлением, перезагрузкой, отказом загружаться
>УдваиваюНадо не удваивать, а ставить загрузчик. Тогда система будет загружаться после первой перезагрузки.
Ну сравнил ролинг с затоем...
Так то Linux на ядре 2.6 под SquashFS прошытый в Flash 10 лет назад ещо надьожнее.
> Мажоры не виноваты - слепили из того что было.В том случае который помню - system:D застрелился.
Нет. Да и btrfs вам ни к чему. Обе значительно проигрывают в плане производительности стандартной ext4.
> Обе значительно проигрывают в плане производительности стандартной ext4.Где?
производительность btrfs сильно зависит от того, насколько часто фиксируются изменения. Стандарнтное 30 действительно, даёт катастрофическую просадку производительности. Монтируйте с autodefrag,commit=120 и производительность приятно удивит. Понятно, что использовать большие времена в commit на системе без ups, не сильно разумно.
> Нет. Да и btrfs вам ни к чему. Обе значительно проигрывают в
> плане производительности стандартной ext4.А ext4 проигрывает в плане производительности стандартной FAT32, ну и т. д. И что?
э... в каком use pattern? fat32, вероятно, лучшая fs для сменных носителей небольшого размера, но мегаскорости к ее преимуществам никогда не относились.Ну разьве что для linear write с очень большим и ненадежным кэшом метаданных, но винда так не умеет, а линух тем более.
нет, exFAT для этих целей лучше FAT32, причём, значительно лучше. Но там жёсткая проприетарщина.
самсунь это почему-то совсем не беспокоит.Но насчет сравнения exfat и ntfs на сообразном тому и тому носителе (ну то есть от 256G вверх) я бы поосторожничал - хороших и убедительных тестов у меня нет.
>А ext4 проигрывает в плане производительности стандартной FAT32, ну и т. д.С отключенным журналом в большинстве операций ехт4 выигрывает у фат.Если бы так не было,гугл использовал бы фат, им журнал не нужен, у них кластеры и резервирования.У них не стояло ограничения в 4 гига на файл. Если где то произошёл сбой автоматом востанавливывается из образа, гугл говорил это быстрее чем проводить проверку диска.
>>А ext4 проигрывает в плане производительности стандартной FAT32, ну и т. д.
> С отключенным журналом в большинстве операций ехт4 выигрывает у фат.Если бы такв большинстве, полагаю, проигрывает.
> не было,гугл использовал бы фат, им журнал не нужен, у них
им нужны unix-like permissions, case sensitivity и прочие обычные юникс-фишки, иначе пришлось бы слишком много переделывать.
Ну и помимо "большинства" есть еще специфические, типа быстрого поиска в большой помойке - а у гугля там именно помойки.
Лучше, кстати, не знать как он устроен.Ну и вы все же не путайте патченную-перепатченную гуглем ext2 с той, которая у вас в ведре.
Та - вообще не работает.
>Ну и вы все же не путайте патченную-перепатченную гуглем ext2 с тойВ журнале linuxformat с инженером из гугла значить врут что используют ext4 с отключенным журналом, ещё фичу в ядро натягивали inofitu или как то похоже системный вызов назывался для мгновенного отслеживания изменённых файлов.
Единственное как сказал инженер чем отличалось у них 4 версия,у них уже тогда работал b-tree индекс и была уже внедрена контрольная сумма.В ядре эти фичи появились где то через 3-5 лет.
> В журнале linuxformat с инженером из гугла значить врут что используют ext4 с отключенным
> журналомне читатель я линухоформатов. Про использование ext2 были доклады самого гугля на самом, не поверите - гугле (когда-то так бывало). Причем достоверно известно что остальным в этот момент пользоваться ей активно нерекомендовалось из-за massive filesystem corruption, поэтому докладец и вызвал определенный резонанс. Но это было давно, и идею перехода на ext4 в тот момент они "активно обсуждали".
Полагаю, с тех пор и перешли, и , в очередной раз - попереписывали в ста местах, но на эту тему достоверной информации у меня нет.
у btrfs фрагментация со временем растёт, а производительность падает.
и ещё кучу раз у меня ломалась фс и система даже когда они заявили что btrfs стабильна.
если нужны снепшоты, то лучше zfs.
если не нужны, то ext4 для hdd, f2fs для ssd. у последней при поломке открытые редактируемые файлы заполняются нулями, но хоть фс вцелом не ломается в отличии от btrfs.
тут был коммент про то, когда уже завезут нормальный UFS как в 1990х, но его потёрли - видать у кого-то зычно бомбануло :)
> тут был коммент про то, когда уже завезут нормальный UFS как в 1990х, но его потёрливидимо, глупость мозолила глаза модераторам
нормальный уфс тебе уже завезли - диск 90х приходи, подарю. 20мегабайт, как ты любишь.
_мега_, я не опечатался.В эпоху 10T дисков, внезапно, подходы 90х оказались не у дел
> В эпоху 10T дисковЯ, кстати, не перестаю поражаться тому, насколько смело народ берёт 10T-диски. Я, конечно, понимаю, плотность упаковки в стойку, все дела, но неужели никого не парит время ребилда или репликации с нуля?
> Я, кстати, не перестаю поражаться тому, насколько смело народ берёт 10T-диски. Я, конечно,они на два градуса стабильно холоднее (из-за гелия)
> понимаю, плотность упаковки в стойку, все дела, но неужели никого не парит время ребилда или
> репликации с нуля?ну, в принципе, не - я и ребилдить не буду - сдохло, туда и дорога.
А если из них хранилки с быстрым доступом под прод какой собирать - то, наверное, завтра эта лавка либо продается гуглю, либо банкрот. Что пнем об сову...
> 20мегабайт [...] В эпоху 10T дисков [...]bait&switch'ите, "уважаемый". Во-первых. речь выше по ветке шла про SSD.
Во-вторых, в UFS есть целых три с половиной технологии "про это":
1) soft updates
2) journalling
2.5) journalled soft-updates
3) background fsck
Так что вброс как бы не по адресу.И в третих - по моей информации, практически всё, что выше 4Tb - это стрёмный трэш (забыл название технологии, сродни MLC - для изменения одного сектора надо перезаписать до восьми секторов). Лично я не рекоммендую использовать такие устройства для СХД - ибо, как говорил великий Ленин, "лучше меньше, да лучше" (вместо этого лучше добавить ещё устройств с "правдивыми" секторами - как бонус разнесётся нагрузка "по шпинделям" - будет больше IOPS)
> Во-первых. речь выше по ветке шла про SSD.о, да, как это я забыл про cylinder groups ;-) они все еще с нами, да, хоть и переименованные и современная disklabel не показывает эту часть.
Но таких дисков, без зон, у меня для вас нет, не сохранились.> Во-вторых, в UFS есть целых три с половиной технологии "про это":
те самые что "works as intended" - (c)самМакКузик
Ну, это еще проще - таких дисков у меня штук двадцать лежит, заходите, заходите.
Эти костылики и подпорочки продлили ей жизнь в их эпоху. "Их" - это 36G lvd scsi, прямые поставки из 2006го на машине времени, только у меня, и только пока действует портал! Заметьте, таких ssd тоже уже не делают!Правда, background fsck вел к паникам если система все же была повреждена, а не просто некоторое количество удаленных файлов недоудалилось при крэше, suj - к "undetected corruptions", но в целом, кое-как, жить можно. Вы еще про dirhash'и забыли (эти, вроде, разумнее чем линуксные).
А если вам все же в 2k19 - ставьте zfs, не выпендривайтесь. Поверьте, сейчас это лучшее из того, что вы можете получить от фри, не смотря на все грабли.
> в третих - по моей информации, практически всё, что выше 4Tb - это стрёмный трэш
все норм, с 4T на ufs тоже мучительно больно. А уж с несколькими...
А packed sectors - ерунда на фоне достижения, кажется, 98го года с soft sector marks и analog read with pattern recognition. И ничего, двадцать лет живем ("а говорили - землю жрать будете! - А ничего, жрем!") К тому же они только на 5krpm, вроде.
Ставьте размер блока в 128k, выключайте сжатие - разницы вообще не заметите. И по надежности тоже.
Разъясните, кто разбирается, на пальцах, с целью повышения уровня образованности. Чем сабж так замечателен по сравнению с обычными линуксовыми FS? Использую по большей части ext4/XFS.
Нормально работающий Copy-on-Write.
Снэпшоты на лету.
Сжатие данных на лету.
Дедупликация данных.
В отличии от btrfs работающий fsck и не умирает при заполнении fs до 100%Можно так же сказать что zfs заменяет ex4/xfs работающие вместе с LVM
> В отличии от btrfs работающий fsck и не умирает при заполнении fs до 100%угу, потому что сама fs умирает на 85 до полной неюзабельности
Правда, подождав всего пол-часика, пока отработает rm, можно вернуть ее к жизни, в отличие от развалившейся btrfs
> потому что сама fs умирает на 85 до полной неюзабельностивызывающе неверная информация. Сам забивал на 100% несколько раз (по недогляду, правда на FreeBSD) - машина продолжала быть настолько же юзабельной, насколько и с забитым на 100% UFS.
Хозяйке на заметку: полезно держать "аварийный" снэпшот с не-важно-чем _мегабайт_ на 20+ (да-да), чтобы в случае забития пула на 100% вместо поисков жертвы и раздумий - было что быстро удалить.
> вызывающе неверная информация. Сам забивал на 100% несколько раз (по недогляду, правда
> на FreeBSD) - машина продолжала быть настолько же юзабельной, насколько и
> с забитым на 100% UFS.Не знаю, как в ZFS, но в UFS по умолчанию резервируется 8%
как раз для таких случаев особо "умного" софта или пользователя
https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks....
Свыше 100% набивать диск сможет только root.
Хотя сравнивать с COW FS все же не стоит - концепты разные, на cow (исходя из концепта и логики - в реализации я не ковырялся) даже для удаления сначала нужен свободный блок для записи новых метаданных. Т.е. если забить cow FS действительно на 100%, то с удалением ненужного будут проблемы. А в реальности, при сильной фрагментации, проблемы начнутся ещё задолго до этого.
> Не знаю, как в ZFS, но в UFS по умолчанию резервируется 8%никак, типа сам дурак ;-) Но там другой прикол, отдельный (и понятный/предсказуемый).
С 85% совсем другая история, и она - дурная.
> никак, типа сам дурак ;-) Но там другой прикол, отдельный (и понятный/предсказуемый).В ZFS легко настраивается резервирование атрибутами ФС (несколько вариантов, можно комбинировать). По умолчанию резервирование = 0 байт. Но есть накладные расходы (системные данные тоже занимают место и иногда до фига), поэтому резервировать приходится с запасом.
Кстати, в btrfs будет пользовательское резервирование когда-нибудь? Лучше бы его сделали, а не квоты (работают, но почти бесполезны).
> С 85% совсем другая история, и она - дурная.С отказом ОС работать при нехватке памяти куча историй, и нет от них спасения нигде: linux, Solaris и другие ОС и при нехватке RAM, и при нехватке места на диске, и в btrfs, и в ZFS глючат, убивают случайные процессы (хотя достаточно убить Firefox), портят файлы настроек (потому что презирают распределённые файловые транзакции), портят исполняемые файлы (если закончилось место при обновлении программ и не используют файловые транзакции для обновления), отказываются продолжать работать и даже загружать оболочку пользователя до удаления файлов или снимков через Live CD или чудом загрузившуюся консоль, очень плохо проводят расчёты оставшегося места и др. Расскажите и вашу историю.
А истории у меня для тебя нет, уж извини - я не раз забивал и RAM и swap и FS одновременно (!), FreeBSD откилливала например браузер или жручий компрессор (как пример - nice xz -T0 -9e --lzma2=dict=512M,lc=2,pb=0,nice=273 --block-size=768M), и колом ничего не вставало, а данные - не пропадали. Ы?
> в UFS по умолчанию резервируется 8%демагогия.
Я когда говорил "на 100%", я КОНЕЧНО ЖЕ имел в виду FS, сконфигурированную с tunefs -m0/newfs -m0. Я нигде не говорил "на 92%".
Кстати, дополнительный бонус при -m <= 7% - FS размещает структуры более компактно, уменьшая фрагментацию.
>> в UFS по умолчанию резервируется 8%
> демагогия.Болтология.
> Я когда говорил "на 100%", я КОНЕЧНО ЖЕ имел в виду FS,
> сконфигурированную с tunefs -m0/newfs -m0. Я нигде не говорил "на 92%".Когда подразумевается нестандартная конфигурация, а под "100%" подразумевают не показания утилит типа df, а что-то свое - то обычно упоминают об этом, а не обвиняют потом в демагогии …
Сударь, Вы вообще представляете себе, что такое 100%?
Обьясняю для детей природы: 100% - это целая единица, ПОЛНОСТЬЮ.
Я под 100% подразумевал полные 100% и ни процентом меньше, а Вы с Вашими умолчаниями - доказанный демагог.
> Сударь, Вы вообще представляете себе, что такое 100%?
> Обьясняю для детей природы: 100% - это целая единица, ПОЛНОСТЬЮ.Сударь Теоретик, Вы вообще представляете себе, откуда обычно узнают, что "забито на x%"?
Вот отсюда:
df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/root xxxG xxxM xxxG 17% /
/dev/gpt/user xxxG xxxG xxxG 52% /usr
man df можете просмотреть сами.И вот так оно выглядит в реальности, а не в теории:
% df -h|grep md0
/dev/md0 96M 8,0K 89M 0% /mnt% dd if=/dev/zero > /mnt/foo/out
/mnt: write failed, filesystem is full
dd: stdout: No space left on device
181505+0 records in
181504+0 records out
92930048 bytes transferred in 0.793665 secs (117089751 bytes/sec)
% df -h|grep md0
/dev/md0 96M 89M 24K 100% /mnt
df показывает забитость на 100% и теперь писать можно только из под рута
# dd if=/dev/zero >> /mnt/foo/out/mnt: write failed, filesystem is full
dd: stdout: No space left on device
15617+0 records in
15616+0 records out
7995392 bytes transferred in 0.069059 secs (115776117 bytes/sec)% df -h|grep md0
/dev/md0 96M 96M -7,6M 109% /mnt
> Я под 100% подразумевал полные 100% и ни процентом меньше, а Вы с Вашими умолчаниями - доказанный демагог.Спасибо, я не был уверен - скорее наоборот, но вот теперь, после "разъяснений" подсчета процентов и пассажей "92%" "полные 100% и ни процентом меньше" , я вижу доказанного теоретика-болтолога.
Потому что не теоретик был бы в курсе "курьеза" с процентами и сразу понял бы, о чем речь.
типа 109% - это 100%
чёрное - это белое
война - это мир
анонн - intelligent
все всё поняли
то есть неюзабельной вообще, угу (и даже стереть не факт что сумеешь - у нас cow, а копировать-то некуда, еще ж не стерли ;)Но все гораздо интереснее при магической цифре 85 - рекомендую попробовать, на досуге - поржешь. (начинаешь с 80, запускаешь что-нибудь fs-intensive типа сборки небольшого пакета, чтобы подойти к 90 - и удивляешься. Нет, не надо выжирать до нуля, все интересное именно в этом месте)
хозяйке на заметку - не надо так делать. man zfs /refreservation - выставляется либо для /, либо для специальной fs "reserved", canmount=off (у меня обычно / и так off)
Удалять его не понадобится - проблему с "некуда cow при rm" он решит прозрачно, проблемы с 85% при этом физически не может возникнуть (поскольку это про пул, а не fs). Но эффект все равно занятный.
Ух как интересно! Вы будете смеяться, но я использовал название reserved, не зная о его (названия) особенности, именно в этих целях. Не могу теперь определиться - стыдно, или интуитивно понятный интерфейс?..
у него нет никаких особенностей, это произвольно выбранное мной имя, на мелких системах это вообще / - он немонтируемый.
"Особенность" в том что для такой fs (мной, ручками) выставляется refreservation - и для всей остальной системы на том же пуле это выглядит как fs, занимающая столько, сколько выставлено - при том что на самом деле место ничем не занято и оно может (и будет!) использоваться при необходимости.соответственно, не будет ни проблем с нулем, ни деградации производительности при пересечении границы 80%.
если у тебя система профессионального уровня и ты можеь выделить пд нужды обслуживания файловой системы ОТ 16+Гб, то будут плюшки типа практически неограниченного расширения, встроенных рэйд, дедупликации, дешёвых снэпшотов. При этом декларируется крайне высокая надёжность.Если выделять столько ОЗУ *только для ФС* в твоих условиях неразумно, фишки zfs в ПОЛНОЙ мере почувствовать не получится.
В этом случае, если нужны дешёвые снэпшоты, имеет смысл смотреть на btrfs (кстати, снимкм у неё несколько удобнее и гибче). По остальным фишкам btrfs старается быть не хуже zfs, получается по-разному.
Я плотно экспериментировал с btrfs с 17 года, сейчас активно использую в реальных задачах. С подстеленной соломкой (ни разу не пришлось воспользоваться), да. Но пока весьма доволен, что самого удивляет. Если фишки типа снимков, сжатия, проверки целостности данных, многодисковых штучек на уровне ФС не нужны, то ни zfs, ни btrfs у XFS не выиграют.
> Я плотно экспериментировал с btrfs с 17 года, сейчас активно использую в
> реальных задачах. С подстеленной соломкой (ни разу не пришлось воспользоваться), да.
> Но пока весьма доволен, что самого удивляет. Если фишки типа снимков,
> сжатия, проверки целостности данных, многодисковых штучек на уровне ФС не нужны,
> то ни zfs, ни btrfs у XFS не выиграют.Для домашнего компа, я так понимаю, это дело избыточно :). В него памяти-то макс. 32Гб лезет :D. (А ещё SAS-контроллер, собака, тупит и не находит диски. Корзину ему что ли прикручивать...)
> Для домашнего компа, я так понимаю, это дело избыточно :).16ГБ под ARC ZFS, да, избыточно. рекомендуемый размер кеша зависит от размера накопителя, для небольших SSD хватит и 8ГБ на всё.
>для небольших SSD хватит и 8ГБ на всё.нафига, извиняюсь, Зеттабайт Файл Сыстем на небольшом SSD?
Because i can!
> нафига, извиняюсь, Зеттабайт Файл Сыстем на небольшом SSD?*очевидно* же: компрессия, чексумминг, дедупликация (если RAM на dedup tables рассчитали), снэпшоты, бэкапы, безопасность (разделение jails/VM volumes, флаги ФС), всякие RAIDы и иерархии кэша искаропки (правда последнее больше актуально для связок неск. SAS/SATA SSD + NVMe), да и работает она довольно быстро, если не забивать на 99%. Но Вы же про стильномодномолодёжные SSD - а их забивать полностью вообще-то нельзя, такой вот двойной разводняк с ними...
>> нафига, извиняюсь, Зеттабайт Файл Сыстем на небольшом SSD?
> *очевидно* же: компрессия, чексумминг, дедупликация (если RAM на dedup tables рассчитали),у тебя такой медленный ssd? У тебя такой большой ssd что проявляется bit rot? У тебя так много лишней памяти и cpu на dedup? (не проще продать и купить второй ssd?)
> снэпшоты, бэкапы, безопасность (разделение jails/VM volumes, флаги ФС), всякие RAIDы и
снапы есть и у btrfs. Остальное вообще непонятно про какую такую безопастность.
> иерархии кэша искаропки (правда последнее больше актуально для связок неск. SAS/SATA
на десктопе, угу.
> забивать на 99%. Но Вы же про стильномодномолодёжные SSD - а
> их забивать полностью вообще-то нельзя, такой вот двойной разводняк с ними...одинарный - в смысле, refreserv защитит и от превращения ssd в тыкву тоже.
Нет, я пользуюсь zfs на мелких (совсем мелких - гиг оперативной памяти, и не вся она для zfs) системах, но это - с горя. Была бы в фре работающая ext4 - я бы пользовался ей. Снапов жалко, но я могу без них обойтись.
> снапы есть и у btrfsНету их. Есть клоны, которые названы снимками только ради маркетинга. Но они почти голые, если смотреть функциональность: резервирования на них нет, рекурсивных созданий снимков и клонов нет, делегирования прав нет, защиты от записи «снимков» только для чтения во время приёма нет, дедубликации с ними нет, имеющиеся функции (кроме CoW) неудобны в использовании. Эти функции самому не добавить — они должны поддерживаться в ФС.
> у тебя такой медленный ssd?я же говорю - и SATA, и M2/NVMe. Разница очень большая.
> У тебя такой большой ssd что проявляется bit rot?
1) их несколько
2) ще знають це у яслях малi дiти, що лучче перебдiть, чим недобдiти (с) Лесь> У тебя так много лишней памяти и cpu на dedup?
ещё раз - если рассчёт DDT показал, что на 2*датасэте dedup имеет смысл и возможен - то применять стОит. Если именно Вы таких рассчётов не проводили - то, включая dedup, Вами будет двигать глупость, мода, вера либо наваждение.
А CPU оно совсем не много ест, практически на любом камне top-end семейства с соотв.инструкциями за последние 9 (девять) лет, начиная с i7-980x (либо с бульдозеров). Тут больше роляет RAM latency, я так понимаю. Так не ставьте дешманскую RAM в дешманские же мамки.
Тут стОит добавить, что - по причине кэширования - RAM лишней не бывает. Это Вы и сами знаете, но тихонько делаете вид, что это не важно. А оно важно. Важно тем, кому важна скорость, чтобы задержки не отвлекали от рабочего процесса.
> снапы есть и у btrfs
В сравнении с их функционалом в ZFS - это не совсем так.
>>> иерархии кэша искаропки (правда последнее больше актуально для связок неск. SAS/SATA
> на десктопе, угу.см. выше - они разные. И, да. Но я creator, мне десктоп нужен не только чтобы котиков лайкать. Ок, зови его по старинке - "desktop workstation", как оригинально звучало; может полегчает.
> Ок, зови его по старинке - "desktop workstation"ну, блин, понятно что неплохо быть богатым и здоровым, но в обсуждениях именно особенностей десктопов лучше все же с этой ремарки - начинать.
там походу как раз уже кто-то о таких начал... про NTFS :)
> там походу как раз уже кто-то о таких начал... про NTFS :)чо не так с моим десктопом с ntfs?
8-OОн десктоп - реально на столе лежит. И "дискеты" с ntfs'ом тоже на столе, рядом.
никаких подводных камней в виде спрятанного под капотом i9 последней модели и терабайта оперативы с nvme
вот стоит ли тащить эту идею дальше "дискет" - я пока думаю. Но убедительных контраргументов (в отличие от ext4/zfs/etc) у меня не находится.
> ЗеттабайтНет там столько байт. 16 ЭиБ максимум получается создать. В названии и документации ZFS — ложь. Это как в шутке про 128-битные процессоры, которых не было.
> Разъясните, кто разбирается, на пальцах, с целью повышения уровня образованности. Чем сабж
> так замечателен по сравнению с обычными линуксовыми FS? Использую по большей
> части ext4/XFS.Хотя бы тем, что уменьшаться умеет по сравнению с "обычной" XFS.
> Хотя бы тем, что уменьшаться умеет по сравнению с "обычной" XFS.щито?!
или ты имеешь в виду "в самой распоследней версии стало уже можно выдернуть диск из vdev если это не raidz а простое ненужно"?
>Хотя бы тем, что уменьшаться умеет по сравнению с "обычной" XFS.да ну?
>>Хотя бы тем, что уменьшаться умеет по сравнению с "обычной" XFS.
> да ну?Ну да.
>Чем сабж так замечателен по сравнению с обычными линуксовыми FSВ btrfs есть косяк в днк- уже куча народа с ним сталкивалась при работе с мелкими файлами.
Это место для метаданных и журнала, оно создаётся при создание раздела,изменить утилитами в процессе можно.Но это нужно мониторить, иначе встрянеш в ошибку нет места и куча гемора на ровном месте.
( я не думаю что в одной компании работали одни маркетологи, они как раз на эту ошибку напаролись в процессе и балансировка не помогла: смотреть ютуб канал :сравнение и описание Бтрфс и ZFS)
При работе с БД алгоритм копирования при записи нужно отключать,это вторая ошибка в ДНК -при этом контрольных сумм нет.С починкой развалившего томапо прежнему грустно в обоих фс(бтрфс и зфс)
,как повезёт.
Погледев на это красная шапка уже приколотила костыль к ХFS ,
копирование при записи, контрольные суммы уже как 5 лет внедрены,единственный недостаток удаление мелких файлов .Глядеть в общем надо,у ZFS народ очень рекомендует публикацию отключать,и за свободным местом следить, иначе можно тоже словить острых ощущений.
рекомендует публикациюДубликацию сорри автокоректор
Вы вероятно про ДЕдуПликацию. В этой связи смею заявить, что дела с ней обстоят так же, как и с многими технологиями в IT сфере: нужно понимать, что это, как оно в общих чертах работает, какие у этой дедупликации требования по RAM на Ваших датасэтах, и стОит ли вообще овчинка выделки. As always - RTFM :)
> стОит ли вообще овчинка выделки. As always - RTFM :)да вот нету там fm, там скорее узун-кулак, длинное ухо, и бабки на завалинке. На практике я бы не советовал - оно даже у ентер-прайс оборачивается такими замысловатыми приключениями, что лучше купить вторую полку.
man zdb | grep -A4 -- -D
man bc
> man zdb | grep -A4 -- -Dи что он покажет ДО включения dedup'а? Именно - "all empty" или как там...
А после - уже поздно пить боржом, беги за новым i9 и ящиком оперативы.
То есть Вы перед применением вообще ничего не тестируете, а сразу 'в продакшн' и на авось. Ясно, понятно.
> То есть Вы перед применением вообще ничего не тестируетето есть ты такой богатый и здоровый, что у тебя есть пара сотен терабайт для потестировать как оно дружит с dedup? И машина времени, чтобы убедиться что через год ничего-ничего не изменится.
Что-то мне кажется, твои хранилки ограничены ржавым wd blue в одном экземпляре.
>, а сразу 'в продакшн' и на авось.
это называется - экспертное мнение. И да, у меня оно есть, и к нему - прислушаются.
А ты продолжай петь о тестировании.
> у тебя есть пара сотен терабайт для потестировать как оно дружит с dedup?бывает до сотни. Проблема?
> И машина времени
чтобы узнать про падение гигантского метеорита?
> через год ничего-ничего не изменится.
НЕ ПОВЕРИШЬ. На "моих" системах обычно* ничего без меня в этом плане не меняется. Вот так.
> мне кажется, твои хранилки ограничены ржавым
всё верно. Вы Бесусловно правы. Вам это только кажется.
> экспертное мнение. И да, у меня оно есть
о, так сударь - ыксперд? Чё, реально? И сановские (именно сановские) сертификаты есть? Сканы ффстудию :)
смеялсо.
> бывает до сотни. Проблема?очевидно, да, если ты собираешься что-то тестировать.
У меня бесплатных сотен (вместе с сотнями нежалко-данных для теста) как-то вот ни разу не случилось. Приходится верить людям на слово и надеяться на техподдержку.
Но себе и своему прошлому опыту я верю больше, поэтому с откровенно помойными технологиями стараюсь заранее разойтись подальше.> НЕ ПОВЕРИШЬ. На "моих" системах обычно* ничего без меня в этом плане не меняется. Вот так.
круто, маладец. То есть вот лежат у тебя "до сотни" (1 - это ведь тоже до? ;) терабайт ненужных данных, и никогда не меняются. Удобно. А на моих системах, внезапно, меняются и требования, и типы хранимых данных, и вообще что угодно - иначе бы нахрен я там был нужен, включили в розетку, все завелось, можно сократить ненужный персонал. Диски менять по мере выхода из строя и обезьянка может.
> о, так сударь - ыксперд? Чё, реально? И сановские (именно сановские) сертификаты есть?
голубчик, потрудитесь почитать википедию, хотя бы, для начального знакомства, что есть "экспертное знание" и как его приобретают. И зачем оно нужно, когда для "тестирования" требуется примерно новая вселенная, созданная где-то отдельно под столом.
Нет, сановских сертификатов у меня нет, и нахрен они не нужны - крайне маловероятно найти настолько богатых лохов, которые будут рассматривать вариант строить хранилки на базе прекрасного сана, если только уже не увязли по самые уши. Да и работать на них, скорее всего, малоприятно.
Внезапно, для б-жественной бубунточки - этими сертификатами ты сможешь спокойно подтереться.
Предвижу реакцию поха: под предлогом заботы о пользователях будут доламывать некогда хорошую файловую систему.> демон zsys, который позволит запускать несколько параллельных систем с ZFS на одном компьютере
А без демона они совсем не умеют? Что тут такого нештатного, что аж целый демон понадобился?
не переживайте, без них все хорошее доломают.
Если еще осталось что недоломанное.А эти доламывают систему интеграции в свой нескучный дистр - приключения с dkms видать показалось маловато и скучновато.
Кстати, попутно, это намек,что btrfs. видимо, все еще почти уже окончательно но немного не.
> Кстати, попутно, это намек,что btrfs. видимо, все еще почти уже окончательно но
> немного не.Что ж, тем забавнее будут читаться рекламные потуги Мейсона в блогах его рекламодателя.
откуда Cannonical знать что там с btrfs, у них же ни одного инженера не осталось, маркетолухи только?btrfs активно используется и развивается SUSE, но не Debian
Ubuntu делает две вещи: пытается продать труд дебианцев и запиливает никчемные костыли на выброс (3 версии Unity на помойке, Mir, который не взлетел, телефон), и этот окажется нежизнеспособным - выбросят (запомните этот твит)
> откуда Cannonical знать что там с btrfs, у них же ни одного инженера не осталось, маркетолухи только?От туда, что btrfs писал не специалист и принял ряд архитектурных решений, которые делают из btrfs непонятно что и не дают нормально пилить фичи.
а кто мне апдейт поломал - маркетолух?
Самый что ни есть инжинер, обожравшийся тухлого инжира.> btrfs активно используется и развивается SUSE
это какой такой suse - той что недавно выкинули на мороз, высосав все деньги из доверчивых лоxoв-акционеров? У нее еще есть какие-то "инженеры", а не полтора дефективных менеджера, специалиста по массовым сокращениям персонала? И они собираются делать то, что нишмагли ни redhatibm ни орацл, когда-то главный идеолог?
Не, вы шутите...> Ubuntu делает две вещи: пытается продать труд дебианцев
ничего что половина активно шевелимых дебиановских пакетов имеет убунтиного майнтейнера и гнездо на ланчпаде?
> это какой такой suse - той что недавно выкинули на морозНе соглашусь. Она как-то всегда умудряется выйти сухой из го... И очень востребована в узких кругах. В ядерной энергетике, например.
ну примерно понятно почему- там софт не обновляют по писят лет, вместе с реактором (вот узкоглазым-то и прилетело), но в конце-концов должны же те старые блоки начать разбирать по полному исчерпанию ресурса?
Ты со шляпой попутал, наверное.
> у них же ни одного инженера не осталось, маркетолухи только?Я эти байки слышал неоднократно от многих, но я не верю вам. И знаете почему? Когда-то дошёл до последнего этапа собеседования, на котором мне просто не хватило знаний. Там работают крутейшие и умнейшие ребята. Те, кто владеет одновременно и технической конкретикой, и общими взглядами на продукт. Весь техперсонал работает дома.
Обломавшись, я сейчас работаю в какой-то очередной транс-наци-ональной копрорации на несколько тысяч рабов, за ту ЗП, которую просил, продающей свой пердукт другим копрорациям, которые всем вам известны. Но ежели меня отсюда попрут, что весьма сомнительно, ибо я здесь уже несколько лет и меня пытаются удержать, то я снова постучусь в каноникал.
чего ж они при этом херню-то такую умудряются делать, а?
А кто делает лучше? Мне аж интересно стало... Альтернативу предложи.
> А кто делает лучше? Мне аж интересно стало... Альтернативу предложи.блжад. Да, надо читать что написано - наикрутейшие и умнейшие - это ж сравнительная характеристика. Видимо, имелось в виду, что в остальных местах анона встретил полный п-ц.
Верю, чо.
кстати, об каноникал, перед которой ты раболепствуешь, и о файловых системах:
как-то раз понадобилось мне подпердолить немного файловые системы
была скачана убанта лайв сиди
и в этой твоей убунточке была вырезена поддержка любого размера блока,кроме 4кб для файловой системы NTFS
ну ладно,думаю,вражеская файловая система, наверняка единичный случай
так нет же - подобные огранчения были и у других фейловых систем
например, точно не удалось отформатировать каким-то из рейзеров с размером блока 512
видимо супергениям каноникала виднее раз ониизачем-то вводят подобные ограничения......хотя возможно это был дебиан с нескучными обоями - фиг его знает...
но дебиан ещё хуже - там тупа меняют копирайты на свои и накручивают колличество пакетов
неужели всякие Шатворты и Габены выбирают дистрибутив ведясь на подобные шуллерства
> и в этой твоей убунточке была вырезена поддержка любого размера блока,кроме 4кб[skip]
вы прослушали поток шизофренического бреда, всем спасибо.
У тебя слишком много свободного времени чтобы разбираться кто из местных анонимов как отреагирует
> У тебя слишком много свободного времени чтобы разбираться кто из местных анонимов
> как отреагируетА во всех разбираться и не надо.
>> У тебя слишком много свободного времени чтобы разбираться кто из местных анонимов
>> как отреагирует
> А во всех разбираться и не надо.xyячьте ракетой, товарищ майор - Бог разберет своих!
А тут уже все равно ничего не поправить.
Хотелось бы NOVA FS увидеть, не ясно сколько его ещё делать будут, но SSD вытесняет HDD и не плохо было бы увидеть файловую систему разработанную только для SSD, так как тема актуальная.
А новостей о NOVA FS уже давно не было :(
> SSD вытесняет HDDГде я могу дёшево купить пяток зеркалированных терабайт, не будучи вышедшим на IPO ПБОЮЛ?
> Хотелось бы NOVA FS увидеть … разработанную только для SSD
Она не для классических SSD, она для NAND-ов с произвольной адресацией и решает абсолютно другие проблемы.
> файловую систему разработанную только для SSD
Что под этим подразумевается и зачем это всё нужно? Боитесь дырки в ячейках протереть? Если у вас бытовой SSD, то вы просто будете двойную работу делать, сперва на уровне fs, затем на уровне фирмвари диска. Если у вас на руках дорогие тырпрайзные решения, требующие бережного ухода, то, во-первых, я вам завидую, во-вторых, у вас уже есть JFFS, YAFFS и NILFS.
> у вас уже есть JFFS, YAFFS и NILFS.Ну и как я мог про F2FS забыть.
это недорогое ентерпрайзное решение - поскольку работать может только на флэшах от сасунг, ибо требует точных знаний внутренней архитектуры, которыми никто не поделится.
> это недорогое ентерпрайзное решение - поскольку работать может только на флэшах от
> сасунг, ибо требует точных знаний внутренней архитектуры, которыми никто не поделится.[citation needed]. В чём заключается неработоспособность на сторонних чипах? В том, что кто-то не умеет читать даташит на то, что напаивает на продаваемый девайс, и не попадает тем самым в размер erase-блока? Сложно представить другие сценарии хардварнозависимой поломки для FS, чья задача — тупо размазывать wear level по всему объёму.
Я, конечно, видел истории про деградацию производительности, но там, кажется, прикол не в заточке под конкретные чипы, а просто в том, какой тип логов выбирается в зависимости от заполненности и как они назад собираются.
> требует точных знаний внутренней архитектуры
FS или хоронилища данных?
> В чём заключается неработоспособность на сторонних чипах?там архитектура заточена под точное знание, как этот самый чип внутри устроен (при том что доступа к этому знанию извне не предусмотрено, и вообще-то предполагалось что это fs для mtd, а не для обычных ssd) - иначе оно банально неэффективно. А учитывая что в ssd поверх запросто может быть навернутая производителем "оптимизация" исходящая из наиболее вероятного применения (то бишь ntfs) - то вообще один вред.
> В том, что кто-то не умеет читать даташит на то, что напаивает на продаваемый девайс
как будто ентерпрайз снабжают даташитом, а не булшитом...
То есть если этот ентерпрайс самсунь - то, наверное, сам себя - снабжает, и то не факт.
т.е. работать-то будет - но тормознее, и ускоряя износ, а не наоборот, как было задумано.
И да, понятия не имею, какой (хотя бы!) размер страницы у наших ssd.А хомячкам достаточно "это ж сасунг! Они сказали - она лучшая для флэша! бегом ставить!". Документацию они не читали и не будут.
А сасунг тем временем в мабилы пихает ext4, а в телевизоры - вообще exfat.
На месте они не стоят. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... Только я не как не пойму или не знаю это новое ядро каждый раз добовляет проблем которые надо исправлять переодически с появлением нового ядра, или это не зависит от ядра, а раньше эти проблемы не увидили? Или и то и друго вместе? Вопрос любому кто захочит ответить. Что-то с трудом представляю, чтобы для exfat или ntfs после того как они появились делалось огромные по кооличеству изменения. exfat и XP потдерживает через патч.
Что-то с трудом представляю, чтобы Microsoft для exfat или ntfs после того как они появились делалось огромные по кооличеству изменения. exfat и XP потдерживает через патч.
ну вообще-то ntfs у нас нынче пятой версии с не вполне совместимыми расширениями - не все, что можно записать десяточкой, прочтется потом XP. А до нее еще и совсем несовместимая четвертая имела место быть. То есть это не банальное исправление ошибок (про которое ms не очень любит рассказывать) а вообще изменения и в структуре и в апи.
Про третью не помню, но, полагаю, тоже что-то было.exfat существенно проще f2fs, тут надо скорее с ext4 сравнивать.
Ну, убунточка всегда была образцом маргинальности решений, так что не удивительно.
Понятно, через неделю откажутся, целую фс тащить какой нет в debian по умолчанию, слишком сложно окажется для 1,5 индуса в марковской шарашке.
Очень верное решение Canonical'а, учитывая всплеск интереса к использованию зфс. Как бы ехт4 ни хвалили, но эта фс не гарантирует 100%-ной надёжности - почитайте хотя бы топики на лоре, где у людей с ехт4 на ровном месте накрываются данные и сыпется фс.
Не знаю, что там на лоре, но на ext4 тут, полагаю, большинство по многу лет сидит, так что сказки можно не рассказывать.А убунта в данном случае пытается сделать "как редхет, но по-другому" - у тех совершенно уютный и стандартный lvm with thin provisioning + XFS.
Не знаешь, так зайди и прочитай, а пока сказки рассказываешь только ты. Ехт4 малонадёжная фс, пруфов вагон.
мне, вот, сейчас стало весьма неуютно. Форматить рэйды под данные в NTFS что-ли?
> мне, вот, сейчас стало весьма неуютно. Форматить рэйды под данные в NTFS
> что-ли?если ридонли - то я всерьез сейчас смотрю именно в эту сторону. (в частности и потому, что на самом деле уже отформатировано)
а чо, хорошая ж fs. Всего на 20 лет устаревшая, это ж не на 50...
И утилит для восстановления хватает.
>Ехт4 малонадёжная фс, пруфов вагон.А чего тогда эту малонадежную фс
"люстра" в качестве ядра использует? (Да, сейчас уже можно накатывать и на btrfs и на zfs ,но весь функционал этих фс пока не используется)
Поймите, убить можно любую фс, есть примеры умирания томов ZFS ,хотя там резервирования ого какое.В любой фс есть важные участки, или производительности будет никакой.Включи полный журнал в ext4 и надёжность вырастет на порядок, тем более сейчас наконец то контрольные суммы довели до ума,но на производительность не жалуйся.
Вот UDF на флэшки не пошла,хотя её убить невероятно сложно,эта фс пошла с двд,у неё коды Рида и Соломона используется,а все из за низкой производительности и последовательной записи.
> А чего тогда эту малонадежную фс "люстра" в качестве ядра использует?так люстре-то пофиг - навернулась, перезалей ноду или новую запусти на ее месте.
> Включи полный журнал в ext4 и надёжность вырастет на порядок
наоборот. Надежность вырастет если выключить журнал и включить async.
Журнал вчетверо увеличит число записей, а они у нас ни разу не атомарные. Не говоря уже о том что сбой питания непосредственно во время записи или порча битиков в ram между записями тоже ведут к фатальным результатам.
журнал страхует только от одного - непредсказуемой потери данных, которое таза банных уже считает успешно положившимися на носитель, без необходимости начисто отключать кэширование.
> Вот UDF на флэшки не пошла,хотя её убить невероятно сложно,эта фс пошла с двд,у неё
> коды Рида и Соломона используетсямалыш, ты бредишь. ECC используется в самом механизме dvd, а в udf никакого контроля данных ни разу не предусмотрено. В 92м году на него не хватило бы мощности процессора. Если что - он в hdd тоже используется, более того, там без него бы вообще давным-давно ничего уже не читалось.
В современных версиях ext4, если ты не в курсе - можно включить. В zfs используется только для метаданных, и не всегда это заканчивается хорошо.
>они у нас ни разу не атомарныеВолшебное слово барьер не слышали?Да оно появилось позже, но появилось.
>ECC используется в самом механизме dvd, а в udf никакого контроля данных ни разу не предусмотреноЕсс это только коррекция 1 или 2 бита на 64 бита,без возможности востановления.Читай Криса Касперского, он очень подробно описывал 3-х уровневую модель коррекцией ошибок, просто что бы выжать побольше ёмкость многие производители дисков уровень 3 не записывали,для двд выйгрыш около 120 МГБ. Udf спецификация 95 года, блин,какой 92 год?.Двд если склероз не подводит в 96 или 97 появился.Сам проигрыватель производил коррекцию ошибок,да да рида-соломона, центральный процессор в том не участвовал.
Теперь насчёт кодов коррекции в _Udf:
Версия 2.50 Значительное обновление файловой системы, которое перевело ее на абсолютно новый уровень. Теперь формат UDF имеет раздел метаданных, который облегчает общую группировку метаданных. Помимо этого, данная файловая система стала гораздо более безопасной, так как была заметно упрощена процедура восстановления информации и опциональное дублирование данных файловой системы. Система работает с Windows Vista и выше. - Читайте подробнее на FB.ru: https://fb.ru/article/197011/faylovaya-sistema-udf-chem-otkryit
> Волшебное слово барьер не слышали?барьер неспособен сделать неатомарную запись - атомарной.
Он способен только навредить производительности и надежности (запись стала идти чаще - больше риск попадания в момент выключения питания/прохеривания ядром памяти) и снова лечит только другую проблему - как-то увеличить шансы что то, о чем ты думаешь, что оно давно уже записалось на диск и не рискует быть потерянным - таки на диск - записалось.До их появления у меня был прекрасный случай, когда кусок сетевой конфигурации просто испарился с диска - вместе с файлом в котором был, и без всяких сообщений об ошибке. Через неделю(!) после того как был создан. Зато fs - как новенькая. Угу, примерно на момент после установки и откатилась ;-)
> данная файловая система стала гораздо более безопасной
да-да, гораздоещеболеебезопастной. Не вижу тут ничего про коррекцию ошибок.
Не читайте вы на ночь мурзилок, честное слово. И забудьте уже про udf вместе с dvd дисками - никому неинтересно с точностью до года помнить события времен РамзесаII, а хорошего в ней не было - ровным счетом ничего.
>Не вижу тут ничего про коррекцию ошибок.Из спецификации :
UDF 2.50 April 15, 2003 131
6.8 Extended Attribute Checksum Algorithm
/*
* Calculates a 16-bit checksum of the Implementation Use
* Extended Attribute header or Application Use Extended Attribute
* header. The fields AttributeType through ImplementationIdentifier
* (or ApplicationIdentifier) inclusively represent the
* data covered by the checksum (48 bytes).
*
*/
>Через неделю(!) после того как был создан.Это встречается и в других фс, я лично встречался с такой сетуацией на ntfs,после проверки диска.У меня ещё ситуация была, один и тот же файл по разному виделся в операционных системах,это я про ntfs и драйвер ntfs-3g .
>около 120 МГБИзвиняюсь соврал , можно для двд выжать до 520 Мегабайт, то есть с отключеным уровнем 3 диск вмещает 5,2 гига, но надёжности некакой.А вскоре в евросоюзе приняли закон что без видимых повреждений диск считается браком производителя и одноразовые диски ушли на помойку.
> "люстра"
> уже можно накатывать и на btrfs и на zfs ,но весь функционал этих фс пока не используетсяЛюстра-на-ZFS использует ZPL (POSIX FS), а более низкоуровневые куски этого комбайна, то есть встаёт в один ряд пищевой цепочки с ZPL и ZVOL. Использования всей функциональности там и не может быть.
> Люстра-на-ZFS использует ZPL (POSIX FS)s/использует/& не/
> Не знаю, что там на лоресборище скудоумных, какая им еще zfs, они и ext4 умудрятся поломать (а дать им в руки стеклянный хер - так вообще хорошо если сам убежишь)
> А убунта в данном случае пытается сделать "как редхет, но по-другому" -
> у тех совершенно уютный и стандартный lvm with thin provisioning + XFS.э... ты вот правда считаешь эту невменяемую поделку стандартной и тебе с ней уютно, или у тебя там данные конторы, их не жалко, все равно есть еще снапшоты на уровне хранилки и vmware ?
А ext4 не надо ломать. Она, так сказать, "из коробки".
Вот например из glibc 2.24 пришлось выкручивать readdir_r() потому что "не шмогла".
Мне это помню неслабо доставило, потому как в тот момент как раз тыкал пальцем в не реентерабельный код (atop afair). С предложением по быстрому махнуть readdir() на readdir_r().
И тут на такое.
>В Ubuntu 19.10 появится экспериментальная поддержка ZFS для корневого разделаНнннннееееееееттттт!!! Это значит майка и до bsd доберется.
Читаю комменты - и так странно: шёл 21й век, версия ядра lo0nix росла как на дрожжах, а данные у них терялись...У меня же всё просто, как и 10 лет назад:
1) мало RAM и есть legacy бинарники => UFS
2) мало RAM и нету legacy бинарников => HAMMER
3) много RAM => classic ZFSс дешевыми снэпшотами ввезде всё ок, но это UNIX, детка.
> 2) мало RAM и нету legacy бинарников => HAMMERО, неужели есть живые пользователи? И долго используете? За все ли фичи трогали? Первый или второй? Как там с page cache? Лишним ребалансированием не страдаете? <ещё тысяча вопросов по мотивам поломок zfs и btrfs>
Долго, но не под все задачи - из-за legacy blackbox'ов (ынтырпрайз зло).
За все фичи, но не все с самого начала :) вот только репликация - ночти с момента появления.
Хаммер - первый. Второй ещё даже не щупал нормально, времени нет :(
Годами полёт нормальный на больших i/o нагрузках, реально ни одного серьёзного замечания, скорость даже в сценарии "HDDs only" - очень даже.А если на ящике нету особых требований по storage, то обычно ленились и использовали UFS - снэпшоты есть, а чего ещё надо?
Все вышеперечисленное надёжно настолько, что никогда никаких потерь данных не случалось, несмотря на крэши, которые бывали и не раз (stress/fuze testing + сами виноваты). Один раз лет 8 назад пошли бэды на WD RAID edition 750Gb, но TLER+GEOM вывезли без вопросов.
в догонку: и да, на UFS приходится по cron'у сверять контрольные суммы, иначе о порче данных не узнать, в отличии от ZFS. Это его минус. Так же могу сказать, что в отличии от гнутых систем, прямые - не встают колом при активной записи, а продолжают быть вполне отзывчивыми. Даже если ZFS старьё времён до FreeBSD-10 и удалять снэпшоты десятками тысяч. Да, в старых ZFS удаление огромного количества снэпшотов происходит не моментально.
Oo, это история про стрекозу??
Если так, то снимаю шляпу.
Да не только. Под разные задачи есть разные инструменты. Если надо молодежне докеры шмокеры - то тут FreeBSD c cbsd/bhyve, а если ящик чисто балансер-фаервол, то в OpenBSD PF новЕе будет. В осстальном - да, она.
А права доступа в ZoL детальные уже завезли? (Это те, в которых чтение данных отдельно от атрибутов и расширенных атрибутов, запись отдельно от добавления в конец и удаления: https://docs.oracle.com/cd/E27998_01/html/E48433/shares__sha... , http://www.ntfs.com/ntfs-permissions-file-advanced.htm .) Без них linux выглядит каким-то отсталым даже от Solaris. Но, возможно, это я что-то пропустил.
> А права доступа в ZoL детальные уже завезли?%$!$!$!
Так завезли, что вывезти не можем третий год.
Смотри сюда:
1 14 0xffffffff80200000 c62680 kernel
2 1 0xffffffff80e64000 362790 zfs.ko
3 2 0xffffffff811c7000 2b90 acl_nfs4.ko
4 2 0xffffffff811ca000 242d8 krpc.ko
"как думаешь, я его просил двенадцатидюймовый - теннис?"
Убунта форматирует раздел в тип zfs_member и потом орет что не знает что это))Zvol&zfs сделал фс с правильным типом - убунта не монтирует)
Зато монтируется через zfs нормЗакинул туда (опция архивация+дедуп) свалку - на чтение вроде работает быстрее ext4
Мне понравилось zfs+gluster. Много места но скорость падает в три раза)))
Заполните свалку на 60% — упадёт в 10 раз. Но это всё равно лучше, чем нехватка места на диске как у остальных, верно? (При нехватке места на диске считайте скорость записи равной нулю.)
Помню-помню лет 10 назад ставил фряху на корневой ZFS, хорошо было.
Рассказываю впечатления от убунта+zfsУстановка:
Начал ставить как обновление 18.10
В результате полетела разбивка. Установка с любыми опциями упиралась в надпись что grub2 не может в uefi вписаться и поэтому ничего не загрузится. Вылечилось тем что убрал в биосе uefiи оставил GPT.
Убунта сразу установилась.Работа: сжатие включил: экономит 35% примерно на диске. дедупликацию убрал.
Свободной оперативки стало заметно меньше.Не знаю что ее теперь сжирает но браузеры теперь упираются в потолок.
ZFS ктото научил врать: при записи она все сбрасывает в кеши и рапортует что все "окей, босс", а через пару секунд начинает все раскладывать куда надо и система дико бьется с диском.
Вобщем, блажь все это. Если zfs куда и ставить так под файловую свалку куда редко лезешь и радоваться архивации, дедупликации, авто копиям итд, а там где надо часто читать\писать лучше оставить ext.