On Thu, Mar 11, 2010 at 06:35:06PM +0100, Stephan von Krawczynski wrote: > On Thu, 11 Mar 2010 15:39:05 +0100 > Sander <sander@xxxxxxxxxxx> wrote: > > > Stephan von Krawczynski wrote (ao): > > > Honestly I would just drop the idea of an SSD option simply because the > > > vendors implement all kinds of neat strategies in their devices. So in the end > > > you cannot really tell if the option does something constructive and not > > > destructive in combination with a SSD controller. > > > > My understanding of the ssd mount option is also that the fs doens't try > > to do all kinds of smart (and potential expensive) things which make > > sense for rotating media to reduce seeks and the like. > > > > Sander > > Such an optimization sounds valid on first sight. But re-think closely: how > does the fs really know about seeks needed during some operation? Well the FS makes a few assumptions (in the nonssd case). First it assumes the storage is not a memory device. If things would fit in memory we wouldn't need filesytems in the first place. Then it assumes that adjacent blocks are cheap to read and blocks that are far away are expensive to read. Given expensive raid controllers, cache, and everything else, you're correct that sometimes this assumption is wrong. But, on average seeking hurts. Really a lot. We try to organize files such that files that are likely to be read together are found together on disk. Btrfs is fairly good at this during file creation and not as good as ext*/xfs as files over overwritten and modified again and again (due to cow). If you turn mount -o ssd on for your drive and do a test, you might not notice much difference right away. ssds tend to be pretty good right out of the box. Over time it tends to help, but it is a very hard thing to benchmark in general. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
