simple explaination, the access pattern in the ipod is very bursty-large buffer, and on the original filesystem the directory entries are stored in such a way that a large number of them could be read in core with a single read call [17:25] most likely an entire dir would be read and dereferenced in a single read call for the entire directory [17:26] on FAT this isn't true, the cluster sizes are obcenely small and you have to dereference/seek/read through a linked list of directory entries to read the smallest directory [17:26] well, any extra level means a different dirent, so it would mean another level of indirection and a new seek to get to it [17:27] you have to wait for the disk to spin around again to read the new track... [17:28] the longer the file name the larger the directory entry, up to a certain size, then a new cluster/inode/what have you is created to hold the overflow, then you have the extra indirection (like on fat) and you lose some efficiency [17:28] frankly since they called in back up and obviously thought i was a tosser, i dont feel they need to know, since they obviously dont know about the filesystems or low power use of magnetic media already :] [17:29] also on the old fs files tend to cluster around their directory entries [17:30] not that they're enumerating directories all the time, it's not, but they pair well when they do have to read them and they're slurping up a few minutes of mp3 too [17:30] i'm certain they would continue, it's fruitless [17:31] when the one even mentioned "running both cores at a lower frequency" i knew he had no clue about low power design :[ [17:31] or his compatriots for that matter, whoever thought that was a useful scenario for COP usage [17:32] another reason the short file names are faster on fat32 is the extra look-aside for the long file names, if they're longer than 8.3, they have ANOTHER dirent (and as you can imagine the fragmentation of one, 2 related of different sizes, paired together, does not fast access make) [17:33] not that the ipod is particularly concerned about the long file name portion, but it is disk overhead and it does make the dirents larger