On Fri, Dec 07, 2012 at 01:43:25PM -0700, Theodore Ts'o wrote:On Fri, Dec 07, 2012 at 02:03:06PM -0500, Chris Mason wrote:Grin, we're really good at debating names. But I do see what you mean.That's not what happened though, and the right way forward from here isI don't think that's a good idea, because the current name explicitly
to give the bit to the feature, maybe with a generic name like
FALLOCATE_WITHOUT_BEING_HORRIBLY_SLOW.
calls out the fact that we are making a tradeoff between what
***might*** be a security exposure in some cases (but which might be
perfectly fine in others) for performance. Using the generic name
would hide the fact that this tradeoff is being made, and the
arguments (which I've never seen backed up with a specific design) is
that it's possible to speed up random writes into preallocated space
on a flash device without making any kind of tradeoff that might imply
a security tradeoff.
I'd hope that whatever generic facility we put in doesn't have the
security implications.
If indeed it is possible to speed up this particular workload withoutPersistent trim is what I had in mind, but there are other ideas that do
making any kind of no-hide-stale tradeoff, then we won't need the bit
--- writes into fallocated space will just get faster, with or without
the bit
I am sure it will be possible to do this in some cases (for example if
you have a device that supports persistent trim which can quickly
zeroize the blocks in question), but I would be very surprised if it's
possible to completely eliminate the performance degradation for all
devices and workloads. (Not all storage devices support persistent
trim, just for starters.)
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.
If google wants to have a block device patch that pretends to persistent
trim on devices that can't, great.
In answer's to Linus's question, the reason why people areSo I've always said this was a real performance problem and that it
hyperventilating so badly about this is that in some circles,
revealing stale data is so horrible that anyone who even tries to
suggest this should be excommunicated. The mere existence of the
code, or that people are using it, horribly offends those people.
isn't just limited to ext4. But can we please move past this part? I
don't think it is completely accurate.