Comment 13 for bug 633686

The "fix" that needs to be done is likely this:

RPM goes to some lengths to ensure that installs (on hard disks)
are high performing.

Specific to the "install" data reported, RPM attempts to decompress
files directly onto the file system using am mmap(2) allocation
buffer for 1 decompression operation for the _ENTIRE_ file,
and also has some addition speedup's to trigger "write behind"
I/O onto a hard disk using madvise(2) MADV_DONTNEED.

I suspect that what is the root cause of S-L-O-O-W RPM is that
the hard disk optimizations don't "work" on flash file systems
because mmap(2) and madvise(2) almost certainly have a dramatically
different implementation.

Lucklly lib/fsm.c already is insturmenetd to just write buffers to
the file system, the "good old way" if/when mmap(2) isn't available
or otherwise fails to "work". The "fix" should _NOT_ be to just
rip out the mmap(2) optimazations which re/were significant.

(don't worry if all of the above is meaningless. my role here is to analyze your
data and suggest the "fix" for RPM.)