On Sat, Oct 13, 2012 at 12:04:55PM -0400, Christoph Hellwig wrote: > On Sat, Oct 13, 2012 at 05:01:15PM +0100, Al Viro wrote: > > You know, I'm in the middle of dealing with one such TODO. Yours, as it > > were. From six years ago. kernel_thread() unexporting. TODO comments > > of any form are routinely shat upon and ignored, especially when shuffled > > away into less read parts of the tree... ;-/ > > > > I'd rather see it done fs-by-fs. Starting with something reasonably easy > > to test - minixfs would do nicely. Don't get me wrong - I'm all for > > burying ->truncate(); what I'm worried about is that we'll end up burying > > the warning about the reasons why vmtruncate() was a bad idea, leaving the > > functionality exactly as it used to be... > > As mentioned I agree with the concern in principle. Let's start by > taking Marco's patches for filesystems that use vmtruncate but don't > actually implement ->truncate. There's a few I remember offhand, e.g. > procfs and ufs right now. Then we can do the actual work required ones > piece by piece. Umm... That would be what, procfs? Frankly, I'm not sure that ATTR_SIZE for procfs actually should not be silently ignored. ->i_size there is completely synthetic - it's not as if truncation would actually change the contents. And ufs situation is quite different - there vmtruncate() is used only on the ->write_begin() side. ->setattr() is already vmtruncate-free. What's needed there is an analog of e.g. ext2_write_failed(). -- 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
