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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
