It looks like moving data to the “trash” folder is done by copying the file there and then deleting the original. This results in a lot of disk IO because all of that data needs to be copied to the new location.
Why this is not done as a simple “move” operation that would just change the file system metadata and be much faster?
I’m also getting a lot of disk IO which I assume is for the same reason. I’m also assuming that in a real world situation the data moved to trash would be more of a steady stream so would have less impact?
I am hoping fro an answer from Storj - was this done on purpose (and if so, why) or did it somehow happened (which would mean that hopefully it would be fixed in the future)?
There probably won’t be 180GB of garbage moved at once in production though, so even if this stays, maybe it won’t be so bad.
@nerdatwork Umm, no. If the PC crashes while copying you have a half-written chunk of garbage lying around. Modern logging file systems don’t break when a cross-directory rename gets interrupted by a power failure.
Even if they did, the window for damage would be a lot smaller (also, it’s a file that’s moved to the trash anyway, so the damage is kindof very limited).
Copying files is not free, the superfluous copy slows down the node.
It was 20MB/s read, 40MB/s write. Also, hard drives are usually not that optimized copying data from one place of the drive to another (I guess I could mount separate array as the “trash” folder, but it could lead to complications.
I have also noticed this as well putting unnecessary load on the hard drive to copy files to another folder. Should be a more efficient way to do this is it possible to just mark a file to be deleted instead of copying to another folder. If someone was running this node on there windows machine its going to slow there system down alot. Its going to create a unpleasant performance drop over all to there PC.
I don’t know any filesystem which has a permission bit “mark as deleted”. Even if there were, it has to work on all filesystem the same way.
I don’t understand why the files are not moved. A move within the same filesystem is an atomic operation, at least under *nix. There is no risk of data loss.
no one speak about data loss, do not know how it made but looks like it not take atomic time, like if it copied entierly. But i might be wrong.
Under mark, i meant like change extension from sj1 to trash
I was hit by this recently as well, which is even more mysterious given that my nodes have been up pretty much 24/7 for weeks, so there shouldn’t even be a need for any GC – my nodes wouldn’t’ve missed any delete instructions.
This approach to storing trash is causing thrashing just like others have experienced. Please fix this.
This was a bit of a special scenarion with a large amount of zombie segments being cleaned up at the same time on the satellites end. Normally GC would only have to deal with very small amounts.