нужен быстрый листинг файлов, в зфс это делается отдельным meta device'ом

нужен быстрый листинг файлов, в зфс это делается отдельным meta device'ом

листинг листингу рознь. Список имен файлов , без меты, например работает быстро практически в дефолтной установке в xfs. Типа ls -f /dir/

листинг листингу рознь. Список имен файлов , без меты, например работает быстро практически в дефолтной установке в xfs. Типа ls -f /dir/

я проверю, спасибо. возможно так оно и есть

я проверю, спасибо. возможно так оно и есть

Зависит от ОСь немного тоже. У вас linux?

Зависит от ОСь немного тоже. У вас linux?

да, Линукс, я обычно работаю с дебиан, но не критично

разные реалзиации io: в linux можно поиграть с настройками VFS, io sched, покрутить dentry cache'ы

Насколько знаю, до 1Гб

в 64битах 2

Друзья, приветствую вас. Я очень ценю скорость, с которой можно получить список файлов в директории при использовании конфигурации ZFS + мета-устройства на отдельном SSD-диске. Из-за политических причин мне необходимо найти альтернативу таковым возможностям ZFS. Пожалуйста, помогите мне рекомендацией: существует ли что-то сопоставимое по скорости (в частности, при получении списка файлов) на других файловых системах? Мое глубокое признание и благодарность будут распространяться настолько, насколько дозволяет разум, без каких-либо излишеств или ограничений, разумеется.

Может ext4 с отдельным журналом на ссд? Но чем это политически отличается от зфс😁

Может ext4 с отдельным журналом на ссд? Но чем это политически отличается от зфс😁

буквой "z" :D

буквой "z" :D

вам смешно, а я каждый раз плююсь =)

Может ext4 с отдельным журналом на ссд? Но чем это политически отличается от зфс😁

журнал-то на скорость подгрузки меты каким боком? тут скорее надо курить в сторону кэширования, я даже как-то подозреваю, что скорость там давал не zfs как таковой , а просто кэш VFS. Прогрев может быть небыстрым, но если памяти побольше , да поиграть с настройками штатного кэширования - можно выжать хорошую скорость. Хотя задача странная сама по себе. Создать себе трудность и потом героически её преодолевать =)

Можно дежать мету в бд и быстро её оттуда брать)

Можно дежать мету в бд и быстро её оттуда брать)

как пример, есть всякие варианты. Но нужно понимать задачу в целом, а попросили просто альтернативу фс. Но 100-200тыс для xfs не проблема

Может ext4 с отдельным журналом на ссд? Но чем это политически отличается от зфс😁

журнал ничего не даст с точки зрения листинга миллионов файлов.

Может ext4 с отдельным журналом на ссд? Но чем это политически отличается от зфс😁

Мне тоже интересно как мета после записи связана с журналом

Если причины политические - BTRFS, BCACHEFS, XFS

А есть еще F2FS - кто юзал?

А есть еще F2FS - кто юзал?

Эффективно все, ибо Android))) Но надо смотреть по производителям, некоторые всё также ext4 используют

Эффективно все, ибо Android))) Но надо смотреть по производителям, некоторые всё также ext4 используют

в смысле, почему андроид значит эффективно?

в смысле, почему андроид значит эффективно?

Эффективно все

Разговорное выражение есть такое

эм. оок.

Окей, перефразирую, чтобы было понятней Почти все (эффективно можно округлить до 100% инженеров) использовали F2FS, так как многие пользовались Android

Можно дежать мету в бд и быстро её оттуда брать)

Чем её там держать?

Чем её там держать?

Как по мне - странное предложение. Не думаю, что БД будет быстрее ФС с этим справляться

Как по мне - странное предложение. Не думаю, что БД будет быстрее ФС с этим справляться

Согласен, но всё же чем :)

zstd весь стрим сожмет так же как и если его в файл засунуть. в пределах окна которое явно больше размера блока и кот. можно до 2 гигов сделать

Если бы можно было окно увеличить до 1Тб, то сжало бы точно лучше, чем с окном 2Гб. Но с таким размером окна будет выигрыш только в случае, если значительно больше совпадений на данной дистанции. А это уже очень специфический кейс, как мне кажется. Я до сих пор знаю только один - архивирование большого количества логов. У Вас есть ещё примеры кейсов? Кстати, вот пример сжатия логов c разным размером окна (20=1М, 27=128М, 31=2G): root@pc:/ext# du -h *ZSTD*/* 6,0G noZSTD/httpd.tar 287M noZSTD/httpd.tar.zst20 269M noZSTD/httpd.tar.zst27 267M noZSTD/httpd.tar.zst31 319M ZSTD1M/httpd.tar 530M ZSTD/httpd.tar

Как по мне - странное предложение. Не думаю, что БД будет быстрее ФС с этим справляться

смотря какая бд, смотря какие запросы. С бд вылезут другие сложности - синхронизация. Но я говорю, без описания всей задачи гадать можно в огромных диапазонах идей =) если там банально 1 дир с лямом файлов, то просто его кэшируем vfs и там хоть ntfs под низом - плевать

смотря какая бд, смотря какие запросы. С бд вылезут другие сложности - синхронизация. Но я говорю, без описания всей задачи гадать можно в огромных диапазонах идей =) если там банально 1 дир с лямом файлов, то просто его кэшируем vfs и там хоть ntfs под низом - плевать

Там банально несколько тысяч папок с сотней мильенов файлов

Сотен мильенов несколько

ну если несколько тысяч и в каждой мильон, то это другой разговор. Изначально был миллион в одной дире :)

ну если несколько тысяч и в каждой мильон, то это другой разговор. Изначально был миллион в одной дире :)

Я для примера

Там банально несколько тысяч папок с сотней мильенов файлов

Если ZFS в этом проверена и справляется, то не стоит крутить носом и воспользоваться ей)

собрал тестовую XFS с логдевайсом на nvme , сгенерил 700к+ файлов, : ]# df -i /mnt/test2 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 61527168 715448 60811720 2% /mnt/test2 # sudo sync; echo 3 > /proc/sys/vm/drop_caches # time ls /mnt/test2 >/dev/null real 0m1.278s user 0m1.016s sys 0m0.134s

не мгновенно, но вроде нормально

Дописывай в резюме скилл - быстро собрать стенд "на коленке" и протестить идею

ну там такая коленка, ляма 2 стоит =) просто есть под рукой , 5 команд дать не сложно

не мгновенно, но вроде нормально

А с 7 млн?

не мгновенно, но вроде нормально

ls | wc -l plz

В тест2

Потому как кое чего что-то не совсем сходится

$ ls /mnt/test2 |wc -l 793683

имена рандомные, размер 10k

$ ls /mnt/test2 | head 000hOWWVTIsPHphpno5D2aZs0 000nD9eEpqBURfb9U6w 001BjuJ1Re93u49ooBsxcjIZ 001CY2Pr33OSYlX

я чот думал будет медленее . хотя кэш сбрасываю, но дай-ка ребутну для верности

700к - это мало.

та не, та же секунда

700к - это мало.

ёлки, ну никто не собирался воспроизводить то окружение

1с на 800к, ну на 1М будет +- столько же

меня волновали порядки, я получил что хотел

/report

/report

кто-то знает? - если данные (мелкие файлы) лежат на спешл-вдев... они дублируются в l2arc если к ним частый доступ (но они же и так на быстром диске)

кто-то знает? - если данные (мелкие файлы) лежат на спешл-вдев... они дублируются в l2arc если к ним частый доступ (но они же и так на быстром диске)

L2arc - это то, что вытеснилось из ARC, а не то, что на медленном диске было

L2arc - это то, что вытеснилось из ARC, а не то, что на медленном диске было

..... Алгоритм L2ARC немного сложнее этого. Самую малость

Если хочется почитать "In short, the L2ARC is continually fed with blocks that are near eviction from ARC."

кто-то знает? - если данные (мелкие файлы) лежат на спешл-вдев... они дублируются в l2arc если к ним частый доступ (но они же и так на быстром диске)

На Special не лежат данные, на нём лежит мета про расположение файлов

На Special не лежат данные, на нём лежит мета про расположение файлов

дык лежат жеж всё что меньше или равно смолблоксайзу, по дефолту 128к

дык лежат жеж всё что меньше или равно смолблоксайзу, по дефолту 128к

Вы с ZIL не путаете?

Вы с ZIL не путаете?

не

не

Что-то не припоминаю, чтобы vdev special по умолчанию использовался для малых блоков

Что-то не припоминаю, чтобы vdev special по умолчанию использовался для малых блоков

да, про "по дефолту" я обосрался =)

да, про "по дефолту" я обосрался =)

Я поэтому отдельно отметил это слово)

..... Алгоритм L2ARC немного сложнее этого. Самую малость

Я намеренно упростил. Но по факту ведь l2arc всё равно мелкие блоки закешит, верно?

Я намеренно упростил. Но по факту ведь l2arc всё равно мелкие блоки закешит, верно?

Если они были в ARC, а вот попадут ли они в ARC надо выяснять, вроде как да but don't quote me on this

Я намеренно упростил. Но по факту ведь l2arc всё равно мелкие блоки закешит, верно?

Кэшиь все по умолчанию, не кэшит стрим по умолчанию :)) из arc

Кэшиь все по умолчанию, не кэшит стрим по умолчанию :)) из arc

Стрим? Что имеется ввиду?

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

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

нет

нет

Окей, а если это будет отдельный датасет, то при его загрузке всёравно будет вычитываться хэшмап и держаться в памяти всегда?

нет

М? Дедуп же можно выключить после? Он всё ещё будет для текущих файлов держать в памяти таблицу дедупа, но новые файлы это ведь не затронет?

М? Дедуп же можно выключить после? Он всё ещё будет для текущих файлов держать в памяти таблицу дедупа, но новые файлы это ведь не затронет?

ну как бы выключил, но облегчения от этого не будет 😃

Хочется воспользоваться чем-то наподобии duperemove для btrfs но делать это на лету и для ZFS :)

можно симлинков/хардлинков сделать через fdupes и тому подобный софт ищущий дубликаты

ну как бы выключил, но облегчения от этого не будет 😃

А если дедуплицированный датасет перелить через zfs send/recieve тоже не сработает? 🙂

Хочется воспользоваться чем-то наподобии duperemove для btrfs но делать это на лету и для ZFS :)

Если Вы ищите дедупа по файлам, то да, скорее hardlink))))))

А если дедуплицированный датасет перелить через zfs send/recieve тоже не сработает? 🙂

Ну, сперва он раздедуплицируется насколько мне известно

Стрим? Что имеется ввиду?

Потоковое чтение , префетч

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

Это точно квапс?