B2 extremely slow

Hi @amazon12,
We released a new version of the desktop client that fixes B2 uploads for files over 5GB in size and tweaks the trash beahavior. You may still need to run the empty trash command multiple times if you have lots and lots of items in there, so let me know if you want to explore the CLI method I mentioned in the previous post.

Hi Tony,

The update did fix the upload issue, so that’s all cleared up. I think I will need the command-line stuff to fix up the trash though - it’s pretty much stalled.

Hi @amazon12,

Thanks for the update!

The CLI script for trashing is here:

Don’t worry, it looks worse than it is. It basically comes down to copying and pasting some lines into the terminal, but let me know if you have any questions.

OK, I have that running… Should I see any progress? I’m seeing the “still items in trash” echoed repeatedly, running the status command shows 42 items in the trash - same as when I started about an hour ago. Should I send a debug or is it just going to take a really long time?

Hi @amazon12,
It will probably just take a really long time. The folders in the 42 items listed could have thousands of files inside, so you won’t see visible progress on those until the entire folder is done.

Still going… :slight_smile:

Here’s something to look out for… I had two Desktop folders (let’s call them desktop-folder1 and desktop-folder2) syncing to B2. Apparently when I was moving stuff to Trash, I included my odrive/B2/odrive/desktop-folder1.cloudf and odrive/B2/odrive/desktop-folder2.cloudf. Sometime yesterday, I guess those placeholders got deleted and that triggered the delete of the actual desktop folders.

I guess that makes sense (the whole “sync any folder anywhere” feature is neat, but confusing when you start to think about where the files actually live), but just wanted to verify that’s expected behavior.

Also while I was poking around the B2 web interface it was sorely tempting to just tick the 40-some folders left and hit delete there… What would odrive’s reaction to that be?

Hi @amazon12,

That is correct. The sync engine will keep everything mirrored in terms of what exists on the cloud. Even though the placeholders don’t take up real space locally, they represent objects in the cloud. When you delete something locally it is put into the local odrive trash, which is really just a holding area for remote deletes. When you empty the trash, the remote delete command is sent to delete that item. Any other odrive clients running will see that the item is gone and reflect that change locally.

This would be okay. odrive will pick-up the changes, once they are processed, and remove the queued items from its own trash.

I like this method (delete on B2). Not sure if you’ve seen the interface, but regardless of whether the API just shows you a flat list of files per bucket, in the web UI, there’s a tree (takes a minute to build when logging-in) and you can select a list of things to delete pretty easily. Nuking a bunch of WordPress directories last night took maybe 2-3 hours - not fast, but in odrive I think we running at about one/day.

Here’s what the UI looks like:

Cool @amazon12!

Deletes at the source should definitely be faster. odrive should reflect the changes once they are processed fully by B2.