PC-compatible hard drives are subdivided into 512-byte sectors which may be independently written any number of times in arbitrary sequence. The flash memory used by most SD cards, thumb drives, and similar devices is not. Although one can get non-volatile memory chips which are organized in such a fashion, the on-chip circuitry required to handle page writes in arbitrary sequence is more complicated (and thus larger and more expensive) than would be required if write sequences were more restricted.
Typically, a NAND flash chip will be divided into pages of 528 bytes (512+16) each, and those pages will be grouped into blocks which range from 16 blocks each (on e.g. an ancient 2MB chip) to thousands of blocks each (on a multi-gig chip). Each block will generally have two associated restrictions:
Once a page has been written, the entire block containing must be erased before the page can be written again.
Each block may only be written about 10,000 times during the lifetime of the chip (different chips' specified endurance may be an order of magnitude higher or lower)
While it would theoretically possible to have each sector on disk mapped to a fixed page of memory, and have a sector-write request read into a buffer the entire block containing that page, update that sector in the buffer, and then erase the entire block and rewrite it from the buffer, the result would be a horrendously slow "disk" that would be worn out within a few minutes of heavy use. Much better performance and reliability may be obtained if each write request causes the controller to select a blank page and write out the appropriate data along with the sector number and some sort of sequence count (each page of flash has room for 16 bytes of housekeeping information in addition to 512 bytes of data). Each time a sector is written, the page which holds its previous contents will become "garbage"; periodically the system will identify blocks which contain largely "garbage" pages, move all of the data contained in their non-garbage pages to blank pages (making the pages from which the data was copied effectively redundant and thus "garbage"), and then erase the blocks once they contain nothing but garbage.
If all of this sounds complicated, that's because it is. On a small drive, it may be practical to, on power up, examine the "tags" associated with every sector and build a table in RAM that maps all the logical sectors to physical sectors, but on a 32GB drive (64 million sectors), even if one had 256 megs of RAM with which to hold such a table and could populate a million entries per second, populating the table after the drive powered up would take six seconds. Larger drives must thus use other approaches to keep track of their bookkeeping data. In many cases, a controller may keep an up-to-date table in memory and an almost-up-to-date table in flash along with a list of blocks that may be written without updating the latter table (if the flash gets unexpectedly powered down, it will load not-quite-up-to-date table from flash and update it with information from the blocks that were written later). If a controller doesn't have enough RAM to hold the entire map at once, it may sometimes have to write parts of it out to flash and load other parts. If this doesn't happen often, it's no big deal. On the other hand, it's possible for a sufficiently-"random" pattern of disk accesses to result in a lot of extra page-table-flush operations. Even if a controller is capable of reading and writing data quickly, page-table thrashing may slow it down by an order of magnitude.
