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
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.
Thank you @Ottetal appreciate the answer.
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!
indeed - and i am looking at about 50TB of total used space that soon needs to go to new drives 
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? 
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…
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.
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.
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! 
LVM helps with migration too