Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocateUAPI

[Ric Wheeler]

On 12/06/2012 08:16 PM, Ingo Molnar wrote:
> * Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> > No, the problem is that the thing is not just a) wrong, but b)
> > only made it in through sneaky ways.
> People disagree with a), and b) only really matters if a) is
> true.
>
> You never gave a technical reason for why protecting against
> future ABI clashes is 'wrong'. It looks like a marginally
> useful, practical patch to me.
>
> Thanks,
>
> 	Ingo

Hi Ingo,

The historical roots of the argument are not quite as clear here as you posit 
above. The need for the interface/ABI itself was the subject of the review.

The interface proposed - expose any deleted data without zeroing it - was 
requested not to enable a tool or fix a specific need. It was proposed in order 
to avoid tripping over an ext4 performance problem that occurs when we change 
allocated-but-unwritten extents into allocated and written.

This is a huge break with very long standing file system semantics - normally, 
we always promise to return to the application only data that you wrote or 
return zeroed blocks of data if you allocated it and did not write it.

This allows you to fallocate all unused space on disk, seek around and poke for 
other peoples' deleted data.  Aside from the obvious violation of expected 
privacy of deleted data (for non-root users at least), it could also break 
things that have the original expectations in place.

After LSF, we did try to reproduce the use case (not with a lot of success) and 
had several proposed ways to fix the ext4 performance challenge instead of using 
this hack to avoid it.

I would prefer to fix the performance issue in ext4 rather than add an interface 
that has no actual users of the actual feature - it exists for applications that 
want to avoid an unfortunate performance hit from something that we could work 
around.

If there are legitimate needs to expose the data to non-root users, it would be 
good to have that debate in the open and clarify the correct interface.

The process issue exposed is not one where "bike shedding" occurred - the 
proposed feature was discussed in person at LSF and on the mailing lists and 
debated and rejected.

Review is part of the way we work as a community and we should figure out how to 
fix our review process so that we can have meaningful results from the review or 
we lose confidence in the process and it makes it much harder to get reviewers 
to spend time reviewing when their reviews are ultimately ignored.

Regards,

Ric




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/