https://elis.nu/blog/2021/05/the-day-when-zfs-saved-my-data/

Господа, день добрый. Подскажите пожалуйста, есть ли способ решения проблемы, гугл ничего толкового не предлагает. Есть файловые шары с огромным количеством очень длинных кириличных путей, ну т.е. папка в папке, это всё в папке и так десяток раз, а в конце ещё и файл с именем в сотню символов. Файлов таких масса, при попытке перегнать их "как есть" с виндовой шары - сыплются ошибки, мол аксесс денай. Прогуглив обнаружил, что где-то на уровне файловой системы есть ограничение в 255 бит на длину пути. Эту проблему можно как-то обойти, кроме вариантов "удалить файлы\переложить их в более короткие пути и т.п.". ZFS весьма гибкая, неужели эту проблему никак не обойти?

Заархивировать, скопировать и распаковать например.

На сколько помню виндовая тулза есть, которая заодно и права сохранит, но не помню как звать. А вообще последний 64 битный Тотал норм жуёт

Господа, день добрый. Подскажите пожалуйста, есть ли способ решения проблемы, гугл ничего толкового не предлагает. Есть файловые шары с огромным количеством очень длинных кириличных путей, ну т.е. папка в папке, это всё в папке и так десяток раз, а в конце ещё и файл с именем в сотню символов. Файлов таких масса, при попытке перегнать их "как есть" с виндовой шары - сыплются ошибки, мол аксесс денай. Прогуглив обнаружил, что где-то на уровне файловой системы есть ограничение в 255 бит на длину пути. Эту проблему можно как-то обойти, кроме вариантов "удалить файлы\переложить их в более короткие пути и т.п.". ZFS весьма гибкая, неужели эту проблему никак не обойти?

Не слушай. Лимит длины имени на винде 255 символов, а на линуксе 255 байт

Не проще ли перенаправить рабочие столы и мои документы на сервер?

С бекапами все просто: есть цикличечкие снапшоиы каждые 15 минут, хранение сутки. Есть вим, в другой дц, есть rsync файлов в третий дц, тоже на zfs. Все длинные имена, скриптом режутся, ещё никто не жаловался

Мы ушли от снапшотов zfs

коллеги, кому нужны винты на CMR , вот нашел оф доку от Тошибы https://www.toshiba-storage.com/ru/products/toshiba-internal-hard-drives-p300/?pdf

https://github.com/openzfs/zfs/issues/2344 каждый может проверить у себя. проблема все еще имеет место быть.

Я обнаружил проблему во время передачи инкрементных снимков зашифрованных томов. Если после репликации на удаленную систему, выполнить наследование ключа (zfs change-key -i) для целевого датасета, то следующий инкрементный снимок сломает том. Ключи везде один и тот же! zfs 2.0.4 Вот шаги для воспроизведения https://docs.google.com/document/d/1rKAZa7lldMHe3hjdK1Rv3pc_Xj4ZgtQnr3718z49ljQ/edit#heading=h.n4ec21qgxfky

длина файлнеймов точно проблема не конкретной ФС, а всего линукса. у меня вон торренты не качаются некоорые изза этого. что на XFS не качались, что на BTRFS. ZFS на торренты еще не пробовал :)))

С датасетами та же проблема.

на зфс торренты тоже не пробовал, а вот на ntfs который на zfs качаю. это жопа

нужно подтюнить размер блока в zvol

хоть бы тиринг сделали :(

если я правильно понял roadmap, то он планируется в обозримом будущем.

в какой версии зфс? линуксовой?

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

не помню почему я сделал вывод что это могут реализовать в openzfs )

считай полдела

[не смотерл видео] это не то же самое что sync=disabled?

[не смотерл видео] это не то же самое что sync=disabled?

там больше похоже на sync=always + SLOG на SSD

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

ну всяко лучше чем езда бошек туда-сюда по 1 разделу :)

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

ну это да. с другой стороны, БД и сами неплохо справляются с атомарностью, особенно если им ФС поможет (например nodatacow в btrfs)

https://www.opennet.ru/opennews/art.shtml?num=55201 линкрелейтед

интересный критерий