Опубликован релиз проекта OpenZFS 2.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после переноса поддержки FreeBSD был признан основной реализацией OpenZFS и был избавлен от упоминания Linux в названии...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55433
z-фска рулит! ещё б ее на rust переписать!
Дефрагментацию так и не запилили? Тогда не нужно.
Зачем вам дефрагментатор? На zfs возможна лишь фрагментация свободного пространства, но не данных.
Это на коровах-то (CoW) "но не данных"?
Лечите кого-нибудь другого.
На коровах почти любая запись в файл фрагментирует данные by design.
прямо "by design"? что, этот "design" запрещает копирование элемента целеком? насильственно заставляет делать это только для отдельной страницы? или все таки есть варианты?
> На коровах почти любая запись в файл фрагментирует данные by design.ARC в помощь.
И как наша доблестная жанночка решит проблему фрагментации на носителе?
Как раз причина, почему ZFS идёт нахер - если ему не отдать памяти по горло, он нормально работать не будет.
Совсем не решит, но существенно облегчит дело за счёт сериализации данных перед сбросом.
А по поводу памяти -- ну так сначала надо выбрать ФС, удовлетворяющую вашим нуждам, а потом уже систему заказывать. К слову, рама стоит вообще копейки.
Так собственно да, и это не ZFS :)
в zfs же RoW, а не CoW
FoW там. Fragment on Write или Fuckup on Write, как кому привычнее.
Дефрагментация на HDD слишком тормозная и неэффективная, а на SSD вообще бессмысленная
> Дефрагментацию так и не запилили? Тогда не нужно.В высокоэффективных файловых структурах - система располагает данные для целевого назначения (максимальной производительности, минимального обьема и т.п.) и делает она это в соотвествии со своим порядком, а никак не твоим представлением, где и как должны лежать цельно-выровненные файлы...
Ротационным накопителям пофиг на "свой порядок" у альтернативно одарённых, для них оптимальное расположение - последовательное.
> Ротационным накопителям пофиг на "свой порядок" у альтернативно одарённых, для них оптимальное
> расположение - последовательное.с разморозочкой, ваш MS-DOS давно уже немодно.
В многозадачной системе с множественным параллельным доступом к данным, причем как правило ни разу не linear, оно ни разу не будет оптимальным. Особенно с учетом того забавного факта, что у данных есть еще и метаданные, и их тоже надо читать каждый раз.
Оптимальным был бы хитрый interleave знающий точно о том что и какими кусками будет читаться, но за неимением /dev/astral - обходятся блоками разумной длинны и размещением метаданных немножко более разумным способом чем в твоем любимом fat.
Ну и какими кусками твои DLL'ки читаются? Правильно. Целиком. Времена мсдос с 512к и оверлеями того, кончились.
Какими попало они читаются. Ага, кончились.
Теперь кодовые страницы _mmap_аются. И читаются только при получении page fault (то есть неиспользуемые - вообще никогда). Там есть еще block size, prefetch и прочие фокусы, чтоб уж совсем по 4k не читать, но в целом мир устроен изрядно сложнее чем тебе кажется.Впрочем, один раз записанный файл скорее всего уляжется на диск последовательно или около того - страдания секты свидетелей фрагментации начинаются когда файл переписывается на ходу. Для бинарников это немного странно.
> страдания секты свидетелей фрагментации начинаются когда файл переписывается на ходу. Для бинарников это немного странно.Кстати, это нормальный режим работы БД
без тебя мы бы об этом ну никак не догадались. Кстати, зачем тебе понадобилось подменять тему разговора?Сколько процентов лично на твоем диске занимают какие-то там "биде" - 0.001 ?
Насколько часто им при этом нужен sequential доступ, даже если бы процент был целый один ?
> без тебя мы бы об этом ну никак не догадались. Кстати, зачем
> тебе понадобилось подменять тему разговора?
> Сколько процентов лично на твоем диске занимают какие-то там "биде" - 0.001
> ?
> Насколько часто им при этом нужен sequential доступ, даже если бы процент
> был целый один ?Ну и смысл было агриться? С тобой же никто не спорил.
Базочек у меня в наличии имеется. Процентов 10 займёт.
А вот чтобы последовательный доступ -- хз. Это, наверное, колоночное хранилище должно быть. У меня таких нет
> когда файл переписывается
> на ходу. Для бинарников это немного странно.Исполняемый файл не переписывается, его банально нельзя открыть с правами на запись и исполнение. Что бы запущенный экзешник возможно было переписать, Микрософт набангалорила удивительное по своим габаритам технологическое отверстие, через которое сливаются все права на файлы и проч.
> Ну и какими кусками твои DLL'ки читаются? Правильно. Целиком.Вы удивитесь, но образы Portable Executable (dll в частности) в Вашей любимой Виндос вообще не читаются. Они _отображаются_. Сначала -- заголовок, потом -- релокации (если требуется) и импорт/экспорт. На этом всё. Далее сектора файла отображаются в страницы ОЗУ при доступе к командам/данным.
Полноценным твердотельникам ещё более пофиг - у них внутри данные всё равно раскладываются так, как хотят они, а не софт.
Да и в современных ЖД c LBA адресацией, соседние номера блоков часто не являются соседями физически. Скорей правила хорошего тона, чем жесткий закон, что надо хранить последовательно.
Охохо.
Ладно, оставлю вас пребывать в уверенности, что LBA каждый сектор по диску рандомно размазывает.
Но если учесть, что единица чтения с диска - дорожка, в основном, нет, можно и индивидуальный сектор, но время чтения будет не сильно меньше... короче, оставлю.
Шел 21 век, но почитатели LMR продолжали молиться своему старом богу. В то время как HMSMR контролится самим жестким диском. Фрагментация? Помолимся, братья...
Проблемы рейда с парити (raid6) так и не решили?
Что за проблемы?
> Что за проблемы?РОССЫПАЕТСЯ ЖЫ.
Детали можно? У меня есть несколько, пока проблем не наблюдаю
> Детали можно? У меня есть несколько, пока проблем не наблюдаюНу так пока всё не рухнет, проблем и не будет. Когда в результате аварии на диске окажутся неконсистентные данные (в частности, среди прочего, парити постоянно теряет консистентность), рейд не сможет восстановиться и придётся вытягивать что получится с дисков по отдельности. Я про эту проблему 6 рейда. Насколько я знаю, разработчики btrfs из-за этого до сих пор настоятельно не рекомендуют уровни 5 и 6. У zfs это "вроде как" не та проблема, однако фундаментально она не решена до конца и в ней.
эта "проблема" вызвана исключительно рукожопием автора btrfs. Ни малейшего отношения к zfs не имеет, и, кстати, никакого "raid6" в zfs нет. Есть raidz2, и теперь еще и draid2, которые ни разу не "raid6".
А вот этого я и не утверждал. Вот только и без btrfs она существует, это концептуальный недостаток рейда. Как ты его ни назови.
она без btrfs не существует.> это концептуальный недостаток рейда
нет, это твои влажные фантазии и слышанный звон.
Проблема с разрушением рейдов в btrfs - это чистой воды проблема btrfs. Скорее всего - ошибки в математике, как уже было на ранних этапах существования md raid, а может еще и неуемная оптимизация (когда в результате записывается не то и не туда, зато очень быстро - как было, и, похоже, в редких случаях осталось у lvm, восстановлению такой не подлежит). К сожалению, авторы предпочли забить и не искать причину - им и так не дует.
Проблема "raid write hole" ничего общего с этим не имеет, это другой слышанный тобой звон. Он в другом ухе. И к катастрофе не приводит.
Write hole -- ошибки в математике, что?
ты совсем тупой и не умеешь прочитать два абзаца раздельно, а не слив в своей дырявой голове в одну кашу?В btrfs - ошибки в математике (и вероятно еще и логике). Свои собственные, анал0г0внетные.
То, что ты или твой такой же тупой тезка слышал про "общую особенность raid" - write hole. К btrfs и ее проблемам никакого отношения не имеет, но вы феноменально т-пые и не можете отличить одно от другого.К zfs ОБЕ эти истории ни малейшего отношения не имеют.
Там все в порядке с математикой, ее человек с математическим образованием писал, и именно это место отдельно проверял, а write hole там by design отсутствует, поскольку тот чувак еще и неплохим инженером был.К сожалению, сплыл.
Даже не читал и не собираюсь. Как и тебя, Манечка. Однако, говоря о зфс, если именно девайс с логом отвалится, проблемы будут. Не так ли? У неё свои недостатки. А что, парити у зфс совсем не деградирует? Если уж у хардварных рейдов проблема нормально не решается, то что можно сделать софтом? Всегда умиляли эти поклонники зфс, а как посыпется, становитесь главными нытиками. Хотя это и не raid6, о котором разговор был. Понятно конечно, что рейд не замена бэкапам, но все данные забэкапить нельзя, а резервирование дорого стоит. Как по мне, основные претензии к зфс в довольно низкой эффективности, что особенно заметно становится с нынешними объёмами данных. Ну не получается цветочек глиняный у них, ну никак. А вы всё обмазываетесь и верите в лучшее.
как ты ловко переодеваешься прям в воздухе.>Однако, говоря о зфс, если именно девайс с логом отвалится, проблемы будут. Не так ли?
не будут. это пофиксили, теперь логу разрешено отваливаться без последствий.
>А что, парити у зфс совсем не деградирует?
опиши что за проблема
если ты имеешь ввиду деградацию зарядов на пластинах, то
1. инфа на диск пишется в виде данные+ЕСС
2. в зфс все обложено CRC кодами + имеются механизмы самовосстановления + рекомендуется делать регулярный scrub.
т.е. об этой проблеме инженеры были в курсе и все необходимое для её решения предприняли когда проектировали zfs.>Если уж у хардварных рейдов проблема нормально не решается, то что можно сделать софтом?
ты удивишься, но в аппаратных рейда тоже работает софт, только места там мало и особо умную прошивку не сделать.
>Всегда умиляли эти поклонники зфс
а меня умиляют хейтеры, у которых знание предмета ограничивается статьёй в википедии.
>Как по мне, основные претензии к зфс в довольно низкой эффективности
эффективности чего?
>Ну не получается цветочек глиняный у них, ну никак
так опенсорс же! включайся в работу, сделай лучше. =)
> РОССЫПАЕТСЯ ЖЫ.Вы с btrfs перепутали.
Не Raid6, а Raid5. В ZFS этой проблема нет, так как пишется не страйпами, а блоками, часто короче чем полный страйп и нет частичной перезаписи спрайпа, которая как раз вызываетт write hole в raid5. Из-за такой организации Raidz в ZFS не масштабирует количество рандомных доступов, только throughout.
оно хоть на расте написано или опять на сишные грабли наступают?
>>Добавлена поддержка горячего добавления памяти и CPU.Осталось добавить поддержку видеокарт, Wi-fi, пятикнопочной мыши, управление скоростью вращения кулеров и тогда будет годная файловая система для повседневного использования.
Systemd-zfsd
Лучше не напоминай про systemd, это такая хрень, что капец
Да, кстати, вы просили напомнить о systemd!
Хорошая вещь кстати! Я очень рад что наконец-то не приходится параллельно поддерживать ещё и баш-портянки для тех же пакетов, собиравшихся под чентось6.
Лучшая файловая система по совокупности потребительских характеристик!
Нет, свободное место утекает.
Стандартное свойство cow-систем на базе древовидных структур.
Это линуксоиды сэр... они могут критиковать ZFS так как ее лицензия знатно троллит пингвинов и при этом же восхвалять Btrfs которая является копипастой на ZFS но под идеологически правильной лицензией
У btrfs есть ещё одно важное отличае от zfs - способность внезапно и гарантировано похерить ваши данные...
Это да. Если ZFS похерила данные, назад уже ничего не вытянуть.
Потому что ВСЕГДА нужно делать бекапы, разнесенные физически. Никакой ZFS от молотка, пожара и кривых рук не защищает.
А вообще, структуру повреждённого RaidZ вполне можно прочитать утилитами восстановления из Винды, если религия позволяет.
>А вообще, структуру повреждённого RaidZ вполне можно прочитать утилитами восстановления из Винды, если религия позволяет.это какими?
>>А вообще, структуру повреждённого RaidZ вполне можно прочитать утилитами восстановления из Винды, если религия позволяет.
> это какими?ZFSin например
>>>А вообще, структуру повреждённого RaidZ вполне можно прочитать утилитами восстановления из Винды, если религия позволяет.
>> это какими?
> ZFSin напримертак это еще альфа
>>>>А вообще, структуру повреждённого RaidZ вполне можно прочитать утилитами восстановления из Винды, если религия позволяет.
>>> это какими?
>> ZFSin например
> так это еще альфаТебе шашечки или ехать? 90+% опенсорца - альфа по жизни, но тем не менее - работает и используется.
>Лучшая файловая системаЗачем же ты упомянул xfs в новости про zfs?
Очень по линуксячьи гордится чужими разработками, а именно XFS от SGI...
А ZFS от Sun чем не угодила? Тем что лицензия не позволяет включить ее в ядро?
Вангую что если когда нибудь ZFS сменит лицензию на BSD, линуксоиды взревут от восторга и будут вопить какая ZFS крутая
Не так важно, кто разработал, важно, что быстро работает (и не деградирует по скорости со временем), и гораздо более эффективно расходует память.
Быстрее FAT сложно придумать
>Быстрее FAT сложно придуматьНет,ехт4 с отключенным журналом работает быстрее.
Ехтенты сэр,быстрее только RAW режим.Ну может еще exfat покажет схожую скорость.
ExFAT лютый апрейд FAT, раньше она так и называлась FAT64
Насчет ext4 с отключенным журналом, ну так это тот же FAT только с экстентами
>Насчет ext4 с отключенным журналом, ну так это тот же FAT только с экстентамиНе ,b-"дерева" у фат нету.Из-за этого с каталогом где до хрена мелких файлов работает шустрее фат.
>ExFAT лютый апрейд FAT,
Хреновый апгрейд-шифрования нет,сжатия нет.Зато добавили ACL (опционально).
>>Насчет ext4 с отключенным журналом, ну так это тот же FAT только с экстентами
> Не ,b-"дерева" у фат нету.Из-за этого с каталогом где до хрена мелких
> файлов работает шустрее фат.
>>ExFAT лютый апрейд FAT,
> Хреновый апгрейд-шифрования нет,сжатия нет.Зато добавили ACL (опционально).В инфраструктуре FreeBSD за шифрование отвечает GELI. И в целом нет необходимости делать очередную тупость внедряя в каждой FS свое шифрование. GELI шифрует FS целиком.
GELI не шифрует ФС, оно шифрует блочные устройства.
> GELI не шифрует ФС, оно шифрует блочные устройства.Ну а блочное устройство в 99% случаев что содержит в себе?
ФС и блочные устройства - это разные вещи вообще-то.
> GELI не шифрует ФС, оно шифрует блочные устройства.Хотя замечание в целом правильное. Функционал GELI значительно шире чем шифрование отдельной FS.
Отсутсвие B+ дерева в структуре FAT историческое
Не работает, я проверял. Ну т.е. линейная скорость для 1 файла может и выше на пару процентов, но когда начинаешь работать с файлами, скорость падает в пол из-за отсутствия возможности эффективно работать с метаданными.
Быстрее FAT вообще ничего сдохнуть не может. А эти волшебные две копии FAT, дефолтная работа с которыми от Майкрософт позволяет потерять данные ещё быстрее и надёжнее...
> Не так важно, кто разработал, важно, что быстро работает (и не деградирует
> по скорости со временем), и гораздо более эффективно расходует память.QNAP так не считает и все расставила по своим местам. Какая трагедия для Линуксоидов.
QTS - Entry and Mid level Linux based system.
QES - Enterprise level FreeBSD based system. И ожидаемо ZFS
QNAP это поделка для домашнего использования. Поэтому совершенно неважно, что там внутри.
> QNAP это поделка для домашнего использования. Поэтому совершенно неважно, что там внутри.Хорошая попытка, как обычно от оголтелого линуксоида обосрать железку ценой так 5000-10000 долларов.
Ну и конечно хотел бы я посмотреть на домашнего пользователя который приобрел бы себе такую штучку за такие деньги...
Ну... Dell\EMC на бтрфс, Portworx на бтрфс. Думаю твоё мнение - это последнее что их может заинтересовать.
QNAP - это унылое SOHO в лучшем случае.
> QNAP так не считает и все расставила по своим местам. Какая трагедия для Линуксоидов.даже мелкая помойная лавка начала переходить на линукс - какая трагедия для глупых фанатов.
Пока да, только те коробочки что подешевле. Но не беспокойся, те что подороже тоже там же будут. Как уже произошло с iX. Пупсики хочуть доскер. Зачем им докер на _сторадже_ - сами не знают, но так модно, так у всех, подавайте и нам.
https://ps.reddit.com/r/DataHoarder/comments/mmjsgu/update_t.../
все что надо знать о "качестве" и "ентер-прайсности" qnap.
Ну если вам истории с remote root, который пол-года не могли исправить, недостаточно было бы.
Жги, Г-ди! Нет тут праведников.
Ты бы вниматель thread прочитал - "We jumped away to another BSD/ZFS based vendor and are pretty happy so far."
И никто не хочет линукс никак. Вернее происходит все с точностью наоборот что ты тут накалякал. Enterprise идет в BSD и линукс в домашние помойки..
А весь докер под FreeBSD замечательно разруливается jailами без топорности тормознутости докера.
> Enterprise идет в BSD и линукс в домашние помойки..Утверждение - ниочём.
Dell\EMC - на 5-6 чентоси, а касательно самого овняного Dell-repellent - MFS-BSD. Так что тут - бабка надвое сказала и решения принимались без тебя.
Еще один любитель подменять тему. Речь шла - об "ентерпрайзности" а по факту китайской помойности qnap, которая ни надежного железа не умеет, ни хотя бы поддержки клиентов - заменить горелый хлам на точно такой же хлам пол-года не может (потому что китайцы не успевают, а складов в US у них нет). И что приводить ее как свидетельство пригодности технологии для энтерпрайза - надо быть полным дураком. Обычная подвальная лавка, даром что с юрлицом в US.
Что тот тред и подтверждает (да и не он один).А что некоторые люди ничему не учатся и попрыгали away - это личные проблемы некоторых людей. Дальше будет еще один тред, про "неназванный прошлый раз вендор - тоже оказался УГ, кто бы мог подумать да и было ли, чем", не сомневаюсь.
> И никто не хочет линукс никак.
расскажи это разработчикам iX. Они, если ты не в курсе, по совместительству разработчики freebsd. Ну, это ненадолго теперь, конечно.
> А весь докер под FreeBSD замечательно разруливается jailами
докер никак не разруливается джэйлами, потому что докер - это _репозиторий_. Готовых бинарных образов. Которые в линoops просто docker run, и в винде просто docker run. А у тебя - никак вообще.
А пупсики хочут чтоб у них работало.
Спасибо за ссылку.
Вы можете отключив зфс фичи и покрутив настройки затюнить её до состояния XFS и дальше.Только смысла нет, отказываться от функционала.
брехня, если бы лично не сравнивал на больших файлах XFS и EXT4, то может быть и повелся бы
Ты полный бред несешь. Может потому что ты банальный неуч и неудачник по жизни
Твой порт всё дудосил!
Кто то использует для себя или в проде?
Поставили на нее постгрес, выжрало 200 гигов оперативки (не считая стандартного кэша, который reclaimable). Норм.
Ты наглядно показал свой уровень администратора. Ниже плинтуса. Руководитель этого чудика есть тут? Гоните его в шею...
Речь об использовании своего кеша и перевода primarycache в metadata?
> Речь об использовании своего кеша и перевода primarycache в metadata?А теперь давай перевод сего перла в терминах именно ZFS.
primarycache=all - это кеширование arc'ом буквально всего, а metadata - тут все и так понятно. Проще говоря, используем родной высокоэффективный кеш постгреса и запрещаем кешировать данные базы arc'ом. Или вы имели в виду что-то другое?
> primarycache=all - это кеширование arc'ом буквально всего, а metadata - тут все
> и так понятно. Проще говоря, используем родной высокоэффективный кеш постгреса и
> запрещаем кешировать данные базы arc'ом. Или вы имели в виду что-то
> другое?Кэширование кэшей бд и т.п. ZFSом даже звучит глупо. Эти вещи надо выделять на отдельные SSD и т.п.
Сдаюсь.
> primarycache=all - это кеширование arc'ом буквально всего, а metadata - тут все
> и так понятно. Проще говоря, используем родной высокоэффективный кеш постгреса и
> запрещаем кешировать данные базы arc'ом. Или вы имели в виду что-то
> другое?Да, чтобы система была эффективна ВСЕГДА необходимо ручками поработать и головой. Создатель системы и файло-системы не знает о твоих задачах.
В винде ты просто форматируешь в NTFS и оно просто работает. И под базу и под игры и под софт и под 3дмакс и под фотошоп и под торренты. И даже под виртуалку с убунтой.
>> Поставили на нее постгрес
> В винде ты просто форматируешь в NTFS и оно просто работает. И под базу и под игры и под софт и под 3дмакс и под фотошоп и под торренты. И даже под виртуалку с убунтой.А в огороде бузина ...
>В винде ты просто форматируешь в NTFS и оно просто работает. И под базу и под игры и под софт и под 3дмакс и под фотошоп и под торрентыЭм, нет. Высоконагруженой базе всегда нужен тюнинг ФС в том или ином виде.
А на домашнем ПК любая ФС просто работает, и под базу и под игры и под софт.
> Эм, нет. Высоконагруженой базе всегда нужен тюнинг ФС в том или ином виде.Эм да, в данном случае это особенность ЗФС. Приходится иногда тюнить настройки кеширования и ARC. То, что она сама не может определиться с оптимальными на лету - это техническая недоработка, хоть и не критичная.
А другие ФС могут? У них внутри ИИ-гномик сидит который волшебным образом понимает характер нагрузки?
Хорош прикалываться.
> В винде ты просто форматируешь в NTFS и оно просто работает.Получить возможность создать программный RAID-5 можно, начиная только с Windows Pro. На Windows Home никаких программных RAID средствами ОС создать не получится — только средствами драйверов чипсета сторонних производителей (AMD или Intel).
Лицензия на использование Windows 10 Pro стоит $289.00 с официального сайта microsoft.com или ~12 000 руб. по рыночной цене в российской рознице.Да, работает просто. Но за это придётся заплатить.
Windows 10 Pro
500 рублей цена вопроса на авито, ну или 400 на ибей.
Речь идет как обычно о газификации лужи.
-- "Что бы работало хорошо надо все сделать верно, но тебе я не скажу как верно, ты там сам разрули и догадайся. И вообще ты ****".
От таких советчиков лучше держатся подальше.
А так да, жрет zfs как не в себя.
Для виртуализации дома - шикарная вещь!
Дома - сойдет. А вот при продовой нагрузке никакой памяти не напасешься.
Аппетит arc легко унять с помощью zfs_arc_max, но правильный подход состоит в том, чтобы определить необходимый размер для ваших типичных нагрузок по попаданиям в кеш.
Размер то можно еще как-то контролировать, а вот распределение нет. Поэтому получается что спустя какое-то время памяти вроде еще предостаточно, только на физическом уровне она фрагментирована безбожно. Запрашиваешь мегабайт - получаешь мегабайт, логически цельным куском, физически из ошметков памяти.
А давно ли оперативка является линейным хранилищем?
Можно расшифровать RAM?
Как только ограничиваем память, тут же скорость падает, причем да же ниже чем старый mdadm на ext4. Никак не лечится, увы и ах. Нужна скорость, Вам не в ZFS, какая бы она не была классная.
И дома, и на производстве.
Но не в качестве одной-единственной-универсальной файловой системе.
А как у вас с рекавери?
Ну те при каких обстоятельствах теряли данные?
> А как у вас с рекавери?
> Ну те при каких обстоятельствах теряли данные?Я ж написал: тогда жёсткий диск кирдыкнулся. Напрочь.
Хорошо - у беня бэкапы всегда 3-2-1:
- минимум 3 копии
- минимум на 2 независимых носителях
- минимум 1 копия в другом здании
А без бэкапов на ZFS жить совсем никак?
Ну типа как у меня сейчас зеркало геомом а поверх юфс2 и потерю одного диска я переживу.
> А без бэкапов на ZFS жить совсем никак?Да легко!
Делаем пул из двух дисков, назначаем избыточность=2 и только в путь!
Можно слепить пул из трёх дисков, и назначить избыточность=3...
Простецкий RAID-Z из четырёх дисков...
Там много чего можно "нарисовать"...
> А без бэкапов на ZFS жить совсем никак?Бэкапы и RAID — две ортогональные технологии хранения данных.
Одна отвечает за сохранность (даже в оффлайн), другая — за бесперебойность работы.
"Ты у мамы дурачек?"https://www.qnap.com/en/product/series/enterprise
Да еще и на FreeBSD по совместительству.
Какая трагедия для Линуксоидов.
QNAP все расставила по своим местам
QTS - Entry and Mid level Linux based system.
QES - Enterprise level FreeBSD based system
А в чём трагедия-то? Кончай бухать.
Я поинтересовался как у людей которые её юзают дела.
И я не линуксойд, у меня фря даже на том десктопе с которого я вам это пишу, и я по немногу коммитю в порты и даже в базовую систему (в основном ядро).
И мотивации для вопроса у меня две:1. У меня дома хранилка собрана на geom mirror+eli+concat и UFS2.
Нагрузка примитивна: скачать торренты/раздать торренты, посмотреть торренты.
На тазике райзен 2700 + 64гб с ецц, которые не очень то заняты тем что там крутится, минимум половину можно было бы чем занять без проблем.
Те я как бы могу позволить себе свалить на zfs, но данные потерять не хочу и бэкапить мне это некуда.
При этом фичи в виде кеша и *как её там, когда оно пишет каждый раз в новое место при измении файла* мне не интересны, а вот крипта интересна.
Идея в том, чтобы повысить надёжность и упростить менеджмент.
2. У нас на работе юзается фря и зфс, но нам не хватает спеца по зфс который хотя бы мог консультировать. Пока оно тупо работает в дефолтах. И у меня есть подозрения что феолты не очень, особенно в том месте где используется geom mirror для зеркалирования на второй диск вместо средств самой zfs.
>[оверквотинг удален]
> потерять не хочу и бэкапить мне это некуда.
> При этом фичи в виде кеша и *как её там, когда оно
> пишет каждый раз в новое место при измении файла* мне не
> интересны, а вот крипта интересна.
> Идея в том, чтобы повысить надёжность и упростить менеджмент.
> 2. У нас на работе юзается фря и зфс, но нам не
> хватает спеца по зфс который хотя бы мог консультировать. Пока оно
> тупо работает в дефолтах. И у меня есть подозрения что феолты
> не очень, особенно в том месте где используется geom mirror для
> зеркалирования на второй диск вместо средств самой zfs.Geom/mirror Geom/Geli swap тут развлекаюсь. А если и ELI, не даели с флешкой, которая загрузочная
> 2. У нас на работе юзается фря и зфс, но нам не
> хватает спеца по зфс который хотя бы мог консультировать. Пока оно
> тупо работает в дефолтах. И у меня есть подозрения что феолты
> не очень, особенно в том месте где используется geom mirror для
> зеркалирования на второй диск вместо средств самой zfs.:facepalm:
Я уже перестал удивляться той среде, в которой ты существуешь. Найти проблемы в перегреве VRM Gigabyte в дросселях с лого (и ничем другим) — это нужно иметь особенные мозги.
забавно что в TrueNAS решили сделать наоборот =)
https://www.qnap.com/en/product/series/enterpriseДа еще и на FreeBSD по совместительству.
ПыСы. Для удаляющих - кому адресовано предыдущее удаленное сообщение было - он его получил.
Дома норм, пару сгнивших блоков данных отловил.
Каши не просит. Кеширование работает очень неплохо.
Что за дерьмо, простите, вы юзаете на подложке, что у вас родной ECC накопителя "сгнившие блоки" не отлавливает? Какие-нибудь доисторические б/у WD, на авито купленные?
Контролируйте свой пожар.Биты могут флипаться где угодно.
На больших объёмах и временных промежутках неисправимые ошибки неизбежны.
Накопитель же, если и отловит, то не скажет какой файл повреждён.
Чувак. Эти сказочки о битфлипах на накопителях и волшебной ZFS - со времён царя Гороха - только сказочки.Битфлип на собственно хранимых данных ловится ECC диска, который очень многобитовый. И не вызывает никаких "повреждений файла".
Если ECC не осиляет скорректировать - будет "битый сектор". Чтобы поймать при чтении лажу - надо этот битый сектор вычитывать 100500 раз, тогда, может быть, звёзды сойдутся, и флипнутся уже 100500 бит "как надо" - но это эксклюзив для мазохистов.
Битфлипы могут на шине возникнуть при передаче данных, но в случае допустим SATA/SAS - это тоже уже практически не актуально, во-первых битфлип на дифференциальной паре - это редкость редкая, во-вторых, на шине есть CRC.
Основная же масса реальных битфлипов возникает в (условно) битой RAM с авиты и прочем битом железе, и остаётся незамеченной, потому что все контрольные суммы при записи посчитаются уже с битых данных.
Современная архитектура систем хранения такова, что ECC/CRC покрыто всё.
И если ещё память покрыть ECC (что по сути давно должно было стать нормой, процесс тормозил только штеуд, не запиливавший ECC в десктопы) - единственным местом, где что-то может совсем уж бесконтрольно флипнуть, остаётся сам CPU. Такие дела.
> Чувак. Эти сказочки о битфлипах на накопителях и волшебной ZFS - со времён царя Гороха - только
> сказочки.угу, главное ж свято веровать.
В волшебную ECC, например.
И ни разу не прочитать ни одного учебника по теории кодирования.
После чего "сказочки" внезапно превращаются в банальную статистику, а к людям, сующим свой "CRC" куда надо и куда не надо - возникают очень интересные вопросы. Например - какой длины был исходный полином и почему НИГДЕ этой информации нет. И, отдельно - а почему у нас ДВА crc (на самом деле их пять но про остальные успели забыть вчерарожденные).А если еще немножко знать о том, как prml диски читают 'данные' методом угадава, то жизнь станет совсем непрекрасной, зато удивительной.
Чувак, о моём отсутствии расскажи вон тем четырём торрентам хозяина этого компа, стоящим на 99.9%
Один блок не находится в сети, хоть ты тресни.
При этом, видеоряд без глюков, jpeg без глюков.
А это потому, что у автора торрент при хэшировании словил меня :)
>99.9%Похоже на давний баг некоторых клиентов, например, у меня на transmisson такая ерунда была. Вроде исправили уже несколько раз.
> Что за дерьмо, простите, вы юзаете на подложке, что у вас родной ECC накопителя "сгнившие блоки" не отлавливает? Какие-нибудь доисторические б/у WD, на авито купленные?Гелиевые 16ТБ от сигейта, например.
Сначала zfs поругался на чексуммы, через несколько дней и релокейты/ошибки чтения появились.
Используем ту версию ZFS, что идёт в бубунте 20.04. Полёт нопмальный, лямы OIPS.
Всё что было раньше - спотыкалось на read-range locks. Так исторически сложилось, что б-жэственная ЗФС изначально не предназначена была для нагрузок, типа СУБД. Но где-то в 2019 году это подправили. Я доволен.
> Кто то использует для себя или в проде?OpenZFS стала менее предсказуемой в режиме восстановления. Поэтому постепенно перевожу единичные носители на проверенную годами UFS2+SU.
FreeNAS используем в роли файлопомойки ...
Вполне себе ничего ... пару дисков отправились в цифровой рай - без проблем.На новых дисках не пробовали - стоят 6Тб от сигейта и хитачи.
Работает и работает.
Ну я использую. 30Тб данных (SSD), striped raidz1. 50 вм, нагрузка на дисковую не очень большая, но постоянные send/recv, клоны, снапшоты, откаты. Все отлично работает
Не самая быстрая фс зато удобная. Убунта, hdd, ssd - все норм уже полгода
Скорость уже давно променяли на надежность и это как не странно нормальн, ведь если данные потеряны кому какая разница какая там скорость
CDDL - УГ-розовой-снежинки нельзя допускать к чему-либо стоящему.
У писаки новости когнитивное расстройство?
Насколько я помню у проекта созданного Illumos всегда было только одно название OpenZFS.
А ZoL это достаточно корявый проект (со стороны лицензирования) по интеграции OpenZFS в ядро Linux. И это погоняло "ZoL" официально не существовало, кроме как в воспаленных мозгах фанатиков пингвина.
"ZFS on Linux" много лет развивался параллельно с ZFS от Illumos как отдельный форк для Linux. Раньше OpenZFS было названием инициативы для взаимодействия и обмена патчами команд, занимавшихся ZFS в Linux, FreeBSD, macOS и Illumos. После того как "ZFS on Linux" портировали для FreeBSD и стало очевидно, что по функциональности и уровню сопровождения он давно перерос ветку от Illumos, создали новый репозиторий OpenZFS, поместили туда код "ZFS on Linux" и объявили, что теперь будут разрабатывать "ZFS on Linux" под этим именем. До этого OpenZFS никакая редакция не называлась.
> После того как "ZFS on Linux" портировали для FreeBSD и стало очевидно, что по функциональности и уровню сопровождения он давно перерос ветку от Illumos, создали новый репозиторий OpenZFS,ZoL выбрали (и портировали) как раз из-за окаменения иллюмос-апстрима ...
Боюсь, таки это был просто удобный предлог.Выбрали ее дЭффективные менеджеры, те же самые, что следующим же ходом "выбрали" в качестве платформы для будущих новых версий truenas ("случайно" платящего зарплаты всем ключевым разработчикам) линoops вместо фри.
Все ключевые технологии отсутствовавшие на тот момент в ZoL, но наличествовавшие в bsd и важные для промыва ушей клиентам - влиты, включая героическую поебду над discard. Может толком и не работают даже, но галочки в промо-материалах стоят в нужных клеточках. Иначе клиенты могли не оценить и перестать заносить новые транши. А больше ваша bsd низачем не нужна, проект можно закрывать и увольнять ненужных более мавров.
С прикручиванием influxdb справятся и студенты на гранты delphix.
>> После того как "ZFS on Linux" портировали для FreeBSD и стало очевидно, что по функциональности и уровню сопровождения он давно перерос ветку от Illumos, создали новый репозиторий OpenZFS,
> ZoL выбрали (и портировали) как раз из-за окаменения иллюмос-апстрима ...И портировал ее, судя по всему, Мейси "Вайргард"
https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...
Это все, что нужно знать о "качестве" ZoL.
Если бы он реально развивался параллельно Illumos то давно бы был под родной GPL лицензией. А так ваши потуги очередной раз притянуть код под лицензией CDDL в достоинства линуксописателей, оправдывая это какой-то чушью из вики - очередной раз смешны...
> А так ваши потуги очередной раз притянуть код под лицензией CDDL в достоинства линуксописателейОна изначально была под CDDL, долбонашка. А линуксоиды, которые тебе так не нравятся, занимаются развитием ФС. И той самой прослойки SPL, которая и на твоей бздшэчке используется. И преобразование семантики из соляро-вантузной(которая в соляре) в нормальную линуксовую, и попутно бздэшную - сделали почти полностью линуксоиды.
> И преобразование семантики ... и попутно бздэшную - сделали почти полностью линуксоиды.Какая занимательная (нет) хрень ...
Какую ФС линуксоиды смогли создать сами? Серию кривых ext, которая только к четвертой версии смогла сравнятся с древней XFS?... но так и не сравнялась ведь ведущие коммерческие дистрибьютивы предлагают в 2021 всю ту же пропатченную XFS 30 летней давности как нечто новое, модное и молодежное
_та_ древняя xfs была точно таким же дерьмом как ранние ext или даже хуже.С лимитом в 2 гигабайта и прочими прекрасными унаследованными фичами времен "когда компьютеры были большие".
> всю ту же пропатченную XFS 30 летней давности
не ту же. От той очень мало что осталось, к счастью. Этой в целом можно было бы пользоваться - если бы она хоть что-то из современных требований умела (без помощи франкенштейна из lvmных прослоек). А они - вот - смотрите, смотрите - уже почти но еще не осилили уменьшение разделов!
Которое скоро уже и не нужно никому будет совсем.
А в чем корявость ext4? xfs например нельзя шринкнуть, а ext4 можно(регулярно пользуюсь), то что в дистрибах по умолчанию обычно расчитано на ленивых админов но не как не лучший выбор
>> А так ваши потуги очередной раз притянуть код под лицензией CDDL в достоинства линуксописателей
> Она изначально была под CDDL, долбонашка. А линуксоиды, которые тебе так не
> нравятся, занимаются развитием ФС. И той самой прослойки SPL, которая и
> на твоей бздшэчке используется. И преобразование семантики из соляро-вантузной(которая
> в соляре) в нормальную линуксовую, и попутно бздэшную - сделали почти
> полностью линуксоиды.Мне интересно 5000 знают они что це такэ)
https://en.m.wikipedia.org/wiki/OpenZFS> 2008: Development of a native ZFS Linux port started, known as ZFS on Linux.
> 2010: illumos was forked from OpenSolaris as its open-source successorВы станете возражать, что википедия не является официалтным источником информации о ZFS и OpenZFS, но официальный FAQ ссылается именно на эту ствтью: https://openzfs.github.io/openzfs-docs/Project%20and�...
> Additional information about OpenZFS can be found in the OpenZFS wikipedia article.
Не хило ты факты тасуешь, а теперь ответь на один простой вопрос? У кого линуксоиды сперли код под сановской CDDL? Не у OpenSolaris случайно?
линуксоиды, ага, размечтался...Там оба источника написаны одними и теми же ребятами, мастерами подделывать историю.
А вот тебе правда, для разнообразия: да, была бесполезная мертворожденная поделка llnl, лет пять почти просуществовавшая.
2008: Development of a native ZFS Linux port started
2013: The first stable release of ZFS on Linux
Ничего так сроки, как тебе кажется?
Все это время, те кому на самом деле было надо - пользовались тормозной и падучей fuse-реализацией. Потому что та хоть как-то работала, а поделка llnl не имела (сюрпрайз!) vfs интефрейса к ядру вообще.
То есть умела только vdev раздавать. Ну оно понятно, для этого переписывать солярисный код особо не понадобилось.Тем что сейчас называется "posix layer" (а на деле vfs реализация для линoops) мы обязаны скромно НЕ упомянутому в принципе индусскому коллективу из бангалора. Еще лет пять назад гуглился (уже без упоминания сделанного) а потом и вовсе пропал.
Эти ребята херачили день и ночь, и наклепали с нуля vfsную часть за меньше чем год. После чего всем индусским кооперативом продались какой-то .inc с уже адресочком в долине силиконовых сисек. И, полагаю, получив вожделенные h1b, бесследно в той долине растворились, mission accomplished.
Код, к счастью, успел всплыть на шитхабе. Вот на нем-то весь нынешний "openzfs" и вырос как поганки вокруг трухлявого пня.
Угу, хорошая фэнтэзя прям за душу берет... особенно 2008 год и FreeBSD 7 с ZFS на борту
Ты все еще не научился пользоваться логами vcs?r168404 | pjd | 2007-04-06 05:09:06 +0400 (Fri, 06 Apr 2007) | 11 lines
Please welcome ZFS - The last word in file systems.
Все начинали в примерно один и тот же момент с одного и того же - кода из opensolaris, ВНЕЗАПНО ставшего доступным и при этом поддерживаемым.
При этом pjd сделал работающую реализацию, хотя и не без странных фокусов, в макоси на пути встал лично Йопс, заявивший "мое первое правило бизнеса с моим другом Ларри - не иметь никаких бизнесов с другом Ларри", после чего попытки вести разработу внутри самой apple (у которой в тот момент вообще не было никакой работоспособной на современном железе fs) быстренько свернули, а силами энтузиастов протрепыхались еще несколько лет, но так приличного качества ничего и не родили, в винде одно время шли нюх-в-нюх с макосью (то есть еще нельзя было пользоваться не понарошку, но уже запускалось и работало), а в линoops... ну я знал людей, всерьез использовавших fuse-версию в production. А куда деваться-то, еще чтоль что-то было в конце нулевых? Ее в общем тоже активно пытались пилить.
А потом как-то все кто в лес, кто по дрова разбрелись - совпадение? Конечно же ж, совпадение!Смена лицензии на one true oracle совершенно непричем.
Все это время параллельно существовала линуксная in-kernel реализация имени ливерморской лаборатории, феерично бесполезная, ибо собственно файловой системы не имела.
Если б не те работящие индусы - так бы по сей день только fuse и была бы у л@п4-х
Ещё бы swap довели до работоспособного состояния, а то он как бы есть, но вызывает гарантированный капут https://github.com/openzfs/zfs/issues/7734 . Того глядишь и hibernation на hdd заработает. Неужели нет башковитых, которые способны это поправить?
> Ещё бы swap довели до работоспособного состояния, а то он как бы
> есть, но вызывает гарантированный капут https://github.com/openzfs/zfs/issues/7734
> . Того глядишь и hibernation на hdd заработает. Неужели нет башковитых,
> которые способны это поправить?SWAP в ZFS пихать?? Да вы знаете толк в извращениях.. И все только ради того чтобы ручками изначально диск не разбивать? Дабы выделить место под SWAP?
Ну, сжатие свопа и динамическая аллокация места полезные вещи.Впрочем, лично я противник гибернации. Это было ещё ок на 8Гб ОЗУ но с 16+ слишком непрактично по скорости для ССД. Не говоря уже о других проблемах.
64 гб озу скидываются на диск за 5 секунд или около того. Это при условии, что они скидываются все.
Вы из тех, кто придерживается идеи: "При операциях достаточно продезинфицировать инструменты, руки мыть не нужно"? Поэтому вас не смущает, что кусок ram будет "на изначально, не извращённо разбитом куске одного hdd ручками" с неизвестным состоянием? Вам не zfs нужен, а /dev/random, пользуйтесь.
> Вы из тех, кто придерживается идеи: "При операциях достаточно продезинфицировать инструменты,
> руки мыть не нужно"? Поэтому вас не смущает, что кусок ram
> будет "на изначально, не извращённо разбитом куске одного hdd ручками" с
> неизвестным состоянием? Вам не zfs нужен, а /dev/random, пользуйтесь.Че за бред? Ты вообще в курсе что такое SWAP то? И как он работает? И что SWAP был задолго до ZFS?
как насчет того, что zfs рекомендует отдать диск целиком?
это рекомендация из solaris, как обычно, имеющая мало отношения к openzfs.
У тех-то своп работает.Вот что делать владельцам пулов с raid/mirror - действительно не вполне очевидно. Впрочем, своп в современных системах немодно, и проще его отключить совсем.
> это рекомендация из solaris, как обычно, имеющая мало отношения к openzfs.очень интересно. стало быть официальная документация по openzfs вот тут вот https://openzfs.github.io/openzfs-docs/Performance%20an... рассказывает все таки про соляру.
ну, так и есть - тычешь там в линк с _объяснениями_ (то на что у тебя ссылка - это бессмысленные мантры), попадаешь сюда:
https://openzfs.github.io/openzfs-docs/Performance%20an...
изумляешься - "папа, ты с кем сейчас разговаривал?!" - в смысле, зачем тебе это знание и что с ним теперь делать.Делаешь выводы о всем остальном содержимом этой свалки, разочарованно закрываешь окошко.
Оно там все такое. Мантры, давно утратившие смысл обрядовые танцы мертвым богам...
А на деле как никто не мог десять лет назад победить need_free(), так и посейчас #ifdef solaris...
Зато, вот, influx db. Именно эта фича была необходимейшей! (нет. именно такие фичи только и умеют запилить макаки, дорвавшиеся до права комитов. Впрочем, их менеджеры именно такого и ждут.)
Б-ть, ну куды бечь, я вас спрашиваю?!
> On Linux, the Linux IO elevator is largely redundant given that ZFS has its own IO elevator.причем последний включается, если отдавать диск, а не раздел
>А на деле как никто не мог десять лет назад победить need_free(), так и посейчас #ifdef solaris...
> Зато, вот, influx db. Именно эта фича была необходимейшей! (нет. именно такие фичи только и умеют запилить макаки, дорвавшиеся до права комитов. Впрочем, их менеджеры именно такого и ждут.)как написано прямым текстом в емнип репорте про гибернацию, они работают в интересах их ынтерпрайз клиентов
> причем последний включается, если отдавать диск, а не разделскорее всего это тоже бредни. Вот про бессмысленный битик в заголовке - это похоже на правду, у макак оно вот так всегда и выходит.
> как написано прямым текстом в емнип репорте про гибернацию, они работают в интересах их
> ынтерпрайз клиентоввряд ли. Это уровень подвальных клиентов, а не энтерпрайз. Ну, какова iX, таков и ентерпрайз-клиент, собственно.
"смотрите, смотрите - теперь графичек втрое красивше, показывает как еще сочнее и мжвячнее ваши байтики превращаются в невосстановимую кашу".Энтерпрайзные хранилки никаких графичков в формате заковыристой никому ненужной поделки (вместо line based или хотя бы модно-молодежного json если совсем с мозгами беда) не рисуют, у них вообще с гуем "все сложно" - дЭффективным менеджерам нахер не надо там ничего видеть, а инженеры работают через cli.
А тут именно подвальный побогаче заказал себе фичу для единственной поделки которую его рабы осилили запустить для метрик.
Что ради нее изуродован весь код сверху донизу без всяких попыток оценить накладные расходы и без умения в условную компиляцию - практически не сомневаюсь.
> как насчет того, что zfs рекомендует отдать диск целиком?А голову включить?
Это скорее особенность работы линукса с памятью... Чем проблема зфс.
Если хотите свап на зфс то нужно внимательно всё настроить.На линуксе похожие проблемы возникают при записи на флешку - система может повиснуть.
Подскажите как правильно, а то в рекомендациях OpenZFS есть инструкция и на следующей строчке "не работает, не используйте", судя по issue - никто до сих пор не смог "правильно" настроить.Из-за флешки система ни разу не висла, если это важно.
Ну с ходу, свапинес в 100 выставить.
А вытеснение кешей в 200(или 1), в зависимости от логики.
Сжатие свопа(забыл как оно называется) которое страницы памяти сжимает, отключить.
Кеши зфс настроить так, чтобы они не занимали больше трети ОЗУ. Впрочем 10% скорее. Как кеши записи так и чтения. Особенно записи конечно в данном случае.Ну и я не в курсе, но по идее вся запись на раздел со свапом должна быть синхронной.
И чексуммы отключить если свап не зеркальный.
SWAP на FreeBSD средствами ZFS:
zfs create -V 4G poolname/swap
zfs set org.freebsd:swap=on poolname/swap
zfs set compress=off poolname/swap
zfs set sync=disabled poolname/swap
zfs set dedup=off poolname/swap
zfs set primarycache=none poolname/swap
swapon /dev/zvol/poolname/swap
Аноньимъ и iZEN,
Понимаю, что вы хотите блеснуть рабочим решением, но для начала сами попробуйте прогнать stress-ng --vm 8 --vm-keep --vm-bytes 120% с вашими настройками. Никакой "свапинес", тем более 100 - не поможет, "sync=disabled" https://github.com/openzfs/zfs/issues/7734#issuecomment-7236... вообще из разряда вредных советов. Выше есть ссылка с обсуждением этой "признанной" проблемы с логами, никакой волшебной пилюли нет.
>вообще из разряда вредных советов. Выше есть ссылка с обсуждением этой "признанной" проблемы с логами, никакой волшебной пилюли нет.Если я ничего нее путаю, то, если не отключить синхронную запись, диск и ЗФС будет делать двойную работу, вначале писать в log на диске, а потом переписывать из него опять на диск уже в нормальном виде.
Поправьте меня если что.Разбираться в этих тестах неохота, фря у меня никогда не залипла со свопом на ЗФС, тестировал сборкой древа портов которая сожрала неприличный объём ОЗУ.
> Если я ничего нее путаю, то, если не отключить синхронную запись, диск
> и ЗФС будет делать двойную работу, вначале писать в log на
> диске, а потом переписывать из него опять на диск уже в
> нормальном виде.
> Поправьте меня если что.У CoW ФС log является самой файловой системой, вообще-то. Когда в него что-то пишется, он в это время является log'ом, когда записалось — уже частью пользовательских данных. Таким образом, ничто никуда повторно не переписывается, а просто местоположение меняет статус.
ЗФС работает не так, погуглите. ЛОГ у неё отдельный.
> ЗФС работает не так, погуглите. ЛОГ у неё отдельный.ZIL будет отдельным, если его специально обозначить для пула на отдельном носителе. Лучше, если это будет сверхбыстрое устройство долговременного хранения, но небольшой ёмкости.
Нет, ZIL присутствует в виде спец области на блочном устройстве - https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/
По Вашей же ссылки написано что ZIL не равно SLOG в плане хранилища.
То есть
ZIL - содержится на тех же дисках
SLOG - на отдельном быстром
Так я и не писал нигде что равно.
> ZIL будет отдельным, если его специально обозначить для пула на отдельном носителе.
> Лучше, если это будет сверхбыстрое устройство долговременного хранения, но небольшой ёмкости.Intel Optane?
> Intel Optane?Оптан хороший вариант, так как у него малые задержки. Важно чтобы накопитель не потерял данные при отключении питания.
Но люди и SAS диски юзали для такого...
Еще можно использовать обычный ССД с SLC кешированием, главное знать размер этого кеша и выделить область равную этому размеру.
Честные MLС диски то-же подходят в общем.
Я выше конечно наврал.
Из лога переписывать не будет. Будет писать из ОЗУ.
Но лог(zil) таки отдельная область на диске и данные будут записаны дважды.
В случае синхронной записи.Когда запрос не синхронный данные в лог не попадают вообще, и пишутся только в кеш ОЗУ.
А расскажите о проблемах зфс подробнее.
Насколько оно устойчиво при заполнении 99%?
Насколько легко потерять данные с вылетом одного диска если делать зеркалирование средствами зфс?
Как там с криптой?
> А расскажите о проблемах зфс подробнее.
> Насколько оно устойчиво при заполнении 99%?
> Насколько легко потерять данные с вылетом одного диска если делать зеркалирование средствами
> зфс?
> Как там с криптой?GMIRROR и GELI, но линуксоиды этой стройной системой обделены..
Хочешь ZFS ставь FreeBSD и не делай людям мозги
Хочешь ZFS ставь Ubuntu и не делай людям мозги
> Хочешь ZFS ставь FreeBSD и не делай людям мозгикакой смысл ставить мертвую систему чтобы получить тот же самый дельфиксовый zfs ?
Баги в котором не исправляют годами потому что "у нас нет ресурсов"(c)
ставь бубунточку, тебе анон все правильно посоветовал. Или забей и ставь дисяточку. Там нормальные storage spaces, с нормальной refs, правда, павершел придется выучить - полноценный гуй обещали только в 11.
>> Хочешь ZFS ставь FreeBSD и не делай людям мозги
> какой смысл ставить мертвую систему чтобы получить тот же самый дельфиксовый zfs
> ?
> Баги в котором не исправляют годами потому что "у нас нет ресурсов"(c)
> ставь бубунточку, тебе анон все правильно посоветовал. Или забей и ставь дисяточку.
> Там нормальные storage spaces, с нормальной refs, правда, павершел придется выучить
> - полноценный гуй обещали только в 11.storage spaces это вообще корявая поделка в попытке догнать enterprise FS. Чего стоит только то что для кэширования ты можешь использовать ТОЛЬКО четное количество дисков если в зеркале диски стоят.
> На линуксе похожие проблемы возникают при записи на флешку - система может повиснуть.С отдельным kthread? Повиснуть? Ты наверное не видел линукса после 2.6.38.
Просто я, на своей бубунтячке 20.04 часто использую медленные старые флешки, процесс копирования на которые подвисает на уровне kthread по причине чрезмерного заполнения кэшей, но сама система - так же отзывчива.
Строго говря - 12309 вывели в отдельный поток.
Приложение все равно же может повиснуть, которое копирует?
И потом если попытаться в момент этого затыка открыть диск в файловом менеджере.
или если браузер или любая другая программа запомнили его где-то и при запуске или открытии окна сохранения файла решили пропинговать.И с сетевыми дисками у меня проблемы похожего характера.
> Приложение все равно же может повиснуть, которое копирует?
> И потом если попытаться в момент этого затыка открыть диск в файловом
> менеджере.
> или если браузер или любая другая программа запомнили его где-то и при
> запуске или открытии окна сохранения файла решили пропинговать.
> И с сетевыми дисками у меня проблемы похожего характера.FreeBSD - нет, не может..
>Ты наверное не видел линукса после 2.6.38Старые линуксы у меняя вываливались в кернел паник частенько, впрочем кноппикс пробовал основательно, и никаких проблем не было с ним от слова совсем.
Никаких залипаний и прочего.
Причем работал он с сиди диска.
СД диска, Карл.
И с флешки отлично работал.Работал отлично и без проблем и боли, я прям прослезился, что с линуксом стало? Зачем убили десктопный линукс?
У меня всегда свежее ядро.
Недавно система начала виснуть, когда копировал на флешку гигабайты.
Жалкой ноунейм юсб 2.0 флешке система выдаёт первую космическую скорость, а потом система висит, пока файл не перенесётся полностью самом деле.
Решается подключением флешки с синхронизацией, где показывает честные несколько сотен кб в сек.
Кто лично работал, как данные на ZFS после сбоев питания? После аппаратного reset?
>Кто лично работал, как данные на ZFS после сбоев питания? После аппаратного reset?Не знаю.
На Солярке никаких проблем с этим нет, на других системах не пользовал
За десяток лет эксплуатации в продакшене (пяток серверов хранения данных с разными конфигурациями zraid) данные потерял только один раз. Но там грохнулась сама железка.
Все норм. Можно включить sync и тогда данные без кеша сразу записываются
ZFS транзакционная.. что записала то записала .. полфайла не сохранит
Стоит FreeNAS на домашней файлопомойке. Без UPS-a. За пять лет использования электричество рубилось сто раз. На железяку постоянно пишется поток с камеры наблюдения. Год назад начали сыпаться bad-сектора на одном из дисков. Весной этого года диск сдох. RaidZ из 4 дисков по 2Тб, 8 гигов обычной, не ECC оперативки. Поменял диск, перестроил массив. Никаких проблем. Потом решил до кучи проверить остальные три диска. В SMART - ошибки, тоже подсыпаться начали. Заменил и их, не отключая сервак. Ничего из того что лежало не пропало. Прогнал CRC по лежащим на серваке фотками и видосам. Сравнил с архивами на бэкапе, один в один. Простите хейтеры ZFS, я старался поломать, но видимо я что-то делал не так.
> Стоит FreeNAS на домашней файлопомойке. Без UPS-a. За пять лет использования электричествоСпасибо, внушает.
> В SMART - ошибки, тоже подсыпаться начали. Заменил и их, не отключая сервак.pending sectors?
Зачем, если есть ext4, jfs, xfs, btrfs, reiserfs, encfs, ntfs, fat, etc
Зоопарк
и возможность выбора для соответствующей цели.
Этим линукс и отличается от бздешечки, в которой - или выделите побольше ОЗУ для ЗФС и протюнингуйте её немного, или бойтесь потерь данных на UFS.
> или бойтесь потерь данных на UFS.... и красной руки с черной простыней!
как что-то плохое
Зачем зачем, если есть fuse.
FUSE как раз таки яркий пример микроядерности в моноядре, жаль что только для ФС
> InfluxDB предложена команда "zpool influxdb".Перед написанием новости полезно прочитать документацию.
Нет такой команды "zpool influxdb", а есть "zpool_influxdb"! Исправьте текст новости.
NAME
zpool_influxdb — collect ZFS pool statistics in InfluxDB line protocol formatSYNOPSIS
zpool_influxdb [-e|--execd] [-n|--no-histogram] [-s|--sum-histogram-buckets] [-t|--tags key=value[,key=value]…] [pool]
Вообще не понятно кто инфлюксом пользуется оно же кривое все . . . Для староверов есть графит, для хипстеров пром. Скорееивсего это хотелка какого то спонсора
Ну вот, только "influxdb" в драйвере файловой системы нам, для полного щастия, конечно же, и не хватало. Ах, да, и "ускоренной загрузки модуля ведра", конечно же.Херачь молнией, Г-ди, тут уже ничего не исправить!
Лог как лог. Вам лишь бы бзднуть не разобравшись
Прочитав специалистов с "опеннета", очередой раз убедился что лучше ext4 и ntfs ничего нет и в ближайшие годы не предвидится.
А ExFAT ?
В венде поганой все хорошо, товарищ зампоплит.
А в линoops - китайцы ж делали, под присмотром корейского надзирателя. С соответствующими качеством и эффективностью. Немного подробностей про как они там половину спека проигнорировали и где рыбу в него заворачивали, озвучил в свое время Парагон, но это ж был кого надо код, платиновый спонсор, не хер собачий, поэтому никакого парагона слушать, конечно же, никто не стал.Так что пользуйтесь ntfs3g, ее нормальный грек делал. э... ну в смысле, он руководил, как вы. Делал русский, единственный из трех участников, чье имя начисто исчезло из копирайтов и из истории. Впрочем, видели его потом в городах, довольно таки отдаленных, так что он, полагаю, не бедствует.
чем оно лучше ext4?
Чем ext4
Как раз именно тем, что нужно изучать, не просто держать нос по ветру популярности, ничего не понимая.
А расскажите, пожалуйста, чем история с мамр и их быстрой смертью закончилась? Нашли решение или всё так же нужно тщательно искать чтобы и без мамр, и ёмкость вменяемая?
Близко ZFS да не укусишь))) так ведь пингвины?
C 2013 года на ЗФС, с 2015 - в проде. И на пингвине. А шо не так?
Пару команд для установки - осилил. Тюнинг под базы и под файло - тоже. Багу з залипшими локами - репортил.
Обожаю сказочки)))
ну и попроси мамочку, чтобы поменяла подгузник, уложила в кроватку и сказочки почитала.А у людей всё нормально крутится. У меня вот тоже несколько лет как на домашних компах плюс на одном из kvm гипервизоров
Домашние компы, KVM гипервизор, что то крутится...хммм что же это?
Не уж то локалхост виртуализировал?
уровень дискуссии - опеннет
да, 20 лет назад было приятнее
Интересно проект развивается.
В самом начале пилили как свободный, независящий от Sun/Oracle вариант ZFS для BSD. Когда саноракл дал свою реализацию для BSD — не забросили, а стали пилить по остальные POSIX и Posix-like , в процессе оформившись как ZFSonLinux. Когда реализация саноракла в BSD начала стагнировать — древний неподдерживаемый код с вкраплениями заплаток от тех, кто ничего твёрже джавы в руках не делал — снова стали OpenZFS и победно вернулись обратно на BSD в ещё более годном состоянии, чем когда-либо.Отличная, красивая история настоящего open source полёта, который показал как надо.
интерес ваши бредни представляют собой разьве что для психиатра.
На фряхе оно работает лучше, чем на ляликсе?
Работало, да. Никакого "influxdb" во всяком случае не пихали в код _файловой_с-ка_системы_, где ему совершенно не место.В силу отсутствия некоторых линoopsовых родовых травм - работало местами и неплохо. Там свои были, но их можно было исправить и даже - исправляли. Пропихнуть через вот этих вот - "мы удовлетворяем своих ентерпрайс клиентов и ваши исправления не исправления" было невозможно, но кто хотел - мог в частном порядке пользоваться.
А потом менеджеры этих подвальных велели не выделываться, потому что "клиенты хочуть доскер!" и те быстренько слили свой проект с ZoL, который уже настолько горбат, что его только могила может исправить.
Вот читаешь доки по ZFS, вроде бы дико крутая файловая система, а на деле тормозной кусок говна, пожирающий дисковое пространство и раму.
По крайней мере на ляликсе. Как там на фряхе и соляре не знаю, может и хорошо всё.
Беня, такое впечатление, что вы не читаете доки, а только кокс через них нюхаете.
Ты сам-то пробовал использовать это поделие на чём-либо отличном от подкроватного NASа?
да пользуйтесь чем хотите.. зачем только в тему лезете со своим ненужным мнением ?что ни тема про freebsd или zfs то набегает куча линуксойдов и начинают чморить за ненужно...
как itгопники...
Я использую FreeBSD, но без тормозной ZFS.
да пилите свои велосипеды как хотите ... в целом всем ср*ть что там у вас
Ну и пошёл ты йухан в таком случае.
да понятно с вами все руки из *опы да еще и грубиян
Боевые пингвины только в темах о фряхе и щас)
Так вот почему в САСШ этой зимой энергетика медным таком накрылась, в домах трубы начали лопаться - ZFS подвела; не "зелёная" ведь энергетика, которая уровня бохх, на которую они молятся сейчас.
А скоро на rust перепишут?
> А скоро на rust перепишут?опять неправильно, да сколько ж можно вас обучать грамматике?!
Скоро на хруст НАЧНУТ переписывать!(это утверждение, если непонятно. Возможно даже уже начинают где-то.)
Ужас! ZFS! Rust! А что дальше?!
А дальше анальный зонд с телеметрией!
Все эти псевдо Open чтобы нагнуть пингвина! Не ведитесь на это!!!
Всё идёт по пути Chromium!
Сначала нагнут сделают OpenФигню - нагибают раком!
Ждут пока наберётся процент рынка - тем временем раздвигая булки!
А потом сделают vendor-lock - и наконец-то имеют во все щели!Выводы уже сделаны, если вы нагнулись раком, то рано или поздно вам вставят!
Ждем когда ты наконец напишешь свой первый "Hello world!", чтобы сразу его присвоить!
Linux BDSM какой-то!
Комментарии похожи на вопли сумасшедших не умеющих даже хоум папку перенести с одного диска на другой но лезущих писать про zfs
По себе судить не надо.