On 12/07/2012 04:43 PM, Chris Mason wrote:
On Fri, Dec 07, 2012 at 02:27:43PM -0700, Theodore Ts'o wrote:
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.
True, 7200 RPM disks are slow, but even allowing them to expose stale
data just makes them a little less slow.
I know it's against the rules to pretend that disks don't matter. But
really, once you're doing random IO into a spindle you've given up on
performance anyway.
-chris
That's right.
And equally true, once you have moved the disk heads to that track, you can
write a lot as cheaply as a little (i.e., do 1MB instead of 4KB). That will also
avoid fragmentation of the extents.
I think it would be good to see how much that gets back for us,
Ric
--
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
