Chris Mason wrote:
On Fri, 2008-11-07 at 10:18 -0600, James Bottomley wrote:
On Fri, 2008-11-07 at 11:11 -0500, Chris Mason wrote:
[ complex trim management code ]
It doesn't seem like a good idea to maintain a ton of code that gets
exercised so rarely, especially wrt filesystem crashes.
Heh, am I the only person here who deletes files on a regular basis
(principally to get my disk down from 99%)?
Using it is easy, but the failure case is the storage forgets about a
block the FS cares about, so actually testing the code means we have to
test all the blocks allocated to the FS to make sure they have the
correct values. Given remapping and everything else we've talked about,
any block in the FS could become corrupt due to a trim bug on block X.
I don't think that trim bugs should be that common - we just have to be
very careful never to send down a trim for any uncommitted block.
On write any unmapped (trimmed) sector becomes mapped again.
So, trim bugs will look like a dozen other bugs, and they may not get
reported for months after the actual bug was triggered (all things I
know you already know ;)
I think the bar for keeping it simple is much higher here than in other
parts of the storage stack.
-chris
Simple is always good, but I still think that the coalescing (even basic
coalescing) will be a critical performance feature.
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
