Il 13/10/2012 19:07, Al Viro ha scritto:
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().
I'm open to change the series and give any help. My original idea was to
do a cleanup patch and after that give to each fs maintainer the
possibility to do ad-hoc fix. Each fs maintainer has got a deep
knowledge of its fs so it was a safe approach from testing point of view
and so on. However if you tell me that in this case another approach is
better is ok for me. I'll fix the patches according to the comments of
Christoph.
Regards,
Marco
--
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
