View Single Post
Old 09-06-2016, 09:49 AM   #10
rtiangha
Evangelist
rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.rtiangha ought to be getting tired of karma fortunes by now.
 
Posts: 495
Karma: 356531
Join Date: Jul 2016
Location: 'burta, Canada
Device: Kobo Glo HD
Quote:
Originally Posted by Markismus View Post
As for probing...I always thought that Kobo went ridiculously slow or even end in a loop when indexing 23GB of books?! That's one of the big reasons for using Koreader for me. Searching such a database was said to take forever. Is that not true anymore?
I have about that many books (the rest of the space is taken up by various ZIM files; I have copies of offline Wikipedia, Wikitionary, etc.) on my 64 GB card. It takes about an hour for the on-device processing, which isn't too bad.

Really, the bottleneck in that case is Calibre, especially when using Kepubs; the driver is single threaded so it takes about 10-15 hours to process each epub one-at-a-time and then a few hours to transfer it all (I've noticed the write speed is about 2-2.5 MB/second). If the Kobo Extended Driver were multi-threaded and could process epubs in parallel like Calibre does if you manually do a batch Kepub conversion using one of the other plug-ins, then that would speed things up considerably for those with multi-core machines. One thing I haven't tried yet is to see if pre-converting epubs to kepubs in advance speeds things up in the event of recovering from a factory reset; I don't know if the Kobo plugins are smart enough to use a pre-existing kepub instead of converting a new one from scratch each time when sending to a device.

As for ext4 use, I tried it for a while last month using frostschultz's script and while it did speed certain file operations up, as my collection grew, there was some lag introduced compared to when everything was using fat32. Disabling journaling on the KOBOeReader partition using tune2fs helped a lot and the responsiveness returned to what it used to be (although rootfs and the recovery partion both use journaling by default and have always done so). However, you lose out on one of the major benefits of using ext4, so at that point, it becomes a comparison of the merits of a relatively new file system vs those of a relatively older file system. Suffice to say, when I had to factory reset my device again, I just stuck with fat32 since I use both Linux and Windows; my entire experiment was to see if journaling would help prevent the occasional database corruptions through normal usage I sometimes encountered with my very large device database (now 1GB and counting, although at the time it was around 600-700MB), but no, it really had no effect on that part of things and thus, I just make sure to run a disk check every time I connect my device to my computer. In theory though, ext4 should perform better on larger partitions overall compared to fat32.

Does anyone know what script is called when the device probes for new books? It'd be nice to know what to change to make the OS aware of a fourth partition. Else, what is the mount point for the external SD? I only have a Glo HD so I don't know what it would be.

Last edited by rtiangha; 09-06-2016 at 09:56 AM.
rtiangha is offline   Reply With Quote