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

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

 



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


[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