lkml.org 
[lkml]   [2012]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-10-14 12:41    [W:0.045 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site