The point is that your disk will not have time to copy and distribute at the same time. You will receive fines for not downloaded files. And disqualification in the end. That’s all. 7tb via rsync is… few weeks 
2 Likes
Here is an idea, you don’t need to do fancy tests, just fill up your free space in your SMR disk with some big files, (you can use whatever is at hand, linux isos, movies, game files, etc), leaving let’s say less than 1Tb free, keep your node running and come back and tell us how it behaves.
That is exactly what I did. Left 60GB free.
Disk usage still low. CrystalDisk mark RND512KQ1T4 32gb test size got me 80mb/s.
Either fine or bad testing on my part 
1 Like
The point is that your disk will not have time to copy and distribute at the same time. You will receive fines for not downloaded files. And disqualification in the end. That’s all. 7tb via rsync is… few weeks
In my mind, I will stop the node, copy 7TB to new node in under 16 hours, start the node and that is it. So not weeks but hours. No “fines”, still 100% audit, just a bit downtime.
1 Like
SMR drives are not good for storj once it starts getting alot of data, I can tell you 100% its not a myth and from experiance SMR drives generally dont do good less you have more then one SMR drive and more then one node on the same network splitting the traffic. Once a SMR drive is full you will probably have some issues if you dont allow for 10% or more free space or else you will not be having a good time because of the way SMR drives work I have lost my nodes because of missing data or missing idenity files because of how SMR drives shuffle data around and if you loose power or something while this happens you will lose everything.
I am running a 5.6TB node on a 6TB Seagate SMR drive and never had any issues so far (databases are on NVMe SSD‘s). But yes, filewalker takes some time….
I bet you won’t be able to transfer 7TB of node data in 16 hours. I did some rsync node transfers from different kinds of drives already and it was much slower unfortunately, even with fast CMR drives 16 hours for 7TB is more than unrealistic.
1 Like
Unless this is a semantic argument about the word suffering, I don’t see your point. If you spent money on an HDD that is now causing all these issues, you won’t be happy about it.
You can use the search feature just as well as I can. I don’t have a link readily available.
SMR drives function quite differently compared to CMR. I don’t think defrag is useful. This is because the disk internally remaps data to tracks in a different way. It acts more like an SSD in that sense and also has TRIM support to optimize those tracks. Regular defrag could also take unbearably long on SMR drives for obvious reasons.
Nodes come in many forms. Including raspberry pi, NAS systems etc. Many won’t have SSD storage available or even a CMR drive. And flash storage like SD cards used on RPI aren’t great at handling many writes in their lifetime.
This would not be a good test as that scenario won’t fragment the free space like running a node to fill up that space would.
yes, it would be. he just need to keep filling the disk until the free space is less than the CRM cache of the disk. that’s why i sad that he should keep running the node.
No it won’t. CMR cache isn’t the only thing that impacts speed. If the free SMR space is clustered together, the disk can still directly write to that without a big speed impact. It only becomes a problem if that free space is scattered over otherwise filled SMR zones. Read my previous posts.
I think this being such a simple test still warrant being tried.
Mi understanding is that the disk firmware always will try to keep the CRM cache free at all cost. No matter if a recent upload is first written to it, as soon an some of those tiny files on the node be deleted it will try to reclaim this space to free the CRM cache forcing a shingle rewrite.
SMR drives are not good at anything and they shouldnt be used for high amounts of data use with small files, This impacts it alot more, I have a SMR drive on one of my windows machines that stores games and the speeds while putting data onto haults down very quickly making the drive 100% useless. SMR drives should have never came to market for how bad they are for any use cases.
1 Like
I’m not a fan of blanket statements like that. The initial archive drives were horrible because they either hand small or non-existent CMR zones. But those that don’t make it abundantly clear that they are for archive purposes tend to perform better. It’s near impossible to know beforehand which one you get though, so yeah, I still avoid them like the plague too. But if you have one that works for your use case, please keep using it. It’s not a bad technology in itself, but there are horrible implementations of it. As for games… I’ve been avoiding spinning disks for years now for that purpose. Can’t deal with those load times anymore.
Yeah well I dont store games on rust these days since nvme drives and SSDs are so much cheaper. But had I known it was SMR I wouldnt have bought it in the first place though because performance is so bad for writing but reading is ok for the most part, But if your doing writing and reading at the same time SMR cannot handle it once the cache is gone.
But I speak from my bad experiances running storagenodes on SMR drives and they were only 4TB not 8TB so I can only imagine it being worse the bigger the drive is. I lost 2 storagenodes alone just by SMR loosing the data completely,.,
1 Like
SMR drives work I have lost my nodes because of missing data or missing idenity files because of how SMR drives shuffle data around and if you loose power or something while this happens you will lose everything
Maybe I would miss a data chunk. But that is true for any none COW filesystem. Identity is on SSD and even if it would not be, I can’t imagine how it should be destroyed by a power loss.
If you spent money on an HDD that is now causing all these issues, you won’t be happy about it.
Of course I did not spend any money. I have drives lying around that I do not wanna use because of bad sectors and/or SMR. I mean that is the whole point of Storj in my opinion. To me this is the only reason why Storj (maybe) has a chance competitive advantage against other S3 providers.
You can use the search feature just as well as I can. I don’t have a link readily available.
I did but did not find anything other than “Don’t do it SMR bad because I say so” or “I have no idea what I am doing and messed up”. These are not the things I am looking for. I am looking for “I had a productive SMR node running and because of SMR I ran into a problem”.
I am running a 5.6TB node on a 6TB Seagate SMR drive
That is what I am talking about! We finally found a SMR unicorn! Cheers, brother from another mother. Glad to hear you are running a full SMR node without any problems.
Did you stop accepting new files to have some free cache space?
How busy is your disk?
16 hours for 7TB is more than unrealistic.
100mb/s would be around 23 houers or roughly one day. That is fine by me. Even 3 days and 15 hours would still be 99% uptime over one year.
I lost 2 storagenodes alone just by SMR loosing the data completely
I wonder how SMR just looses all your data?
Power failure, then checkdisk in linux poof gone. Both drives do not have any bad sectors but both drives that I had were seagate 4TB x2 I just use them for raw storage for my server now…
Also theres alot of posts about SMR drives that kinda point you to not use a SMR drive, I havent been posting about mine because I was really annoyed when it happened and Id hate for you to go though the samething if it can be advoided. My node was 3 years old and I lost it because of a SMR drive. One because it lost data the other was because it lost the identity files and I didnt remember where I put the orginals.
SMR or CMR doesn’t matter when it comes to copying millions of small files, you will never get close to such speeds unless you’re cloning the disk partition directly from one disk to another.
It sucks to lose a node 
I’m wondering why an SMR drive would be worse than a CMR drive from a reliability point of view though? Is the SMR technology more prone to data loss?
My guess would be once it starts to get full it has less space to work with to shuffle data around and ends up either loosing over overwriting it. Its hard to explain what happen with both nodes but I still never understood what happen to this day. But both drives still work fine though. I really am at a loss as to why it happened.
bhahaha. good luck man. zfs send/recieve with mbuffer dont copy with so speed
There is a big difference. A non-COW filesystem may lose the data that it was writing just before the power failure. For Storj it may be the uploaded file or part of the database, though database would be recovered, with just te last rows missing.
When a SMR drive triggers a shingle update, it will rewrite 256MB or so and if the power goes out, you may lose those 256MB, which may include the latest file, but also could include old files and, more importantly, metadata, screwing up the filesystem. Usually filesystems expect that if the data is written to disk, it stays there and are only concerned about losing data they are writing right now, not the data they wrote a week ago.
Rsync with millions of tiny files would not get you anywhere near 100MB/s, maybe 5MB/s. OTOH, if your new drive is the same size as the current one, you can stop the node and copy data with dd, that would be fast.
A SMR drive is a hybrid between a normal HDD and a tape. It has large blocks (I think the most common size is 256MB) that can be written to normally the first time, but, when you need to overwrite some data in it, you have to rewrite the whole 256MB or however much data is there.
This creates multiple problems - performance (and possible timeouts) being one of them. Another problem is that if power fails during the 256MB rewrite you might lose the whole block, which may contain filesystem metadata.
SSDs have a similar problem, but their blocks are smaller (1MB or so) and good SSD have capacitors that hold enough charge for the SSD to finish whatever it was writing (it’s called power loss protection).
Is this really the case? I would hope that internal HDD management wouldn’t have any steps during that process when files aren’t somewhere on permanent storage. If this is true, your data is never really safe, because anything could be rewritten at any time… Even more reason to avoid them then.
You’d need to copy a whole shingle to the CMR area, then copy it back. Even more I/O. No idea whether this happens, I suspect the alternative is to have a capacitor large enough to power the drive to finish a single shingle update…