On Tuesday 11 May 2010, [email protected] wrote: > >On a 2gb microSD, 200-300mb of metadata would be quite a fair bit*. > >Has there been any studies on how well btrfs fares on SD cards/eMMC > >type chips? > > > >(*) Not against the selection of btrfs - I use ZFS on my servers > >extensively and it has saved my data on more than one occasion, so I > >understand why btrfs would be useful on mobile devices. > > This kind of "btrfs on SD/eMMC" study sounds like task that someone > could do for us rightaway. Any takers ? ;)
So here are some quick figures from test that looks a bit strange at first, but it's the only way I found to quantify the "user experience" effect of SD/MMC type things. As you might be aware, sd/mmc has a flash translation layer. It's pretty dumb. The erase block size of the underlying flash is pretty huge, 128 - 256k I've been told. The translation layer has a small pool of unused blocks. When you write 4k of data, and then 4k of data somewhere else on the device, here's what I've gathered happens: The FTL reads in the 256k block you wrote to, it marks it as not used. It takes an unused block, erases it, and writes the 256k with your 4k modification to it, and marks it used and updates whatever table it has to map logical addresses to flash addresses. Then the same thing happens for the other 4k write, or it might wait to see if more writes to the same flash block arrive. So obviously, if it's writing 256k for every 4k of logical writes, random writes are going to hurt really really bad. It of course gets frustrating for the user when I/O latency shoots up to 500ms due to random writes.. Considering Intel and others needed big ARM CPUs and 64M+ of RAM on their SSDs to run a decent log-structured filesystem ontop of the flash to get decent random write performance, I wouldn't expect SD/MMC type storage to ever improve. So anyway, my simple test: copy large amounts of small files. And the collection of small files I had around: my 2 gigabyte squid cache spool. Test consisted of a "fast enough PC" and a 1200MHz 512M ram ARM device, the sheevaplug. In the sheevaplug I had a 4 gigabyte class 4 Kingston microSD card. I rsync from the "fast enough PC" to sheeva. It peaks at about 10Mbyte/s doing ssh+rsync. The sequential speed as determined by dd: read: 3959422976 bytes (4.0 GB) copied, 207.743 s, 19.1 MB/s write: 3959422976 bytes (4.0 GB) copied, 865.145 s, 4.6 MB/s Time taken for rsync of 2gbyte of data: ext2: 110m28.319s ext4: 29m42.082s btrfs: 46m36.385s nilfs2: 16m02.786s ext3 was same speed class as ext2. I did these tests some months ago and didn't seem to write down the ext3 results. -o noatime for everything except btrfs where I used -o noatime,ssd_spread,compress Kernel 2.6.32 nilfs2 wins because it writes almost everything out completely sequentially. It probably has pretty dreadful performance on harddrives. LogFS would also be interesting to investigate... _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
