Messages in this thread | | | Date | Sun, 14 Oct 2012 11:59:26 +0200 | From | Marco Stornelli <> | Subject | Re: [git pull] vfs pile 3 |
| |
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
| |