Disk usage discrepancy?

I didn’t say that. However I can say that

is ignorant.

Sorry, not sure I understand you. I didn’t pay for development of the current solution, I’m just a node operator.

I know you are trying to mock Storj developers, but you shouldn’t. It’s them who made it work as a network, that’s a big achievement already.

The way you refer to Storj developers, it sounds like you’re new here. It would help a lot if you actually acted like wanting discussion.

One thing that the lazy file walker broke is that before if a file was to be moved/removed, this was done immediatelly after reading its direntry and inode. As such, these structures were still in cache and did not have to be re-read to actually move/remove the file. Now however, if a low-memory system has to first read all inodes, and only then move/remove files, their file system structures could have already been removed from memory cache.

Another obvious one is that previously if GC was interrupted, at least some files were already moved/removed. Now we need to wait until the whole reading phase is finished.

I wrote down one suggestion here.

Another suggestion would be to give up on the temp directory, and write uploads directly to the blobs directory. This saves 2 synchrononous writes (plus some reads as well) to directories, plus at least ext4 will try to place the inode close to the blobs subdirectory, which may later save on seeks for both downloads and file walkers.

Though, better returns would come from giving up on using one file per piece.

Out of curiosity, are there any statistics how much of storage is hosted on Windows nodes? @Alexey suggested in the past we can establish a rough proportion of Windows to non-Windows nodes by looking at the number of downloads on Github, but it is probably also useful to look at total storage of Windows vs. non-Windows nodes.