After updating from v6.3.5 to v6.4.1, it stuck on "Checking tribler version"

[vi]

No messages get logged to console.

[vi]

After moving away ~/.Tribler to ~/.Tribler.bak it got though. After cp ~/.Tribler.bak/dlcheckpoints/* ~/.Tribler/dlcheckpoints/ it also remembered the downloads.

[whirm]

@vi Could you confirm that copying the old DB back to .Tribler makes Tribler fail again?

[vi]

Backed up current .Tribler, restored old v6.3.5 .Triber.

Checking Tribler version...

I have just noticed that it's also big: sqlite directory is 543.7MiB.
Have you already considered other databases like LevelDB (or like that)? Maybe you can put torrents themselves into it, avoiding CTF(collected_torrent_files) directory at all.

Maybe it's just slow? I see some CPU and IO activity...

It's traversing CTF with stat64... Let's wait...
There should be a progress bar (based on number of traversed files, as there is a maximum for it).

Deleting swift files ... The collected_torrent_files directory shrinks...

Migrating torrent files -> ERROR dropping corrupted torrent file .... Invalid cross-device link (maybe because my corrected_torrent_files lives on a separate BTRFS partition).

rename("/home/vi/home/tribler/TriblerDownloads/collected_torrent_files/6b2edbaebc0adebd1055c231b7b2e7e32b0945fc", "/home/vi/home/tribler/TriblerDownloads/.tmp_migration_v64/d0cb1b71253b9225094a20ceb2d8e4dd42a97d45.torrent") = -1 EXDEV (Invalid cross-device link)

Tribler seems not to behave good in a space-constrained environment. BTW it's deleting all its torrents... How self-destructive.

Symlinked .tmp_migration_v64 into correct location. Now it the migration process seems happier than before.

Finally:

Failed to upgrade the on disk data. Tribler has backed up the old data and will now start from scratch. Get in contact with the Tribler team if you want to help debugging this issue. Error was: Checking all directories in torrent collecting directory...

ERROR 1420668790.93 upgrade:55 failed to upgrade: Cannot call rmtree on a symbolic link (because of I have just created it. Should have been used mount -o loop instead).
Fragile...

My Tribler setup spans 3 partitions: the first for profile, the second for downloads and the third for CTF. And dlcheckpoints is also a candidate to be apart from the biggish SQLlite database.

Maybe you should also tell the user from the beginning that Tribler is going to occupy about 6 GB of your disk space. Make sure you have it. That way I may had arranged it in a saner way. In general I don't think it's a good idea to store a lot of little files and big vides on the same partition.

Ending experiments and restoring .Tribler from backup again. CTF is gradually being repopulated again.

[whirm]

@vi we've seen that the torrent migration is quite slow on some machines but we haven't investigated further as we are seriously thinking about killing the torrent collection altogether and just share magnets with some metadata associated.

I've sent a pull request that should deal with the cross-filesystem issues you where having.

Do you still have the 6.3.5 data around to test again with 6.4.2?

Thanks!

[vi]

The migration can be slow, but in this case it should be mentioned in the message to use (not just Checking Tribler version),

I have ~/.Tribler backup for 6.3.5, but not the torrent collection was removed.

just share magnets with some metadata associated.

Will Tribler be self-sufficient, i.e. will the network of only other Tribler clients, without other non-Tribler torrent peers still work?

[whirm]

The part I've seeing being slow was the torrent parsing/migration and you see the infohashes passing trough.
In your case it was before that?
I'll have a look and see what's going on before we get to that point.

RE being self-sufficient: yes, it would collect the torrent info from the DHT as when you click on a standard magnet link.

[whirm]

@vi: We are working on a branch which uses a leveldb based torrent store instead of the collected_torrent_files directory:

https://github.com/whirm/tribler/tree/torrent_store_migrator

That branch includes the upgrade code too, so it will ingest all your torrent files into the new store.

It will also store the torrent stuff in .Tribler instead of TriblerDownloads, just so you know.

Could you put a copy or your old backup in place and tell us how it behaves for you?

Have in mind that you will need to install python-leveldb to be able to run this branch.

Thanks!

[whirm]

As a note for comparison: On my machine it takes about 10 minutes to do the whole verification/migration procedure with a 2.1 GB collected_torrent_files directory.

[vi]

Restored v3.6.5-backed-up .Tribler, tried running whirm/tribler@3676ea3. It "ingested" the collected torrent files, but after that stopped Failed to upgrade the on disk data. with

ERROR   1422662120.63         upgrade:70    failed to upgrade: Cannot call rmtree on a symbolic link
Traceback (most recent call last):
  File "/home/vi/home/tribler/tribler/Tribler/Core/Upgrade/upgrade.py", line 54, in check_and_upgrade
    yield torrent_migrator.start_migrate()
  File "/home/vi/home/tribler/tribler/Tribler/Core/Upgrade/torrent_upgrade64.py", line 64, in start_migrate
    self._migrate_torrent_collecting_dir()
  File "/home/vi/home/tribler/tribler/Tribler/Core/Upgrade/torrent_upgrade65.py", line 70, in _migrate_torrent_collecting_dir
    rmtree(self.torrent_collecting_dir)
  File "/usr/lib/python2.7/shutil.py", line 232, in rmtree
    onerror(os.path.islink, path, sys.exc_info())
  File "/usr/lib/python2.7/shutil.py", line 230, in rmtree
    raise OSError("Cannot call rmtree on a symbolic link")
OSError: Cannot call rmtree on a symbolic link

Probably it tried to rmtree the ~/TriblerDownloads/collected_torrent_files which is a symlink to other partition in my setup.

By the way ~/.Tribler/collected_torrents, ~/.Tribler/sqlite and ~/.Tribler/dlcheckpoints are also good candidates to be symlinked away from "home" partition to "storage" partition...

Also note about free space pressure: LevelDB tends to perform slower and slower when out of disk space (it waits for some space to be reclaimed and attempts again to store the new data). Migration of collected_torrent_files to collected_torrents is not "streamlined", it temporarily requires twice as much of the storage. And if there is no free disk storage available, it will "stuck", not fail early.

Maybe you should delete each collected torrent file individually after adding them to LevelDB, and not try rmtree after the end (what if some unrelated data gets in the way?). Unknown unidentified files (not a torrent or thumbnail or something like that, with non-standard name) should not be removed.

(this paragraph is extracted into a separate issue: #1186)

[whirm]

I don't think we are going to support symlinking stuff around any time soon.

However some paths can be configured trough libtribler.conf and we would accept PRs that add some more if they make sense.

RE deleting torrent files when adding them to LevelDB, that's how we are doing it: https://github.com/whirm/tribler/blob/torrent_store_migrator/Tribler/Core/Upgrade/torrent_upgrade65.py#L106

The only thing that could be done is to make sure we have enough space in the target dir for the upgrade procedure to succeed.

[whirm]

@vi I've created an issue for the disk space thingie and I'm closing this one as your issues have to do with manually symlinking stuff around which you should be able acomplish by editing paths in `libtribler.conf``

[vi]

Missing link to the disk space issue: #1189