From: Boris Gjenero <boris.gjenero_at_gmail.com>
Date: Sat, 25 Apr 2015 09:11:35 -0400

Occasionally I use text_editor to take notes on my 5G 30GB iPod. This
has always worked well in the past with the stock MK3008GAL hard drive.
(BTW I recommend opti2.kbd
http://www.rockbox.org/wiki/LoadableKeyboardLayouts ) Recently I
upgraded to a HS12YHA, which is 120GB with 4k sectors.

I was playing WMA. When I saved in text_editor, creating a new file, it
seemed to hang. The wait was long enough that I reset the iPod, leaving
a 0 length file. Then I tried again, also playing WMA and waiting longer
and it worked. This made me think that Rockbox took a long time to look
through the FAT because the drive was mostly full and free space was
toward the end.

Specific conditions are needed to reproduce this. FAT32 has an fsinfo
sector with a hint value telling where the first free cluster should be
located. Rockbox makes use of this, allowing fast cluster allocation.
After mounting the iPod in Windows, the free space hint was 0x1da2. Then
I played that same WMA album, and reproduced the problem. The free space
hint was now 0x321da2, showing that Rockbox must have scanned though
many clusters in the FAT. Here is sudo dd if=/dev/sdb2 bs=512 count=1
skip=1 | hexdump -C
00000000 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00
|RRaA............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
000001e0 00 00 00 00 72 72 41 61 0a a2 05 00 a2 1d 32 00
|....rrAa......2.|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
|..............U.|
00000200

This gave me the idea to cache the FAT in dircache. If the drive isn't
terribly fragmented, the FAT information would take less space than the
file names. Assuming you store start cluster and chain length for each
contiguous chunk and 32 bit values are used, an unfragmented file would
need 8 bytes. Free space could be stored as another file. Space that's
marked bad or otherwise reserved would not need to be stored. With this,
buffering would only have to read file data. I didn't try to implement
this yet; I'm just wondering what others think about this idea.

When I tried to reproduce without playback being active, I could see
file creation taking longer but it wasn't ridiculous. I guess this is
because Rockbox will boost if necessary for proper playback without
breaks, but other stuff might not get much CPU time. I've never had a
problem with this before though.

I'm also wondering about why the free space hint was set to 0x1da2 in
Windows and 0x321da2 in Rockbox. Does something have a bug causing it to
write only 16 bits of the hint value, or do I have a crazy coincidence
of free space locations?

Finally, I'd like to apologize for disappearing the way I did in the
past. I got myself hung up on details worrying about what others would
think of various possible solutions. It became unpleasant and killed my
motivation to continue. This is my problem; I'm not blaming anyone else
for causing this.

I have posted my TCC780 RCA RC3000A port at
https://github.com/dreamlayers/rockbox/tree/rc3000a . I have no plans to
work toward committing that, because nobody else seems interested in it,
so I don't see how it would benefit Rockbox. In other words, I don't
want to commit a port that only I am going to run.

Best regards,

Boris
Received on 2015-04-25