The solution seems to be counter-intuitive to the problem.
The normal equation usually goes: Larger files get better performance with larger clusters. What happens is that it takes fewer read operations (round-trips to the drive) to read the file - more time is spent actually transferring the data, and less time is spent asking for it. It also (usually) helps reduce file fragmentation, in that each time you reposition the drive head, you get a substantial chunk of the file - at least 32K, as opposed to the possibility of having to reposition the heads every 8K.
Also, the cluster size has no bearing on the application's buffering of data. While the drive reads the full 32K, the application may have only asked for 10K of it (or 1 byte), and it just gets the data it asked for, not the full cluster (unless the application is working at the lowest level for data access - unlikely, but possible).
So under normal circumstances, 32K or even 16K clusters will be more performant for FLAC than 8K or 4K clusters. This is especially true with laptop drives where spindle speeds (latency) and head speeds (seek) are slower than "normal" drives. Since it takes longer to reposition the heads, and longer for the data to "arrive" at the heads as the drive spins, fewer seeks (larger clusters) are the optimal configuration.
However, there may be some odd issues due to smaller caches on the drives, and the way the Phatbox caches/reads ahead that conspire to make all of this moot. This could especially be true with FLAC, where less of the song fills the buffers, so that there is less tollerance for delays in getting data from the disk. If reading the "wasted" data in a larger cluster slows down reading the data from the next song, and all of this is combined with multitasking the player, display, etc., then I could theoretically see a problem with using large clusters.
IMO, if the solution works, then that's great, and good to know. But it's odd that the solution runs counter to what logic would suggest.
