Improve performance of the micro SD

Owl_ · 01-31-2020, 07:31 AM

Hi, Anyone knows if it’s possible get better performance of a Kobo Clara HD, formatting his partitions with a bigger allocation unit size? (I know that a big allocation unit size improve the speed of the micro SD)
If yes how must I do? (I’ve got windows that doesn’t allow me to see the linux partitions)

DNSB · 01-31-2020, 06:25 PM

Quote:

Originally Posted by Owl_

Hi, Anyone knows if it’s possible get better performance of a Kobo Clara HD, formatting his partitions with a bigger allocation unit size? (I know that a big allocation unit size improve the speed of the micro SD)
If yes how must I do? (I’ve got windows that doesn’t allow me to see the linux partitions)

Even if you pop the uSD card out and into a Linux system, I suspect that you would find ext4 using extents would limit any gain by playing with the block size. With the default 4K block size, an ext4 extent can map up to 128MB in contiguous blocks. With 4 extents in an inode, that gives 512MB.

The other thing to remember is the Linux family of OS very often reads and writes small blocks. This was brought out years back when people were finding wildly varying results on Nooks. XDA has quite a few items on this -- SD Strange-results - or - How I learned to love CM7 on SD - Dec-11 results compiled! for one example.

NiLuJe · 01-31-2020, 07:20 PM

Also, the actual user content is stored on a vfat partition, and FAT32 is the pits, no matter which way you look at it.

hobnail · 01-31-2020, 09:33 PM

If you're trying to speed up the initial opening of a book I can sympathize. But I wonder how much of it is due to the SD card versus the slow as molasses CPUs they use in these gizmos.

rtiangha · 02-01-2020, 12:10 AM

Quote:

Originally Posted by NiLuJe

Also, the actual user content is stored on a vfat partition, and FAT32 is the pits, no matter which way you look at it.

Yeah, but there's a mod around here that lets you mount it as ext 2/3/4, although I think you had to format it outside of the Kobo (I can't remember; it's been a few years, but you could then manually set block size, if you wanted) along with a discussion about it.

I actually had mine running ext4 for a while and was amazed at how much faster it seemed at booting up compared to running fat32 on it, until it was pointed out that it was because it wasn't running any kind of fsck on boot compared to when it was formatted with fat32 (there were some pros and cons though, and my experiences are later in that thread). And of course, if you go this route, you'll no longer be able to mount it under Windows unless you have a Windows ext driver installed (I think). I ultimately switched back to fat32 because at the time, I was regularly switching between Linux and OSX and so wanted to still read it under both. It worked fine, though. If I wasn't OS agnostic, I might have stuck with it.

Owl_ · 02-08-2020, 05:16 PM

Using minitool partition wizard I could only change the cluster size of the FAT32 partition to 128 Kb.
The other partitions cannot be touched o resized (I tried to put unallocated space after and before the partitions, but nothing).

I haven't noticed a performance improvement. I'm wondering if this could be for the bad microSD: I used a normal Kingstone 32GB

DNSB · 02-08-2020, 08:01 PM

You might also want to remember that the Kobo Forma and Aura One with eMMC storage have similar performance to the Clara HD, etc. which use uSD storage. This despite the data sheet for the eMMC showing better performance specs -- 37MBs read, 120MBs write compared to a Sandisk class 10 SD card with it's minimum 10MBs. Individual cards do vary wildly in their speed -- I bought one 3 pack of Sandisk uSD cards and the read speed went from 20MBs to 30Mbs. Using a UHS card will not help since near as I can tell the Kobo ereaders do not support the UHS bus so will fall back to the standard SD bus.

NiLuJe · 02-08-2020, 08:45 PM

Err, my Forma positively *trounces* my H2O as far as storage speed is concerned

.

sherman · 02-08-2020, 09:31 PM

Quote:

Originally Posted by NiLuJe

Err, my Forma positively *trounces* my H2O as far as storage speed is concerned

.

Really?

I got a Forma, and my mum got a Libra recently, and I've found the transfer speed over USB to be waaaaay slower than my H2O, or old Glo.

I chalked it up to slow eMMC and shrugged my shoulders thinking there wasn't anything I could do.

Although, Windows 10 does complain about problems when I connect either reader...

DNSB · 02-08-2020, 09:36 PM

Quote:

Originally Posted by NiLuJe

Err, my Forma positively *trounces* my H2O as far as storage speed is concerned

.

H2O version 1? My testing on a Forma and a Clara HD gives an edge to the Forma GUI but not a massive edge. Loading the same 100 books transferred to the ereader and timing how long the importing screen takes to run gives the Forma about a 10% speed advantage. That may be limited by the Forma being close to full at this time though the size of the database on the Clara HD may also be an issue.

I haven't done testing from the ereader itself. For transferring books to the ereaders, the speed is pretty much the same with (I suspect) the USB interface being the bottleneck. I'm still using an older version of CrystalDiskMark 6 so I can have some consistency with my older tests since CrystalDiskMark7 did quite a few modifications to the tests that makes comparing results a PITA for testing that connection speed.

NiLuJe · 02-08-2020, 11:23 PM

Huh. I don't have hard numbers, but it's *exceedingly* faster at writing stuff at the very least, both on its own or over USB.

It's entirely possible that my (old, original) H2O simply sucks, but then you can also throw every other eReader I own in the same bin ;p.

sherman · 02-08-2020, 11:50 PM

The CrystalDiskMark bench of my Forma is as follows:

Click image for larger version

Name: FormaCDM.png
Views: 180
Size: 19.4 KB
ID: 177024

In real world transfers, I'm lucky to hit 2MB/s writes to my Forma.

My mum's Libra is the same.

I'm wondering if it's an issue with the vfat partition. Windows 10 isn't happy when I plug them in, says there's an issue with the drive, although I never have any errors or problems other than the slow transfer speed.

NiLuJe · 02-09-2020, 11:31 AM

@sherman: That's just nickel bungling the USBMS mount/umount sequence (I would assume) (mainly on devices with an eMMC, for some reason), leaving the dirty bit set.

NiLuJe · 02-09-2020, 12:25 PM

fio would seem to agree with my gut feeling ^^.

(TL;DR: Mostly crappy random read all around, but abysmal random writes on the H2O).

Like I said, the card on my H2O may be on its last leg

.

H2O:

Code:

┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/mnt/onboard/.foo)─┐
└─(0.24:39%:18:15:41%:#)── ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=100m --blocksize=4k --fsync=1 --direct=1 --gtod_reduce=1 --numjobs=1 --group_reporting                                                                                                                                                   ──(Sun, Feb 09)─┘
TEST: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.18-8-g1b5e1
Starting 1 process
TEST: Laying out IO file (1 file / 100MiB)
Jobs: 1 (f=1): [r(1)][28.0%][r=4295KiB/s][r=1073 IOPS][eta 00m:18s]
Jobs: 1 (f=1): [r(1)][50.0%][r=4299KiB/s][r=1074 IOPS][eta 00m:12s] 
Jobs: 1 (f=1): [r(1)][70.8%][r=4338KiB/s][r=1084 IOPS][eta 00m:07s] 
Jobs: 1 (f=1): [r(1)][91.7%][r=4362KiB/s][r=1090 IOPS][eta 00m:02s] 
Jobs: 1 (f=1): [r(1)][100.0%][r=4570KiB/s][r=1142 IOPS][eta 00m:00s]
TEST: (groupid=0, jobs=1): err= 0: pid=9835: Sun Feb  9 18:18:59 2020
  read: IOPS=1091, BW=4364KiB/s (4469kB/s)(100MiB/23463msec)
   bw (  KiB/s): min= 3923, max= 4854, per=99.55%, avg=4344.24, stdev=116.74, samples=46
   iops        : min=  980, max= 1213, avg=1085.33, stdev=29.22, samples=46
  cpu          : usr=1.96%, sys=44.67%, ctx=52513, majf=0, minf=39
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=25600,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=4364KiB/s (4469kB/s), 4364KiB/s-4364KiB/s (4469kB/s-4469kB/s), io=100MiB (105MB), run=23463-23463msec

Disk stats (read/write):
  mmcblk0: ios=25582/0, merge=0/0, ticks=12690/0, in_queue=12550, util=53.42%
- Real: 85987ms User: 1040ms System: 13100ms Percent: 16% Cmd: ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread  MajFault: 7 VolContSw: 29095 InvContSw: 27315 -
┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/mnt/onboard/.foo)─┐
└─(1.54:39%:18:18:41%:#)── ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=100m --blocksize=4k --fsync=1 --direct=1 --gtod_reduce=1 --numjobs=1 --group_reporting                                                                                                                                                  ──(Sun, Feb 09)─┘
TEST: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.18-8-g1b5e1
Starting 1 process
Jobs: 1 (f=1): [w(1)][3.3%][w=545KiB/s][w=136 IOPS][eta 03m:24s]
Jobs: 1 (f=1): [w(1)][5.6%][w=532KiB/s][w=133 IOPS][eta 03m:23s] 
Jobs: 1 (f=1): [w(1)][8.1%][w=526KiB/s][w=131 IOPS][eta 03m:13s] 
Jobs: 1 (f=1): [w(1)][10.6%][w=526KiB/s][w=131 IOPS][eta 03m:06s]
Jobs: 1 (f=1): [w(1)][13.0%][w=499KiB/s][w=124 IOPS][eta 03m:01s] 
Jobs: 1 (f=1): [w(1)][14.9%][w=289KiB/s][w=72 IOPS][eta 03m:03s]  
Jobs: 1 (f=1): [w(1)][16.5%][w=300KiB/s][w=75 IOPS][eta 03m:07s]  
Jobs: 1 (f=1): [w(1)][18.3%][w=496KiB/s][w=124 IOPS][eta 03m:08s]
Jobs: 1 (f=1): [w(1)][19.4%][w=304KiB/s][w=76 IOPS][eta 03m:15s] 
Jobs: 1 (f=1): [w(1)][20.6%][w=187KiB/s][w=46 IOPS][eta 03m:20s] 
Jobs: 1 (f=1): [w(1)][21.4%][w=91KiB/s][w=22 IOPS][eta 03m:29s]  
Jobs: 1 (f=1): [w(1)][23.6%][w=557KiB/s][w=139 IOPS][eta 03m:21s]
Jobs: 1 (f=1): [w(1)][25.8%][w=329KiB/s][w=82 IOPS][eta 03m:13s]  
Jobs: 1 (f=1): [w(1)][28.2%][w=501KiB/s][w=125 IOPS][eta 03m:03s] 
Jobs: 1 (f=1): [w(1)][30.2%][w=238KiB/s][w=59 IOPS][eta 02m:58s]  
Jobs: 1 (f=1): [w(1)][32.7%][w=484KiB/s][w=121 IOPS][eta 02m:49s] 
Jobs: 1 (f=1): [w(1)][34.5%][w=282KiB/s][w=70 IOPS][eta 02m:45s]  
Jobs: 1 (f=1): [w(1)][36.1%][w=391KiB/s][w=97 IOPS][eta 02m:43s] 
Jobs: 1 (f=1): [w(1)][38.0%][w=272KiB/s][w=68 IOPS][eta 02m:38s] 
Jobs: 1 (f=1): [w(1)][39.8%][w=235KiB/s][w=58 IOPS][eta 02m:36s]  
Jobs: 1 (f=1): [w(1)][41.1%][w=242KiB/s][w=60 IOPS][eta 02m:35s] 
Jobs: 1 (f=1): [w(1)][42.2%][w=222KiB/s][w=55 IOPS][eta 02m:35s] 
Jobs: 1 (f=1): [w(1)][43.4%][w=218KiB/s][w=54 IOPS][eta 02m:34s] 
Jobs: 1 (f=1): [w(1)][46.1%][w=469KiB/s][w=117 IOPS][eta 02m:24s] 
Jobs: 1 (f=1): [w(1)][48.3%][w=456KiB/s][w=114 IOPS][eta 02m:17s] 
Jobs: 1 (f=1): [w(1)][50.6%][w=538KiB/s][w=134 IOPS][eta 02m:10s] 
Jobs: 1 (f=1): [w(1)][52.7%][w=528KiB/s][w=132 IOPS][eta 02m:04s] 
Jobs: 1 (f=1): [w(1)][54.8%][w=409KiB/s][w=102 IOPS][eta 01m:58s] 
Jobs: 1 (f=1): [w(1)][56.3%][w=339KiB/s][w=84 IOPS][eta 01m:55s] 
Jobs: 1 (f=1): [w(1)][57.7%][w=142KiB/s][w=35 IOPS][eta 01m:52s] 
Jobs: 1 (f=1): [w(1)][59.4%][w=11KiB/s][w=2 IOPS][eta 01m:48s]    
Jobs: 1 (f=1): [w(1)][60.6%][w=340KiB/s][w=85 IOPS][eta 01m:46s] 
Jobs: 1 (f=1): [w(1)][62.5%][w=373KiB/s][w=93 IOPS][eta 01m:41s] 
Jobs: 1 (f=1): [w(1)][64.1%][w=564KiB/s][w=141 IOPS][eta 01m:37s]
Jobs: 1 (f=1): [w(1)][66.4%][w=483KiB/s][w=120 IOPS][eta 01m:30s]
Jobs: 1 (f=1): [w(1)][68.8%][w=357KiB/s][w=89 IOPS][eta 01m:23s]  
Jobs: 1 (f=1): [w(1)][71.2%][w=523KiB/s][w=130 IOPS][eta 01m:16s] 
Jobs: 1 (f=1): [w(1)][72.8%][w=221KiB/s][w=55 IOPS][eta 01m:12s]  
Jobs: 1 (f=1): [w(1)][74.7%][w=498KiB/s][w=124 IOPS][eta 01m:07s]
Jobs: 1 (f=1): [w(1)][76.1%][w=246KiB/s][w=61 IOPS][eta 01m:04s]  
Jobs: 1 (f=1): [w(1)][77.7%][w=269KiB/s][w=67 IOPS][eta 01m:00s]  
Jobs: 1 (f=1): [w(1)][79.0%][w=316KiB/s][w=79 IOPS][eta 00m:57s] 
Jobs: 1 (f=1): [w(1)][80.2%][w=174KiB/s][w=43 IOPS][eta 00m:54s] 
Jobs: 1 (f=1): [w(1)][82.4%][w=402KiB/s][w=100 IOPS][eta 00m:48s] 
Jobs: 1 (f=1): [w(1)][83.9%][w=234KiB/s][w=58 IOPS][eta 00m:44s] 
Jobs: 1 (f=1): [w(1)][86.0%][w=500KiB/s][w=125 IOPS][eta 00m:38s]
Jobs: 1 (f=1): [w(1)][88.2%][w=230KiB/s][w=57 IOPS][eta 00m:32s]  
Jobs: 1 (f=1): [w(1)][90.0%][w=83KiB/s][w=20 IOPS][eta 00m:27s]   
Jobs: 1 (f=1): [w(1)][91.9%][w=317KiB/s][w=79 IOPS][eta 00m:22s]  
Jobs: 1 (f=1): [w(1)][93.4%][w=284KiB/s][w=71 IOPS][eta 00m:18s] 
Jobs: 1 (f=1): [w(1)][94.9%][w=419KiB/s][w=104 IOPS][eta 00m:14s]
Jobs: 1 (f=1): [w(1)][96.7%][w=253KiB/s][w=63 IOPS][eta 00m:09s]  
Jobs: 1 (f=1): [w(1)][97.5%][w=47KiB/s][w=11 IOPS][eta 00m:07s]  
Jobs: 1 (f=1): [w(1)][98.9%][w=439KiB/s][w=109 IOPS][eta 00m:03s]
Jobs: 1 (f=1): [w(1)][99.6%][w=134KiB/s][w=33 IOPS][eta 00m:01s] 
Jobs: 1 (f=1): [w(1)][100.0%][w=95KiB/s][w=23 IOPS][eta 00m:00s]  
TEST: (groupid=0, jobs=1): err= 0: pid=9840: Sun Feb  9 18:24:05 2020
  write: IOPS=90, BW=363KiB/s (371kB/s)(100MiB/282294msec)
   bw (  KiB/s): min=    7, max=  658, per=100.00%, avg=364.45, stdev=191.77, samples=555
   iops        : min=    1, max=  164, avg=90.68, stdev=48.05, samples=555
  cpu          : usr=0.43%, sys=6.08%, ctx=28458, majf=0, minf=37
  IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,25600,0,25599 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=363KiB/s (371kB/s), 363KiB/s-363KiB/s (371kB/s-371kB/s), io=100MiB (105MB), run=282294-282294msec

Disk stats (read/write):
  mmcblk0: ios=0/25871, merge=0/0, ticks=0/263790, in_queue=263700, util=93.52%
- Real: 282916ms User: 2390ms System: 19820ms Percent: 7% Cmd: ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite MajFault: 9 VolContSw: 51844 InvContSw: 2829 -

Forma:

Code:

┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/mnt/onboard/.foo)─┐
└─(0.22:25%:18:21:94%:#)── ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=100m --blocksize=4k --fsync=1 --direct=1 --gtod_reduce=1 --numjobs=1 --group_reporting                                                                                                                                                   ──(Sun, Feb 09)─┘
TEST: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.18-8-g1b5e1
Starting 1 process
TEST: Laying out IO file (1 file / 100MiB)
fio: cache invalidation of fio-tempfile.dat failed: Function not implemented
fio: cache invalidation of fio-tempfile.dat failed: Function not implemented
Jobs: 1 (f=1): [r(1)][24.1%][r=3661KiB/s][r=915 IOPS][eta 00m:22s]
Jobs: 1 (f=1): [r(1)][40.0%][r=3624KiB/s][r=906 IOPS][eta 00m:18s] 
Jobs: 1 (f=1): [r(1)][56.7%][r=3540KiB/s][r=885 IOPS][eta 00m:13s] 
Jobs: 1 (f=1): [r(1)][75.9%][r=3592KiB/s][r=898 IOPS][eta 00m:07s] 
Jobs: 1 (f=1): [r(1)][93.1%][r=3660KiB/s][r=915 IOPS][eta 00m:02s] 
Jobs: 1 (f=1): [r(1)][100.0%][r=4111KiB/s][r=1027 IOPS][eta 00m:00s]
TEST: (groupid=0, jobs=1): err= 0: pid=2484: Sun Feb  9 18:22:24 2020
  read: IOPS=908, BW=3633KiB/s (3720kB/s)(100MiB/28189msec)
   bw (  KiB/s): min= 3409, max= 4007, per=99.62%, avg=3618.16, stdev=97.61, samples=55
   iops        : min=  852, max= 1001, avg=904.49, stdev=24.36, samples=55
  cpu          : usr=2.45%, sys=45.55%, ctx=64216, majf=0, minf=22
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=25600,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=3633KiB/s (3720kB/s), 3633KiB/s-3633KiB/s (3720kB/s-3720kB/s), io=100MiB (105MB), run=28189-28189msec

Disk stats (read/write):
  mmcblk0: ios=25406/0, merge=0/0, ticks=13470/0, in_queue=13320, util=47.44%
- Real: 47570ms User: 820ms System: 16160ms Percent: 35% Cmd: ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread  MajFault: 0 VolContSw: 38959 InvContSw: 45618 -
┌─(ROOT@(none):pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(/mnt/onboard/.foo)─┐
└─(0.99:26%:18:22:93%:#)── ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=100m --blocksize=4k --fsync=1 --direct=1 --gtod_reduce=1 --numjobs=1 --group_reporting                                                                                                                                                  ──(Sun, Feb 09)─┘
TEST: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.18-8-g1b5e1
Starting 1 process
fio: cache invalidation of fio-tempfile.dat failed: Function not implemented
Jobs: 1 (f=1): [w(1)][3.7%][w=618KiB/s][w=154 IOPS][eta 03m:01s]
Jobs: 1 (f=1): [w(1)][6.6%][w=596KiB/s][w=149 IOPS][eta 02m:50s] 
Jobs: 1 (f=1): [w(1)][9.7%][w=620KiB/s][w=155 IOPS][eta 02m:39s] 
Jobs: 1 (f=1): [w(1)][12.8%][w=646KiB/s][w=161 IOPS][eta 02m:30s] 
Jobs: 1 (f=1): [w(1)][16.0%][w=642KiB/s][w=160 IOPS][eta 02m:22s] 
Jobs: 1 (f=1): [w(1)][19.2%][w=654KiB/s][w=163 IOPS][eta 02m:15s] 
Jobs: 1 (f=1): [w(1)][22.3%][w=646KiB/s][w=161 IOPS][eta 02m:09s] 
Jobs: 1 (f=1): [w(1)][25.0%][w=650KiB/s][w=162 IOPS][eta 02m:06s] 
Jobs: 1 (f=1): [w(1)][28.3%][w=654KiB/s][w=163 IOPS][eta 01m:59s] 
Jobs: 1 (f=1): [w(1)][31.5%][w=670KiB/s][w=167 IOPS][eta 01m:53s] 
Jobs: 1 (f=1): [w(1)][34.8%][w=650KiB/s][w=162 IOPS][eta 01m:47s] 
Jobs: 1 (f=1): [w(1)][38.0%][w=662KiB/s][w=165 IOPS][eta 01m:41s] 
Jobs: 1 (f=1): [w(1)][41.1%][w=638KiB/s][w=159 IOPS][eta 01m:36s] 
Jobs: 1 (f=1): [w(1)][44.4%][w=662KiB/s][w=165 IOPS][eta 01m:30s] 
Jobs: 1 (f=1): [w(1)][47.5%][w=666KiB/s][w=166 IOPS][eta 01m:25s] 
Jobs: 1 (f=1): [w(1)][50.9%][w=646KiB/s][w=161 IOPS][eta 01m:19s] 
Jobs: 1 (f=1): [w(1)][54.0%][w=638KiB/s][w=159 IOPS][eta 01m:14s] 
Jobs: 1 (f=1): [w(1)][57.1%][w=661KiB/s][w=165 IOPS][eta 01m:09s] 
Jobs: 1 (f=1): [w(1)][60.2%][w=646KiB/s][w=161 IOPS][eta 01m:04s] 
Jobs: 1 (f=1): [w(1)][63.4%][w=654KiB/s][w=163 IOPS][eta 00m:59s] 
Jobs: 1 (f=1): [w(1)][66.5%][w=646KiB/s][w=161 IOPS][eta 00m:54s] 
Jobs: 1 (f=1): [w(1)][70.0%][w=654KiB/s][w=163 IOPS][eta 00m:48s] 
Jobs: 1 (f=1): [w(1)][73.1%][w=646KiB/s][w=161 IOPS][eta 00m:43s] 
Jobs: 1 (f=1): [w(1)][76.2%][w=650KiB/s][w=162 IOPS][eta 00m:38s] 
Jobs: 1 (f=1): [w(1)][79.4%][w=654KiB/s][w=163 IOPS][eta 00m:33s] 
Jobs: 1 (f=1): [w(1)][82.5%][w=654KiB/s][w=163 IOPS][eta 00m:28s] 
Jobs: 1 (f=1): [w(1)][86.2%][w=666KiB/s][w=166 IOPS][eta 00m:22s] 
Jobs: 1 (f=1): [w(1)][89.3%][w=666KiB/s][w=166 IOPS][eta 00m:17s] 
Jobs: 1 (f=1): [w(1)][92.5%][w=662KiB/s][w=165 IOPS][eta 00m:12s] 
Jobs: 1 (f=1): [w(1)][95.6%][w=686KiB/s][w=171 IOPS][eta 00m:07s] 
Jobs: 1 (f=1): [w(1)][99.4%][w=709KiB/s][w=177 IOPS][eta 00m:01s] 
Jobs: 1 (f=1): [w(1)][100.0%][w=726KiB/s][w=181 IOPS][eta 00m:00s]
TEST: (groupid=0, jobs=1): err= 0: pid=2490: Sun Feb  9 18:25:22 2020
  write: IOPS=161, BW=648KiB/s (663kB/s)(100MiB/158129msec)
   bw (  KiB/s): min=  459, max=  734, per=100.00%, avg=647.36, stdev=31.89, samples=314
   iops        : min=  114, max=  183, avg=161.37, stdev= 7.97, samples=314
  cpu          : usr=0.75%, sys=9.71%, ctx=53120, majf=0, minf=26
  IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,25600,0,25599 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=648KiB/s (663kB/s), 648KiB/s-648KiB/s (663kB/s-663kB/s), io=100MiB (105MB), run=158129-158129msec

Disk stats (read/write):
  mmcblk0: ios=0/51274, merge=0/0, ticks=0/144530, in_queue=144320, util=91.20%
- Real: 158456ms User: 1580ms System: 17140ms Percent: 11% Cmd: ./fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite MajFault: 0 VolContSw: 67438 InvContSw: 3891 -

01-31-2020, 07:31 AM	#1
Owl_ Enthusiastic reader Posts: 424 Karma: 3880485 Join Date: Mar 2017 Location: Italy Device: Kindle paperwhite3, Kobo aura one, kobo touch 2.0, Kobo Clara HD,Poke2	Improve performance of the micro SD Hi, Anyone knows if it’s possible get better performance of a Kobo Clara HD, formatting his partitions with a bigger allocation unit size? (I know that a big allocation unit size improve the speed of the micro SD) If yes how must I do? (I’ve got windows that doesn’t allow me to see the linux partitions) Last edited by Owl_; 01-31-2020 at 08:07 AM.

02-08-2020, 05:16 PM	#6
Owl_ Enthusiastic reader Posts: 424 Karma: 3880485 Join Date: Mar 2017 Location: Italy Device: Kindle paperwhite3, Kobo aura one, kobo touch 2.0, Kobo Clara HD,Poke2	Last result Using minitool partition wizard I could only change the cluster size of the FAT32 partition to 128 Kb. The other partitions cannot be touched o resized (I tried to put unallocated space after and before the partitions, but nothing). I haven't noticed a performance improvement. I'm wondering if this could be for the bad microSD: I used a normal Kingstone 32GB

02-08-2020, 11:23 PM	#11
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Huh. I don't have hard numbers, but it's exceedingly faster at writing stuff at the very least, both on its own or over USB. It's entirely possible that my (old, original) H2O simply sucks, but then you can also throw every other eReader I own in the same bin ;p. Last edited by NiLuJe; 02-08-2020 at 11:26 PM.

02-08-2020, 11:50 PM	#12
sherman Guru Posts: 875 Karma: 2676800 Join Date: Aug 2008 Location: Taranaki - NZ Device: Kobo Aura H2O, Kobo Forma	The CrystalDiskMark bench of my Forma is as follows: In real world transfers, I'm lucky to hit 2MB/s writes to my Forma. My mum's Libra is the same. I'm wondering if it's an issue with the vfat partition. Windows 10 isn't happy when I plug them in, says there's an issue with the drive, although I never have any errors or problems other than the slow transfer speed.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
stupid question on DR800SG - Micro-A or Micro-B USB?	X. Trapnel	iRex	4	12-01-2015 03:25 AM
Touch Which do you use...micro sd or micro sdhc?	yhamm	Kobo Reader	4	10-11-2011 10:55 AM
Micro SD or Micro SDHC for updating PB360?	Kameli	PocketBook	5	04-15-2011 12:49 AM
Does splitting EPUB among more HTML files improve Performance?	purcelljf	ePub	2	10-01-2010 01:15 AM
HOWTO: Improve performance on calibe generated ePUBs	=X=	Sony Reader	16	06-17-2009 12:15 AM

01-31-2020, 07:20 PM	#3
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Also, the actual user content is stored on a vfat partition, and FAT32 is the pits, no matter which way you look at it.

01-31-2020, 09:33 PM	#4
hobnail Running with scissors Posts: 1,587 Karma: 14328510 Join Date: Nov 2019 Device: none	If you're trying to speed up the initial opening of a book I can sympathize. But I wonder how much of it is due to the SD card versus the slow as molasses CPUs they use in these gizmos.

02-08-2020, 08:01 PM	#7
DNSB Bibliophagist Posts: 46,288 Karma: 169098402 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	You might also want to remember that the Kobo Forma and Aura One with eMMC storage have similar performance to the Clara HD, etc. which use uSD storage. This despite the data sheet for the eMMC showing better performance specs -- 37MBs read, 120MBs write compared to a Sandisk class 10 SD card with it's minimum 10MBs. Individual cards do vary wildly in their speed -- I bought one 3 pack of Sandisk uSD cards and the read speed went from 20MBs to 30Mbs. Using a UHS card will not help since near as I can tell the Kobo ereaders do not support the UHS bus so will fall back to the standard SD bus.

02-08-2020, 08:45 PM	#8
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Err, my Forma positively trounces my H2O as far as storage speed is concerned .

02-09-2020, 11:31 AM	#13
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@sherman: That's just nickel bungling the USBMS mount/umount sequence (I would assume) (mainly on devices with an eMMC, for some reason), leaving the dirty bit set.