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

Reply via email to