On Thu, Jul 31, 2008 at 3:26 PM, Ric Wheeler <rwheeler@xxxxxxxxxx> wrote: > Grant Grundler wrote: ... >> rpm isn't a great gauge of performance either since the perf is a >> function of rpm * bit density. >> > > Is this real rotational latency, or normalized? Sorry... I was thinking throughput (MB/s) and not rotational latency. mkp is right that rotaional latency (ie rpm) is a significant part of total avg latency. > I think that the avg seek > time is usually a bit more predictive of how well we do with the worst case > load (fsck). *nod* .... >> erase and/or write times could be exported as well somehow for SSDs >> if the FS (or other higher layer that wants to know) can't avoid >> garbage collection and erase cycles. I was just told today that flash >> devices >> have 10x higher write time than read time. erase is another order of >> magnitude higher. This doesn't include any garbage collection overhead. >> > > This is changing - they have various ways of getting them much closer > together. On the other hand, a USB flash drive is much slower than a high > end SSD which can hit 20,000 IOPS. The IOPS isn't the issue. It's the difference between having a rotation/seek latency and not. The efficiency (percent of theoretical throughput or IOPS) of either USB stick or enterprise SSD shouldn't be that different if the FS is aware of erase blocks and how it lays out the data. The USB stick will always be slower - the question is efficiency not comparing it to a faster SSD. >> >> I think new file systems should be tuned to work with SSDs before we >> worry so much about the differences between SSDs/flash technologies >> and vendors. And then prescribe a different FS for different >> storage technologies. This avoids the "layering violations" discussion >> and helps keep the FSs (testing and developement) substantially simpler. >> >> grant >> > > If we have access to the parts, we will try to get them to self tune given > whatever we can grab. I'm just pointing out that "self tuning" is more complex, more work, and requires more testing. Ultimately it will take longer to deploy and I don't think we have time for it. Just trying to defer this work until I see substantial evidence of at least one FS that works well with SSDs and can be deployed. I'm not against "self tuning". But I believe sufficiently good results are achievable by directly embedding the device attributes in the FS as we've done for conventional rotational media in ext2. Maybe I'm being too skeptical that developments can't be done in parallel for new features. thanks, grants -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
