I have the storagenode in Windows and it runs on Docker. The disk filesystem is NTFS.
I need to migrate to Linux Debian and not to loose the node.
What should I do in this case?
Can I simply get the HDD from Windows PC and put the disk to a different machine on Linux or I should make a migration with some specific instrument on different machine with different disk via lan?
Linux can read NTFS, but can be safer to copy over network from windows host to linux host.
Alternatively, you can run chkdsk on a disk, to correct all possible inconsistencies in the filesystem and then move the disk to linux computer… but I would still feel safer letting the proprietary OS deal with its proprietary FS.
I would add, if your Windows is Windows 10/11, it uses deduplication and encryption features of NTFS by default. You may have issues with this disk on Linux, because Linux doesn’t support these features out of the box, so your node may start to failing audits, because it cannot read deduplicated/encrypted data. NTFS working noticeable slower under Linux, so your node will start to use much more RAM. The integrated tools to check NTFS disk under Linux is not fully compatible, so to check and fix the filesystem you would need to reconnect this disk to the Windows PC and check it there.
So, either disable deduplication and encryption for this disk, check the filesystem and try to use it under Linux keeping in mind all limitations or migrate data to the ext4 disk.
Got it. I have a small amount of HDDs for insurance on warehouse so I will go with migration to the ext4 disk.
Thanks to arrogantrabbit and Alexey for solving my questions.
PS please look for
problem-with-pulling-storagenode-image-to-docker
topic.
I’m trying to keep the nodes alive while I’m experimenting with migration and avoid silly moves in haste.
Добрый день!
Возник вопрос по команде копирования rsync:
Какой флаг в команде нужно использовать для копирования файлов, чтобы значения owner и permissions менялись при копировании автоматически на owner и permissions директории в которую производится копирование?
На текущий момент команда выглядит так:
sudo rsync -aP -e "ssh -p XX" -v /mnt/g/identity/storagenode/ user@192.168.1.X:/var/storj/storagenode1/identity
файлы копируются с owner user:user.
у директории owner user:docker.
Также если создать новую поддиректорию в /var/storj/ через mkdir из под пользователя, присваивается user:user, хотелось бы чтобы при создании получало `user:docker’.
-a это тоже самое что -rlptgoD, где
-p, --perms preserve permissions
-o, --owner preserve owner (super-user only)
Если вы не хотите чтоб копировался владец и разрешения — не указывайте эти флаги.
https://linux.die.net/man/1/rsync
А зачем? Права на файлы и директории соответвсут тому кто их создал. Можно конечно вот с этим поиграть, иногда даже работает: linux - How to set default file permissions for all folders/files in a directory? - Unix & Linux Stack Exchange
Эти флаги не указывал - они будут бесполезны при переносе с windows в linux.
Часто бывало что переносе узла с одного диска на другой (в Windows) возникал конфликт прав и владельцев, поэтому пытаюсь понять как сделать так,
чтобы файлы при копировании записывались с параметрами директории.
У меня нет базовых знаний, поэтому всё читаю и анализирую в процессе в рамках очередного кейса.
Часто мои предположения и выводы далеки от того что должно быть на самом деле:)
В данном случае:
если я создал директорию var/storj с -o user:docker,
значит для дальнейшей корректной работы узла после его запуска
у файлов в этой директории должны быть те же параметры.
Чтобы user и docker могли rwd и exec все файлы в директории.
Или это ошибочно и user:user в качестве владельца будет достаточно?
права выглядят так:
ls -l /var/storj/storagenode1/data
total 68
drwxr-xr-x 2 user user 4096 Sep 27 10:43 bin
-rw------- 1 user user 8533 May 20 21:07 config.yaml
drwx------ 4 user user 4096 Feb 24 2021 orders
drwxr-xr-x 2 user user 4096 Sep 30 02:40 retain
-rw------- 1 user user 32768 Sep 30 10:45 revocations.db
drwxrwxrwx 7 user user 4096 Sep 30 15:00 storage
drwx------ 2 user user 4096 Sep 30 15:02 storagenode
-rw------- 1 user user 933 Sep 30 10:45 trust-cache.json
если бы вы не указали -p ( косвенно, через -а), то результат бы был точно как вы хотели:
New files get their “normal” permission bits set to
the source file’s permissions masked with the
receiving directory’s default permissions (either
the receiving process’s umask, or the permissions
specified via the destination directory’s default
ACL), and their special permission bits disabled
except in the case where a new directory inherits a
setgid bit from its parent directory.
--perms, -p
This option causes the receiving rsync to set the
destination permissions to be the same as the source
permissions. (See also the --chmod option for a way to
modify what rsync considers to be the source permissions.)
When this option is off, permissions are set as follows:
o Existing files (including updated files) retain
their existing permissions, though the
--executability option might change just the
execute permission for the file.
o New files get their "normal" permission bits set to
the source file's permissions masked with the
receiving directory's default permissions (either
the receiving process's umask, or the permissions
specified via the destination directory's default
ACL), and their special permission bits disabled
except in the case where a new directory inherits a
setgid bit from its parent directory.
Thus, when --perms and --executability are both disabled,
rsync's behavior is the same as that of other file-copy
utilities, such as cp(1) and tar(1).
In summary: to give destination files (both old and new)
the source permissions, use --perms. To give new files
the destination-default permissions (while leaving
existing files unchanged), make sure that the --perms
option is off and use --chmod=ugo=rwX (which ensures that
all non-masked bits get enabled). If you'd care to make
this latter behavior easier to type, you could define a
popt alias for it, such as putting this line in the file
~/.popt (the following defines the -Z option, and includes
--no-g to use the default group of the destination dir):
rsync alias -Z --no-p --no-g --chmod=ugo=rwX
Зависит от реализации демона на виндоусе и как производится копирование - через rsync транспорт или сетевые диски.
Если вы копируете на сетевой диск то права будут такие же как и у соединения. Если через rsync транспорт — то может быть что угодно.
Тут куча ньюансов. Права и владельцы должны действительно быть настроены так чтобы storagenode могла читать и писать файлы, это не значит что владелец должен совпадать. Можно просто дать группе Everyone r/w доступ, и тогда вообще будет неважно кто владелец.
В документации тут написано Storage Node - Storj Docs что можно передать user id и group id через параметр
--user $(id -u):$(id -g)
Тут берется значие текущего пользователя, кто запускает docker run и узел будет запущен от имени этого пользователя. (Это не значит что численное значение id внутри и снаружи контейнера будет одинаковым!)
Теоретически, можно копировать данные как угодно, и потом передать в --user UID и GID владельца файлов. Практически, работоспособность этого будет зависеть от наличия SELinux или AppArmor на машине. Если они запущены, то пространство имен внутри контейнера и хоста разные. Пользователь 313 на хосте может будет соответствовать пользователю 100312 внутри контейнера. Потому так вот назначать права не получится.
Самый надежный способ – это скопировать c какими попало владельцем (или указать владельца через --chown) но дать права читать/писать всем через аргумент --chmod, например, так
rsync -a --chmod=ugo=rwX
Затем запустить контейнер, запустить новый Шелл в контейнере и перезаписать владельца на все файлы изнутри контейнера на пользователя который запускает узел. После этого можно убрать права на g и o, и оставить только u=rw, и получится как права на config.yaml тут:
Можно, конечно, не заморачиваться и оставить как есть, с o=rwX (как сейчас стоит на storage:)
Нюанс тут:
Эта команда с хоста или внутри контейнера? “user:user” на хосте может не соответствовать ничему в конетейнере. Потому нужно это проверять из оболочки изнутри контейнера.
Подъитоживая:
rsync -a --chmod=o=rwX ...docker run -it <container name or id> /bin/shstat config.yamlsudo chown -R meow:woff /mnt/storage/blobssudo chmod -R 600 /mnt/storage/blobsЭто команда через терминал на хосте.
так как команда уже запущена и копирование идёт около 7 часов, сейчас уже ничего трогать не буду.
по окончании через Х дней, сделаю chown и chmod, поменяю характеристики при повторном запуске.
Поправка:
Должно быть как выше по тексту
Не быстрая история - перегнать по локалке 2,5TB.
За 19 часов примерно 6% (130GB).
Предполагаю что 4 узла с примерно +/- 2,5TB будут копироваться месяц.
“Хорошо” что объём данных на узлах снизился, было в среднем 8TB/диск.
Надеюсь что повторные синхронизации на порядок меньше времени займут.
Первая итерация завершилась,
2,35Tb копировалось примерно 16 дней.
Обычная локалка, сетевые карты 1gbps.
Это нормальная производительность для этого процесса или можно что-то сделать?
Так же что происходит с дельтой удаленных за время миграции файлов на узле - при повторном процессе rsync они удаляются или остаются внеузловым мусором на диске?
Можно попробовать rclone sync, заодно удалит в пункте назначения то, что было удалено в источнике, он должен быть быстрее.
Ещё раньше я использовал Resilio sync, тоже довольно быстро работает, автоматически увеличивая параллелизм до предела.
Последняя синхронизация при остановленном узле в источнике должна быть с флагом --delete, это обязательное требование не только для того, чтобы мусор удалить, но также чтобы удалить временные файлы от БД, иначе закончите с повреждёнными базами после старта в новой локации.
эту команду можно использовать не начиная процесс с самого начала?
имею ввиду что запустить её после rsync не удаляя ранее перенесённое.
благодарю за ценный совет - учту.
правильно вас понял - флаг --delete при команде rsync использовать?
разумеется. Единственное, я не помню, меняет ли дату rsync, если да, то стоит использовать флаг --checksum, чтобы команда rclone sync использовала только checksum, а не дату и размер.
В нашей документации (How do I migrate my node to a new device? - Storj Docs) мы рекомендуем использовать флаг -a, а он сохраняет оригинальную дату. Так что если вы использовали -aP, то можете смело использовать rclone sync -P без --checksum.
Да, но это имеет смысл только при финальном синке, когда исходный узел остановлен, в остальное время сам синк будет идти дольше из-за этого флага. Но его можно использовать всегда.
Жаль что в документации нет сценария с rclone sync, для меня она незнакома и пока сложно въезжать в новое в уже запущенном процессе.
На данный момент rsync запущен 2ые сутки, пока идёт процедура попробую поэкспериментировать на ненужных данных с конструкцией команды rclone sync.
А это пока что новый экспериментальный способ. Он не хуже, но пока не будет подтверждён несколькими Операторами, добавлять его в документацию как основной способ вроде рано.
Никаких проблем от его использования я не ожидаю.
Например, если вы использовали бы robocopy на Windows, то там можно увеличить параллелизм (это как раз то, что и делает rclone) с помощью опции /mt:<n>:
Посмотрел ветку, конструкцию команды тут не публиковал,
опубликую как текущий rsync закончится.
не обязательно основным, можно как один из способов в ветке для Linux.
Самая прелесть rclone, что он может быть использован в любой ОС. Даже на Android и iOS.
А ещё - он умеет Storj из коробки. То есть в самом экзотическом случае, вы сможете забэкабить в Storj, а потом через cunoFS запустить узел на этом и он будет работать. Да, иногда медленнее, чем с локальным диском. Но…
Это как?
Узел на нём крутить или данные на хранение публиковать?
Если честно вообще не понял о чём идёт речь:)
