# Speed up storagenode migration by first migrating to hashstore **URL:** \ **Category:** Node Operators\ **Tags:** move-node, hashstore\ **Created:** [June 30, 2026, 7:05am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992 "2026-06-30T07:05:16Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![HGPlays](https://storj.bcdn.literatehosting.com/letter_avatar/hgplays/32/5_5575768a8748004e209b776fc1b2916d.png) [@HGPlays](https://forum.storj.io/u/HGPlays)\ **Post date:** [June 30, 2026, 7:05am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/1 "2026-06-30T07:05:16Z")
I have not been paying attention for a long time. I soon need to migrate a few 10TB nodes to new 18TB drives - and want to know if the hashstore is rolled out for all nodes now? if not, was it not supposed to by now? Hashstore cuts my copy time down by alot. (yes i know the recomendations for moving nodes, i do it my way). Thanks in advance ---
**Author:** ![Ottetal](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ottetal/32/18876_2.png) [@Ottetal](https://forum.storj.io/u/Ottetal)\ **Post date:** [June 30, 2026, 7:27am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/2 "2026-06-30T07:27:42Z")
We’re not fully converted to hashstore on all satellites. `du -shx /mnt/storj/storjnode-*/data/storage/blobs` to get the currently remaining blob size on all your nodes. ---
**Author:** ![HGPlays](https://storj.bcdn.literatehosting.com/letter_avatar/hgplays/32/5_5575768a8748004e209b776fc1b2916d.png) [@HGPlays](https://forum.storj.io/u/HGPlays)\ **Post date:** [June 30, 2026, 7:28am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/3 "2026-06-30T07:28:44Z")
Thank you @Ottetal appreciate the answer. ---
**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\ **Post date:** [June 30, 2026, 10:50am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/4 "2026-06-30T10:50:19Z")
> [@HGPlays](#): > > Hashstore cuts my copy time down by alot. Oh yeah! Using rsync: piecestore nodes used to move at 10-20MB/s (usually the low end)… and hashstore nodes move at 50-100+MB/s (usually the high end). ---
**Author:** ![EasyRhino](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/easyrhino/32/1133_2.png) [@EasyRhino](https://forum.storj.io/u/EasyRhino)\ **Post date:** [July 1, 2026, 5:33pm UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/5 "2026-07-01T17:33:39Z")
> [@Roxor](#): > > Oh yeah! Using rsync: piecestore nodes used to move at 10-20MB/s (usually the low end)… and hashstore nodes move at 50-100+MB/s (usually the high end). Oh nice, that will make migrating disks several times less painful! ---
**Author:** ![HGPlays](https://storj.bcdn.literatehosting.com/letter_avatar/hgplays/32/5_5575768a8748004e209b776fc1b2916d.png) [@HGPlays](https://forum.storj.io/u/HGPlays)\ **Post date:** [July 2, 2026, 8:20pm UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/6 "2026-07-02T20:20:01Z")
indeed - and i am looking at about 50TB of total used space that soon needs to go to new drives 😃 ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [July 4, 2026, 2:03am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/7 "2026-07-04T02:03:22Z")
> [@Hashstore Migration Guide](https://forum.storj.io/t/hashstore-migration-guide/30658/362): > > > [@Hashstore Migration Guide](https://forum.storj.io/t/hashstore-migration-guide/30658/361): > > > > Oh yeah! Using rsync: piecestore nodes used to move at 10-20MB/s (usually the low end)… and hashstore nodes move at 50-100+MB/s (usually the high end). > > Oh nice, that will make migrating disks several times less painful! > [@HGPlays](#): > > i do it my way 🤦 Move the _the whole filesystem_. Not file by file. Not “your way”. If “your way” is not moving the whole filesystem — “your way” is wrong. You all are still moving the whole filesystem, because you have to, because otherwise the node will break. You are just doing it in a number of competing worst ways possible. It doesn’t matter which of the wrong ways is a winner at being slightly less crappy. They are all wrong. Why do you all insist on eating cactuses? 🌵 ---
**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\ **Post date:** [July 4, 2026, 10:57am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/8 "2026-07-04T10:57:09Z")
There are certainly times it **can** make sense to move entire partitions - especially if Storj is the only thing using them. But if Storj only has access to “extra space”… you may not be able to do it that often. The last node I moved used 2TB of a full 18TB disk, so it didn’t make sense to move 16TB extra. And the time before that I needed to move the node from a 14TB drive to a 10TB drive. Unless this is a sneaky way of promoting ZFS datasets: so you can use zfs send|receive, and move incremental snapshots instead of using multiple rsync runs? Then that sounds like a good idea! 👍 I just didn’t initially set things up like that… but I guess I could change… ---
**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\ **Post date:** [July 4, 2026, 1:54pm UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/9 "2026-07-04T13:54:26Z")
> [@Roxor](#): > > There are certainly times it **can** make sense to move entire partitions I’d say rarely there is not. Of course storagenode must reside on its own filesystem. Why would you mix your data with storagenode data? Both zfs (datasets) and btrfs (subvolumes) support this, for this specific, very common usecase — have multiple filesystems share raw space, without rigid partitioning. Oh, NTFS and ext4 don’t? Yeah, fat16 and fat32 don’t either. Don’t use ancient filesystems. To be fair, Microsoft did make an attempt with storage spaces and then reFS. They failed spectacularly, but they did make an attempt. > [@Roxor](#): > > sneaky way [yes](https://forum.storj.io/t/zfs-moving-storagenode-to-another-pool-fast-and-with-no-downtime/22668) But there is nothing sneaky about it. This is the intended and preferred way to move data. Storj has to recommend per file rsync becuse it’s the safest, fs-agnostic approach. It will work and it will succeed, and does not require support. “Just wait, it will finish”. Does not mean it’s the best or efficient way. ---
**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\ **Post date:** [July 4, 2026, 7:15pm UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/10 "2026-07-04T19:15:05Z")
> [@arrogantrabbit](#): > > But there is nothing sneaky about it. This is the intended and preferred way to move data. I think you’ve convinced me. The next time I need to move a node I’ll still pick-it-up with rsync… BUT… I’ll make sure to put-it-down on its own dataset. I can start to get a taste of if future maintenance with send|receive will be more streamlined. Thanks! ❤ ---
**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:** [July 5, 2026, 5:50am UTC](https://forum.storj.io/t/speed-up-storagenode-migration-by-first-migrating-to-hashstore/31992/11 "2026-07-05T05:50:44Z")
LVM helps with migration too > [@Best Practice for Transferring Data To New Drive](https://forum.storj.io/t/topic/22111/34): > > It’s not difficult, but requires to read a documentation. I would emulate this on loop devices Create images for the disks $ truncate -s 1G disk1.raw $ truncate -s 1G disk2.raw Create loop devices to emulate disks $ sudo losetup -f disk1.raw $ sudo losetup -f disk2.raw find which one loop devices has been created $ losetup | grep disk /dev/loop6 0 0 0 0 /home/ubuntu/disk1.raw 0 512 /dev/loop7 0 0 0 0 /home/ubuntu/disk2.ra…