Botond,

Again, I would ask that you take a look at the procedures found here: 

https://help.ubuntu.com/community/DiskPerformance

... and then open another bug, complete with details of kernel version, dstat -D <dev> when doing a "dd if=/dev/zero of=<dev> bs=32k", and then the output of "dmesg | grep usb" so we can see the usb-related messages, etc.  

I just did my own testing, using a 2.6.32-git6 based kernel (so it has a lot of freshly merged ext4 improvements), and what I can see when copying a large file to an Aptiva 2GB USB stick (purchased from Microcenter; identifies as a Sandisk device via lsusb -v), is a slowdown when doing a cp bigfile /mnt, when copying to ext2 and ext3, sometimes to a crawl (4k/second according to dstat), but when a I do dd if=/dev/zero of=/dev/sdc, I see 6MB/sec.  I see the same 6MB/sec while mke2fs is zeroing out the inode table, and if I copy the large file using ext4, I see 6MB/sec (very rarely it drops down to 3-5MB/sec, but only for a second).   When the same USB stick is formatted using vfat, I see a wide range of write bandwidths, from 3-6MB/sec, with an average of maybe 4-5 MB/sec.   My hardware is a Lenovo T400 with 4GB of memory, and the writes to the disk start showing up with dstat after at most a 1 second after I hit the return key to initiate the cp from the shell prompt.

So as you can see, these are very different results than what you have gotten.   I get very similar (although perhaps slightly degraded) results as far as write speends are concerned when I mount the ext2 or ext3 file system using ext4 by the way.  And I can consistently replicate these results, which indicates that at least on my system, raw sequential writes (i.e., via dd if=/dev/zero ...) are 6MB/sec, and using the ext4 file system driver gets me close the same raw sequential write rate, regardless of whether the file system is formatted using ext2, ext3, or ext4 (although things are a bit worse when extents are disabled).   I am getting perhaps 75-80% of the raw write speed when using vfat to a USB stick, consistently over writing a 1GB file to a 2GB USB stick.   With ext2 and ext3, I lost patience before the file copy completed, but after 10 seconds or so with ext2, and perhaps 30 seconds with ext3, the write speeds as reported by dstat -D had dropped down to 4-8 kb/sec, and it would stay there for a few minutes, and then suddenly pop back up to around 3-4 mb/sec, only to later (after some time had passed) drop back down to 4-8 kb/sec.

The bottom line is that everyone is reporting slightly different symptoms, and so opening separate bug reports, with detailed information is the only hope of figuring out what is going on.   I am going to posit that some people are losing because of bad interactions between the kernel and their USB controller (which should show up when they see bad results with raw writes to the device).   Others may be seeing interesting interactions between the write order and size of the writes by a particular file system driver and their particular USB stick.   Depending on the sophistication of the flash controller on the USB stick, the USB stick may handle small (4k) writes much less efficiently than large (64k to 128k) writes, especially if the writes are random access as opposed to sequential in nature.  Note that the requirements for writing large jpegs in a digital camera (what many of the really cheap flash controllers were originally optimized for) are quite different from those needed for a general-purpose file system.

I don't have time to much more in the way of detailed analysis, unfortunately (especially since at least with my USB stick and ext4, things were hunky-dory :-).  If I had the time I would next try a different collection of USB sticks, and different kernels, including the default karmic kernel, to see if my results stayed the same while varying one variable at a time.   That is, doing an exhaustive series of tests following the scientific method, which hopefully most folks learned in their high school science classes.   If someone does have the time to do this work, I'd suggest opening a new bug (since Launchpad is really slow with large bugs, and there's a lot of noise in this bug already), and after you do this large series of tests, with the information I've suggested here and in the Wiki, post a pointer to the new bug in this bug report, and I'll promise to take a look at it.