Thanks, once again, pizzar0!
Yes, I know my Kingston's performance isn't great -- I bought it before I knew what I know now. It had reviewed well and was cheap
I'll definitely keep Corsair, Patriot, and Mushkin in mind for future purchases (I've always had an interest in Mushkin for some reason, though never bought any of their products). The good news is that the audience for my documentation (straying from the topic at hand for a bit, sorry!) is mostly joe-blows when it comes to buying flash drives and using them with Porteus. Those who are experts already will probably have little to gain from my rambling drivel.
Thanks also for posting the second PDF -- that one gets to a lot of the issues with flash devices (round hole, square peg with regards to OS's and FS's).
RE: NILFS, maybe I'll try compiling the latest from GIT (hopefully I can compile it against the standard porteus kernel and replace the existing driver, rather than patching and recompiling the whole kernel). I should compile the userland tools while I'm at it -- I think I converted them from a .deb I found. I won't be recommending it for general use until it is more stable and has an fsck function, but I'll definitely be doing some stuff with it in our 'unsupported software' section -- namely, using it as a filesystem for save.dat containers.
RE: the Linaro Flash Card Survey -- I shouldn't speak too much on their behalf, but I believe the goal is not to catalogue each and every flash device. Rather, it is to gain a broader understanding of the hardware that is out there, and then optimize their kernel, OS and FS to handle flash devices better. To that end, I think they can have more success, but you're correct about how quickly the technology changes. So, hopefully their optimizations will be flexible to change with the hardware.
RE: page size/eraseblock size -- I agree that aligning to pages is of primary importance. I did notice faster write speeds in some tests when my drive was aligned on a 4MB multiple vs a 4MB multiple +1MB. I ran each test three times and took the average of the three tests and calculated the standard deviation and coefficient of variation. Though 4MB often scored higher, it primarily did so by less than the coefficient of variation (except for one test that was a little bit more conclusive). Since every page size I've seen can be divided into 1MB, I'll primarily be urging users to align the start of their partitions to a sector that is divisible by 2048. This is likely not perfect, but far better than starting on sector 63 or 'wherever-the-hell-gparted-decides-to-put-it'.
Back to the first .pdf you posted, here are some of my questions related to the slideshow:
In the I/O statistics (1/2), what are we looking at here? Is NILFS so consistently high because of how it writes once and retains old files on disk, and is scoring high in this measure good, bad, or indifferent based on the inherent differences between FS's?
I/O statistics 2/2 -- again, what are we looking at here? Whether or not the FS places data in order, based on the order received?
Case study -ext4 -- what's the ext4-wb stand for?
Case study - btrfs -- I haven't tried it with larger block sizes, but this lines up with some of my experience -- I noticed small performance gains with SSD option (ssd_spread, in my case) and, I tested FAT with the default cluster size and with a 16KB cluster size. The larger cluster size wasted lots of space (~20%) for small files, was slower with small files, and just a tad faster with larger files. Not really worth it.
Case study -xfs -- I got some gains with XFS with barriers disabled, but it still didn't improve it's performance with small files to the point where it came even close to EXT4, BTRFS, or NILFS. Perhaps the effect is exaggerated when you are operating with more channels?
All I have to say about TRIM is that I wish they had it in flash drives, so I could play with it
Again, thank you for all of your helpful information and responses. I could probably go on badgering you with questions all day, but I'll stop here and look for more resources on the web
Posted after 31 minute 45 seconds:
Ok -- rereading the mkfs.nilfs2 man page with a little deeper perspective, I can see where I've not aligned it optimally for my device. It defaults to a 4096 page size and an 8MB allocation unit size. I'm dealing with a 16kb page size (or so I believe) and a 4MB allocation unit size (that one is easier for me to see in the flashbench tests). This is starting to get fun!