On Tue, Jun 26, 2012 at 02:21:24PM -0400, Ric Wheeler wrote: > > It would be interesting to see if simply not doing the preallocation > would be easier and safer. Better yet, figure out how to leverage > trim commands to safely allow us to preallocate and not expose other > users' data (and not have to mark the extents as allocated but not > written). TRIM is applicable to SSD's and enterprise storage arrays. It's not applicable HDD's. > This is not a theory guy worry. I would not use any server/web > service that knowingly enabled this hack in a multi-user machine and > would not enable it for any enterprise customers. Sure, but for single-user or for dedicated cluster file system server, it makes sense; it's not not going to be useful for all customers, sure, but for some customers it will make sense. > We should be very, very careful not to strip away the usefulness of > file system just to cater to some users. A mount option or a superblock flag does not "strip away the usefulness of the file system". It makes it more useful for some use cases. Your alternate proposals (preinitializing the space with zeros, using trim, writing larger chunks) will work for some use cases, certainly. But it's not going to be sufficient for at least some use cases, or they will simply not work. Fundamentally it sounds to me the biggest problem is that you don't trust your customers, and so you're afraid people will use the no-hide-stale feature if it becomes available, even if it's not needed or if it's needed but you're afraid that they don't understand the security tradeoffs. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
