Search the Community
Showing results for tags 'compression'.
Found 2 results
Since CloudDrive uses its own filesystem and has full control over it, has it been considered to implement native compression? And by compression, I don't mean NTFS file level compression, I mean optional native compression in CloudDrive's filesystem. This would reduce the amount to transfer data over the network at the expense of CPU usage (and in some cases RAM) during compression. I guess we could have two types of implementations of the compression feature. A simple mode and one advanced mode. The simple mode would just use one compression method that applies to whatever content is stored, for instance LZMA. It would be nice if the user could at least control the compression level (low / medium / high). And it would be useful if it was an adaptive compression technique where it is smart enough to not compress already compressed data like compressed pictures and movies. The advanced mode would give the user choice to tinker more with the settings. The adaptive compression technique could be extended, for instance different compression methods for different types of data. For instance, a rule could be set up to use PPMd for data containing a lot of text (text files, word, databases etc) which is highly effective on this kind of data, and other compression methods for other kind of data. Automatic compression that magically works behind the scenes in CloudDrive would be a very powerful feature. It would reduce the amount of data to transfer, and thus reduce the cost for both bandwidth and cloud storage since less data is stored. It has a cost of course; depending on the compression method used, CloudDrive would require more CPU and sometimes more RAM usage during file transfer. The time to download / upload data would be reduced but the time to compress and decompress would be increased. Giving the user to choice to enable compression would be very nice, and giving power users to control even more settings would be the cherry on top. So I'm curious - is this something you have considered? Is it something that users want? Needless to say I would like it a lot I believe compression, encryption and cloud storage go hand in hand.
Hello everyone! Another happy user of Drivepool with a question regarding NTFS compression and file evacuation. A few days ago I started having reallocated sectors counters on one drive. Stablebit scanner ordered drivepool to evacuate all the files, but there was not enough space so some of them remained. I bought another drive, which I added to the pool, and tried to remove the existing one, getting an "Access is Denied" error. Afterwards, I tried to force evacuation of files from the damaged drive using the appropriate option in the Stablebit scanner. This triggered a rebalance operation which was going very well, but then I notice several hundreds of GB marked as "Other" not being moved. Then it stroked to me that the new drive has some files without NTFS compression, whereas the old drives in the pool did have. I think somehow since the checksums are not the same for compressed and uncompressed files this is somehow confusing the scanner. What I did so far (for consistency at least, hope this doesn't make things worse!!!) is to disable compression from all the folders I had it enabled (from the old drives, including the faulty one) and wait for the rebalance to complete. Is this the right approach? Is this also expected to happen when using NTFS compression? In drivepool is actually not worth the hassle to have it enabled? (I was getting not fantastic savings, but hey! every little helps, and wasn't noticing perf. degradation). Hope the post somehow makes sense and also hope my data is not compromised for taking the wrong steps! Thanks! DrivePool version: 184.108.40.2068 Beta Scanner: 220.127.116.1162 OS: Windows 2016 Attached DrivePool screenshot as well