08-29-2013, 11:54 PM | #1 |
Wizard
Posts: 3,821
Karma: 19162882
Join Date: Nov 2012
Location: Te Riu-a-Māui
Device: Kobo Glo
|
Fragmentation an issue for μSD filesystems?
Does anyone know whether fragmentation could be a performance issue for the Kobo filesystems?
The device's internal filesystem is EXT format which is supposed to be highly resistant, if not completely immune, to fragmentation effects. But the user filesystem where the main database, book and image files are stored is FAT format which can suffer badly from fragmentation problems, especially as it starts to fill up. If the FAT filesystem does suffer from fragmentation then perhaps having a larger μSD card that always stays at least half empty might help. |
08-30-2013, 01:08 AM | #2 |
Connoisseur
Posts: 56
Karma: 31830
Join Date: Oct 2012
Location: Australia
Device: Aura HD, after a train ate my Glo
|
Some time ago I was poking around Kobo's filesystem (https://www.mobileread.com/forums/sho...d.php?t=211550) and as part of that I used e4defrag tool.
However, I didn't even mention doing this in my post because it didn't really do much. In my humble opinion there are two reasons why it can't do much: First reason: it's an SD card we're talking here, which doesn't have seek time (and instead has block access time). Any large file cut in fragments, as long as those fragments aren't smaller than block size (~32 KiB?), should be read at the same speed regardless of whether those blocks are consecutive or not. "Seek" time doesn't depend on "distance" the "head" needs to travel. Second reason: due to an advantage EXT filesystems had over FAT filesystems in the 90s, a myth developed that linux filesystems somehow don't suffer from fragmentation. Windows got the same resistance with NTFS, but as a result defragmenters evolved into complex tools that attempt to put files in an optimised order (as opposed to simply not having files fragmented). Linux never got such tools. As a result, any EXT defragmenter you'll find today will be incredibly simplistic, and therefore useless (which just reinforces the myth, really). As for the database on the FAT partition -- you can defragment the FAT partition by just connecting it to a Windows PC. But to defragment any single file (such as the database) you can just connect it to the PC, move the file away from Kobo, then move it back. The new copy should be defragmented FAT filesystem also has very serious problem with fragmentation of directory structures. If you ever find a tool, that runs on NT Windows (as opposed to 95/98/ME), that can defragment FAT directories, this might be a huge thing. I personally never found such tool, and Windows' own defragmentation API will never touch FAT directories (so all "generic" defragmenters that just use the API are powerless). Last edited by sysKin; 08-30-2013 at 01:22 AM. |
Advert | |
|
08-30-2013, 05:04 PM | #3 | |
Bibliophagist
Posts: 34,734
Karma: 144851472
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Forma, Clara HD, Lenovo M8 FHD, Paperwhite 4, Tolino epos
|
Quote:
When I was using my Glo with a replacement internal uSD card, I had about 1400 books on it. One co-worker was saying that he noticed his ereader getting slower as he added and removed files though the total number of files on the ereader (Sony, not sure of the model) stayed around the same. To see if I noticed any effects on my Glo, I connected it to the computer, copied all the files in the FAT32 partition to my hard drive, formatted the partition and copied the files back. After this, I could see no difference in the times to open an ebook, search in the library, etc. Regards, David |
|
08-30-2013, 05:29 PM | #4 |
Captain Penguin
Posts: 2,944
Karma: 2077653593
Join Date: May 2009
Location: Vancouver, BC
Device: Kobo Libra 2, Nook Glowlight
|
This. Defragmentation is discouraged on solid state drives, as there's no seek time, which is the point defrag addresses. Besides, defrag moves (write/delete) files around, which increases wear on SSDs, which have a finite number of writes before performance degrades significantly.
|
Thread Tools | Search this Thread |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Question about K3 filesystems | lgx | Kindle Developer's Corner | 0 | 10-19-2010 12:22 AM |
DR800 alternative filesystems | bran | iRex | 3 | 09-28-2010 05:29 PM |
ἐγκώμιον: A (Xe)LaTeX Poetry Template | ahi | Workshop | 12 | 10-20-2009 09:00 AM |
New version of μBook | comtrjl | Reading and Management | 5 | 03-02-2008 01:17 PM |
iLiad filesystems | arivero | iRex Developer's Corner | 6 | 10-22-2006 02:05 PM |