Замедление в этом месте никто не заметит. При работе нода читает и пишет файлы на скорости около 5-10мбит, это ни о чем вообще. А вот ускорение после перезапуска, когда надо пробежаться по миллионам файлов и на это уходят сутки нуждается в любой помощи.
Это все равно шило на мыло: что проверять десять файлов, что десять кусочков внутри одного файла. Вы фактически вставляете маленькую файловую систему в каждый большой кусок и перемещаете проблему с больной головы на здоровую. Другими словами переименовыванием понятий проблему не решить.
Если у вас энумерация фалов медленно работает — эту проблему надо решать либо настройками текущей файловой системы, либо использованием более подходящей, а не изобретением новой.
Задача доступа к миллиарду файлов уже решена в различных файловых системах, заставлять сторж изобретать еще одну не имеет никакого смысла.
Я могу посоветовать zfs, ARC/L2ARC для ускорения многократного доступа, или special vdev для однократного/редкого. Персонально я вообще не замечаю что filewalker что-то делает. О его существовании я узнал из этого форума.
1 Like
Ну эта операция тоже станет медленной: вам надо распаковать архив на диск, проверить файлы, перейти к следующему. Намного больше i/o, чем просто линейно пройтись по всем файлам.
Я тоже не знал о его существовании, у меня один узел Windows native, 2 docker for Windows, один Raspberry pi 3b+ (ext4) с USB диском. Правда, никаких RAID.
Не надо ничего на диск распаковывать или внутри архива беспорядочно бродить, что за странные мысли. Если прямо так хочется иметь дело с файлами то их можно распаковать в оперативную память, в объекты иммитирующие файлы.
Зачем? Сегодня уже все уже и так в оперативной памяти. Вся метадата уже в оперативной памяти, либо сразу, либо постепенно там оказывается по мере чтения.
Наоборот, если объекты не отдельные файлы а запакованы куда-то — то все будет значительно медленнее, потому что метаданных будет недостаточно, нужно будет сами данные с диска читать и копаться внутри. Это долго.
Очевидно же, если нужно определить наличие и размер пяти кусков на диске, быстрее будет если эти куски в отдельных файлах, потому что файловые системы делают это очень быстро, это самый оптимизированный сценарий. Потому, собственно, все файловые системы держат метадату в отдельной куче, а не вперемежку с файлами, как вы предлагаете. Все считывается в память очень быстро и потом задержки минимальные. Некоторые файловые системы позволяют держать всю метадату на отдельных носителях, скажем nvme SSD, и все операции, кроме чтения и записи самых данных, происходят мгновенно.
Имитировать файловую систему внутри другой файловой системы, потому, контрпродуктивно — это убивает все эти оптимизации.
Крайняя степень этого будет — все держать в одном огромном файле и копаться внутри. Разумеется, все оптимизации файловых систем идут в форточку и сторжу придутся изобретать что свое, что по сути будет просто еще одной проприетарной, очень плохой, файловой системой.
1 Like
А что вообще делает filewalker? Если просто смотрит на наличие и размер файла то “архив” состоящий из кучи мелких склееных файлов отлично решит проблему. Вместо того чтоб проверять наличие 1000 файлов и 1000 размеров ему надо будет проверить всего 1.
Если считает хеш суммы всех файлов то тоже самое, прочитать один архив вместо 1000 файлов получится заметно быстрее.
По моему, он проверят только метадату. (Я почти уверен).
Но в как бы то ни было — последовательный скан — это не тот юзкейс, под который надо оптимизировать. Это очень низкоприоритетная, и, к тому же крайне редкая, задача. Что надо оптимизировать — это случайное чтение нескольких, из миллионов маленьких, <4к файлов, раскиданных по терабайтовому полю. Современные файловые системы с этим справляются отлично: добавлением еще одного уровня абстракции можно только все замедлить, (метадата уже в кеше а файлы нет; лезть внутрь файла чтоб выковырять кусочки просто добавит лишнее IO) но ни как не ускорить: если бы был способ это ускорить хитрыми структурами данных — это было бы уже сделано, в рамках существующей программы, под названием «файловая система» 
Edit (расставил кучу запятых…)
Люди которые жалуются на скорость filewalker на самом деле не видят леса за деревьями: медленный файлвокер это не причина, а симптом. Симптом того, что метадата не помещается в свободную память. А это значит, что время до первого байта включает в себя десятки миллисекунд задержки чтения жесткого диска каждый раз клиент запрашиват файл, и в результате увеличенная вероятность проиграть гонку за первые 29 кусочков другой ноде, которая закешировала метадату (где лежат все куски) в рам и начинает посылать нужный кусочек со значительно меньшей задержкой.
Вот буквально недавно то же самое обсуждалось: How do I empty the trash? - #20 by arrogantrabbit
1 Like
Если только метадату тогда какие проблемы вообще, меньше файлов - быстрее проверит. А оптимизировать надо обязательно, 10+ часов дрочева дисков после перезагрузки это большая проблема.
Перезагрузка нужна при обновлении, регулярно.
При чем тут память вообще? После перезапуска кеш чист, не важно сколько есть памяти если она пустая.
Проход по всем файлам никак не зависит от памяти если по ним до этого никто не ходил. Даже если памяти под кеш достаточно то его пока все равно нет.
У меня это занимает 4 минуты, около 10TB нода. Почему? Много памяти для Кеша. Если на вашем устройстве это занимает 10 часов — оптимизировать надо ваше устройство, а не сторж.
Перезагрузка ноды никак не влияет на дисковый кеш. Второй и последующие запуски будут еще быстрее.
Почитайте про metadata prefetch. Файловая система читает блоками, и при чтении одного файла метадата кешируется для всего блока, даже если ничего не делать. А если делать — то можно предсказать, что будет нужно дальше, и закешировать дополнительные блоки заблаговременно. Поэтому да, больше памяти (больше чем размер метадаты суммарный) — быстрее скан, даже на холодный старт, потому что чем дальше в лес — тем больше кеш хитов.
Уже все максимально до упора оптимизировано: каждый кусок уже в отдельном файле лежит, в файловой системе. Файловые системы оптимизируют доступ к файлам лучше всех, если им не мешать: это их одна из немногих, насмерть отполированных, задач.
Я думаю @theurs про холодный старт, после перезагрузки ПК. Что говорит об использовании Windows, где файловую систему нужно обслуживать, как минимум проводить дефрагментацию (по умолчанию она делается, и лучше так и оставить).
Однако в Windows память тоже используется для кэша, может и не так эффективно, как в Linux (или вообще отключено, если диск расшарен по SMB/CIFS), но - помогает.
Так что желательно перезагружать ПК реже, памяти иметь больше, проводить дефрагментацию и не шарить диск по SMB/CIFS/NFS.
a mnogo pamjati eto skolko, esli ne sekret?
Много по меркам 2012 года, на сегонящний день не очень: это старый supermicro сервер x9 серии. 32GB ram, из которых 11ГБ используется всякими сервисами, остается 20ГБ на кеш.
К сожалению, на этот сервер бекапится несколько маков по SMB, и самба практически полностью вытесняет файловый кеш своими буферами несколько раз в день. Но, несмотря на это, наличие свободной памяти когда нужно, полностью убирает все проблемы с производительностью, несмотря на периодическое вытеснение Кеша. ARC hit rate практически никогда не спускается ниже 95%, в среднем болтается около 99%.
A kakaja OS windows server?
Это не виндоус, это FreeBSD 13.1
ot windows 10 takogo upravlenija pamjatju ne dozdjshsja, u menja na vseh serveras 24-32 gb ram, i filewolker rabotaet chasami, nemnogo spasaet tolko primocashe+512gb NVME
я помню вначале я пытался сделать из windows pc (Win 10 Pro) сервер для Time Machine – просто потому что он и так был все время включен, и куча свободных SATA портов на мазерборде – прямой смысл. Тем не менее даже в этом (двух разных) сценариях все тормозило просто ужасно.
Primo Cache помогал немного, но не сильно. Я еще пробовал tiered storage – Enmotus FuzeDrive, (AMD его продавала как StoreMI со своими мазербордами).
Я подозреваю что там есть какие то хитрые настройки в виндоус чтобы дать приоритет файловой системе и сервисам, потому что явно такие тормоза неспроста. Может в северных версиях они включены по умолчанию, или вообще не поддерживаются в workstation лицензии. Чем искать, разбираться, и сражаться с ветряными мельницами я перешел на FreeBSD и внезапно – все само сразу быстро работает. Так что у меня нет решения как заставить виндоус работать как надо…
Со всем уважением, но какое это имеет отношение к теме топика?