On Fri, Dec 07, 2012 at 04:09:32PM -0500, Chris Mason wrote: > Persistent trim is what I had in mind, but there are other ideas that do > imply a change in behavior as well. Can we safely assume this feature > won't matter on spinning media? New features like persistent > trim do make it much easier to solve securely, and using a bit for it > means we can toss back an error to the app if the underlying storage > isn't safe. We originally implemented no hide stale for spinning media. Some folks have claimed that for XFS their superior technology means that no hide stale doesn't buy them anything for HDD's. I'm not entirely sure I buy this, since if you need to update metadata, it means at least one extra seek for each random write into 4k preallocated space, and 7200 RPM disks only have about 200 seeks per second. One of the problems that I've seen is that as disks get bigger, the number of seeks per second have remained constant, and so an application which required N TB spread out over a large number of disks might now only require a fraction of the number of disks --- so it's very easy for a cluster file system to become seek constrained by the number of spindles that you have, and not capacity constrained. This to me seems to be a fundamental problem, and I don't think it's possible to wave one's hands to get rid of it. All you can say is that the people who care about this are crazy (that's OK, I don't mind when Christoph or Dave call me crazy :-), and that their workload doesn't matter. But if you are trying to optimize out every last seek, because you desperately care about latency and seeks are a precious and scarce resource[1], then I don't see around away the technique of not requiring an update to the metadata at the time that you write the data block, and that kinda implies no-hide-stale. Regards, - Ted [1] Even if you don't care about the latency of the write operation, the fact that the write operation has to do two seeks and not one can very well slow down a subsequent high priority read request, where you *do* care about latency. The problem is that you only have about 200 seeks per spindle. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
