Re: [git pull] vfs pile 3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux