# Нода 5 лет+ (Node Age 65 Months) 7.28ТБ хранение, 70 млн файлов. Прогулка или что-то пошло не так **URL:** \ **Category:** Node Operators\ **Created:** [November 28, 2024, 9:15pm UTC](https://forum.storj.io/t/5-node-age-65-months-7-28-70/28679 "2024-11-28T21:15:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![AiS1972](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ais1972/32/60_2.png) [@AiS1972](https://forum.storj.io/u/AiS1972)\ **Post date:** [November 28, 2024, 9:15pm UTC](https://forum.storj.io/t/5-node-age-65-months-7-28-70/28679/1 "2024-11-28T21:15:54Z")
![изображение](https://storj-s3.bcdn.literatehosting.net/original/3X/2/c/2c0fc1e12c3ded015ad873d85dbbf51ffa4ae057.png) На скрине запечатлен процесс прогулки по ноде 7.28ТБ на ssd 16ТБ. Вводная диспозиция : имеется нода, которая существует с момента старта сторжа версии 3. ![изображение](https://storj-s3.bcdn.literatehosting.net/original/3X/7/c/7ce84ec810860de9aab178e689800865efdfb09d.jpeg) Жила она всё это время на hdd сигейте 16ТБ ST16000NM001G. Я решил сделать дефрагментацию и заодно прогулку. Для этого я сделал зеркало на 16ТБ ssd micron 9300 про. Затем отломил зеркало на hdd и получил ноду на ssd , которая затем будет пофайлово копироваться на hdd - это не долго , примерно сутки. Но сейчас не об этом, а о запущеном перед переносом прогульщике с отключенным ленивым прогульщиком. Так вот… Наш любимый прогульщик, как по мне, стоит признать мертвой технологией, по той простой причине, что нода даже будучи запущена на хайэнд оборудовании выполняет прогулку уже более получаса, безусловно процесс немного замедлил идущий также перенос в корзину, но это не так принципиально. Даже в случае с параллельной работой переноса в корзину, это все очень долго. Что говорит о том, что на диске, фрагментированном за годы работы ноды на этом диске, этот процесс с практической точки зрения является бесконечным. Да есть всякие там костыли, типа zfs с метой на ssd… Но я не преемлю дополнительную точку отказа на пустом месте, не говоря за повышение стоимости, что при нынешней доходности невозможно. Костыль в виде барсучьего кеша также меня совсем не впечатлил. Разговоры о “ни чего не покупайте для сторжа” так же не забываем… Так ведь ? НО! В общем случае, по моему мнению, это плохое решение, которое требует замены. ![изображение](https://storj-s3.bcdn.literatehosting.net/original/3X/5/e/5e2a169234dcd4bf7a54ed4515ad360177d61f0a.png) Ну и собственно сама нода. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [November 29, 2024, 3:29am UTC](https://forum.storj.io/t/5-node-age-65-months-7-28-70/28679/2 "2024-11-29T03:29:44Z")
Если вы используете диск целиком для узла, то вы можете включить фичу dedicated disk: > [@The whole disk/partition allocation feature](https://forum.storj.io/t/the-whole-disk-partition-allocation-feature/28192/4): > > To config.yaml the following: storage2.monitor.dedicated-disk: true storage2.monitor.ReservedBytes: 100 GB storage2.piece-scan-on-startup: false Edit: Both storage2.monitor.ReservedBytes and storage2.monitor.reserved-bytes do work the same it looks like, but to keep the usual format we should use storage2.monitor.reserved-bytes. Правда использование на доске не будет обновляться корректно, зато совсем не нужен used-space-filewalker и узел будет принимать данные, пока место не кончится (резерв по умолчанию 300ГБ, но его [можно изменить](https://forum.storj.io/t/the-whole-disk-partition-allocation-feature/28192/2)). Другая экспериментальная многообещающая фича - hashstore: > [@Release preparation v1.118](https://forum.storj.io/t/release-preparation-v1-118/28648/1): > > - [81687fa](https://github.com/storj/storj/commit/81687fa) shared/modular: support preset with settings for hashstore Мы скоро опубликуем, как её можно включить и использовать. Пока что она скрыта в текущей релизной версии. А текущий обходчик будет работать медленно без кэширования метаданных в SSD слое (доступно также в Windows, называется storage layers), либо в памяти (нужно не менее 1GB на каждый TB данных), либо badger cache. В случае Windows NTFS ещё помогает дефрагментация, однако для случая SSD это не должно быть важно. Если у вас оно работает медленно на текущем SSD, то возможно требуется обновить firmware. ---
**Author:** ![AiS1972](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ais1972/32/60_2.png) [@AiS1972](https://forum.storj.io/u/AiS1972)\ **Post date:** [November 30, 2024, 10:08am UTC](https://forum.storj.io/t/5-node-age-65-months-7-28-70/28679/3 "2024-11-30T10:08:36Z")
> [@Alexey](#): > > А текущий обходчик будет работать медленно без кэширования метаданных в SSD слое (доступно также в Windows, называется storage layers), либо в памяти (нужно не менее 1GB на каждый TB данных), либо badger cache. Алексей! Да бог с ним с обходчиком, диски выделенные, потому он отключен обычно. Мне почему то кажется что сейчас версия ноды на windows стала даже принимать ингреса в 3-4 раза меньше чем на линуксе. Ощущение что что-то в коде ноды некорректно работает с файловой системой. Я собираюсь проверить эту версию, перенеся одну ноду на линукс с zfs и метой, и сравнить ингрес на ноде на windows и ноде на линукс. Потому как перенос ноды windows на ссд не дал оcобого преимущества в ингресе, в сравнении с той же нодой на hdd. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [December 1, 2024, 7:21am UTC](https://forum.storj.io/t/5-node-age-65-months-7-28-70/28679/4 "2024-12-01T07:21:57Z")
Аппаратное обеспечение никогда особо не влияло на количество входящих данных. Каждый узел - уникален и обслуживает клиентов по запросу. Даже на том же сервере они ведут себя по-разному, потому что используются разными клиентами: помните про фильтр /24? Вот он и помогает сателлитам выбирать узлы так, чтобы на одном сервере не оказалось несколько кусочков одного и того же сегмента, а значит с высокой долей вероятности эти узлы будут обслуживать совершенно разных клиентов. Windows NTFS известна тем, что обычно работает медленнее, чем даже ext4 на том же оборудовании, так что перемещение на ZFS может иметь положительный эффект.