Kolibri: Free Space Report Is Wrong When Content is Symbolically Linked

[nobicycle]

Observed behavior

$ ls -l /opt/kolibri/
total 219344
lrwxrwxrwx 1 root root 44 Sep 7 21:19 content -> /media/esata/MEDIA_DISK/KOLIBRI_DATA/content
-rw-r--r-- 1 kolibri kolibri 220577792 Sep 9 10:15 db.sqlite3
-rw-r--r-- 1 kolibri kolibri 32768 Sep 9 10:41 db.sqlite3-shm
-rw-r--r-- 1 kolibri kolibri 78312 Sep 9 10:41 db.sqlite3-wal
-rw-r--r-- 1 kolibri kolibri 0 Sep 7 19:06 debug.log
-rw-r--r-- 1 kolibri kolibri 4096 Sep 7 19:06 job_storage.sqlite3
-rw-r--r-- 1 kolibri kolibri 32768 Sep 9 10:15 job_storage.sqlite3-shm
-rw-r--r-- 1 kolibri kolibri 3761592 Sep 8 12:42 job_storage.sqlite3-wal
-rw-r--r-- 1 kolibri kolibri 66774 Sep 9 10:15 kolibri.log
-rw-r--r-- 1 kolibri kolibri 479 Sep 7 19:06 kolibri_settings.json
drwxr-xr-x 5 kolibri kolibri 4096 Sep 7 19:06 kolibri-venv
-rw-r--r-- 1 kolibri kolibri 6538 Sep 9 10:41 server.log
-rw-r--r-- 1 kolibri kolibri 10 Sep 9 10:15 server.pid
drwxr-xr-x 2 kolibri kolibri 4096 Sep 9 11:01 sessions
drwxr-xr-x 25 kolibri kolibri 4096 Sep 7 19:06 static

[me@tower Raccoon]$ df -h / /media/esata/MEDIA_DISK
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 39G 34G 2.4G 94% /
/dev/sdb2 1.8T 1.6T 140G 92% /media/esata/MEDIA_DISK

Note the symlinked location has 140G available but Kolibri front end reports "Your remaining space: 2 GB"
…

Expected behavior

Correct free space should be reported.

…

User-facing consequences

Cannot install content.

…

Errors and logs

Vivaldi browser

1.15.1147.42 (Stable channel) (64-bit)

Kolibri version | 0.10.2
-- | --
http://192.168.1.100:8087/
/opt/kolibri/db.sqlite3
tower
Linux-4.14.65-1-MANJARO-x86_64-with-arch-Manjaro-Linux
2 GB

kolibri.log.txt
server.log.txt

[indirectlylit]

related: #3883

[indirectlylit]

@lyw07 would you mind taking a look at this?

[lyw07]

Yes sure. I will look into this issue

[lyw07]

Hi @nobicycle ,

Instead of creating symbolic links to your new disk to extend the storage space, I would recommend using our command kolibri manage content movedirectory <destination> to move your current content into the new disk and set the new disk folder to be the directory to store all the content. Here are the instructions for using the command: https://kolibri.readthedocs.io/en/latest/manage.html#change-the-location-of-kolibri-content-files

But even with using the command, the free space report is still wrong, as you pointed out in this issue. I would fix the issue under the circumstance that the directory of content files is reset through the command kolibri manage content movedirectory <destination>.

Please let me know if you have any questions. Thank you for filing the issue!

[nobicycle]

@lyw07

The link 'ln -s' command is the simplest way to achieve kolibri content on an alternate volume. It is completely transparent to the application and guaranteed not to cause issues.

This method is referenced in your own Kolibri administration area of the manual.

Performing some complicated trick in Python is clearly an inferior choice .

Most servers are now running Linux, even on the Microsoft Azure platform.
Therefore this platform is the one you should be prioritizing and therefore you should be using its low-level application transparent solutions.

Even after running your "Python trick" the disk space is still reported wrong.

[indirectlylit]

Hi @nobicycle -

The guidance that @lyw07 gave you is correct. It is not a "python trick", but a new Kolibri feature which allows the application to explicitly reference the content in a location outside of the Kolibri home folder.

This method is referenced in your own Kolibri administration area of the manual.

Thank you for bringing this to our attention. We'll update the docs to remove this outdated advice.

It is important to use the content movedirectory command because it ensures that your database is kept annotated with all available content.

Even after running your "Python trick" the disk space is still reported wrong.

As was clearly communicated, "even with using the command, the free space report is still wrong, as you pointed out in this issue".

The fix is referenced directly above and will be available in the 0.11 release.

Performing some complicated trick in Python is clearly an inferior choice.

In the future, please be more respectful in the way that you express your opinions in our repos. For reference see our code of conduct.

[benjaoming]

Hi @indirectlylit and everyone else - the Code of Conduct team is there to resolve any grievances, disputes etc. If you feel that unacceptable behavior has taken place, just flag the team that handles this: [email protected]

---

As a Linux user, I feel that making symbolic links is in my DNA. It's a very intuitive way of managing disk space in a flexible way, free from hierarchic directory structure. So I'd be very sorry if suddenly we didn't support it, and have to tell people who are using symbolic links are wrong.

The freedom to manage the file system of Kolibri is extremely critical, as it will contain large amounts of data. Users have to be able to schedule and manage disk space according to their tools, knowledge and needs.

Using symbolic links, mount points etc. are all part of this. Using kolibri manage content movedirectory is another alternative that's especially critical to ensure that inexperienced users have a safe method to move data. IMO they are not interchangeable.

[indirectlylit]

Thank you @benjaoming for flagging this.

My apologies, @nobicycle: it was not my intent to accuse you of a violation.

I really do appreciate your engagement and you've been a valuable member of our small development community over the past year, with many insightful contributions.

[nobicycle]

Compared to "ln -s SOURCE TARGET" running "kolibri manage content movedirectory " is mystifying (the sense of 'trick' used) to an administrator, so I stand by my words.

@indirectlylit thank you.

I am still not sure of the policy going forward. "We'll update the docs to remove this outdated advice." Does this stand?

or this:

"Using symbolic links, mount points etc. are all part of this. Using kolibri manage content movedirectory is another alternative that's especially critical to ensure that inexperienced users have a safe method to move data. "

If we are handing out compliments I'd like to say the team that I have interacted with on this repo are excellent.

[lyw07]

Hi @nobicycle

Thank you for your understanding! I'm working on a PR to fix the issue when the content directory is symbolically linked. It's #4444 . Hopefully we will get it merged soon so you issue can be resolved when you update to our future release 0.11.0.

I came up with the recommendation about using the kolibri manage content movedirectory initially because we recently developed this command, and it was the first thing came into my mind when I saw this issue. I'm sorry that I didn't explain my words clearly. Again, I really appreciate your help in issuing all the kolibri bugs you have found to improve our code.

Also, thank you @indirectlylit @benjaoming for handling this issue while I was away for the vacation! :)

[indirectlylit]

"We'll update the docs to remove this outdated advice." Does this stand?

@benjaoming and I differ slightly on this and will discuss further

My recommendation would be to use the movedirectory command unless there is a specific reason that it's not working for you. If that's the case, I'd be interested to better understand what's not working, and you can use symlinks as a workaround.

One might expect symlinks inside KOLIBRI_HOME to be transparent to the application, but as we can see in #4444 it does raise some edge cases.

[benjaoming]

Fixed in #4444 - so closing this.

@indirectlylit - symlinks are very powerful mechanisms for distributing massive amounts of contents over several partitions and devices. Also in the case that the database is desired to run on a small, fast drive, while content is stored on a larger, slower drive. Therefore, I think we should keep up the effort to support it, although I agree that now that we have movedirectory, this is obviously cleaner and safer to communicate to normal users.

Thanks all! :)