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

[Dave Chinner]

On Wed, Dec 05, 2012 at 12:34:15PM -0500, Theodore Ts'o wrote:
> Because it's the on-disk encoding, when btrfs uses extra bits for its
> btrfs-specific inode flags, it means that I need to avoid using those
> bits in ext4, if it's a flag that needs to also be exposed via
> chattr/lsattr.

What, you mean the ones they posted to -fsdevel for peer review?

http://marc.info/?t=129914133000001&r=1&w=2

> P.S.  The main reason why it would have been better for btrfs
> developers to have consulted me is that they also depend on
> lsattr/chattr, and those programs are part of e2fsprogs.

They did consult you directly, Ted. Here's the header from V2 of the
patch indicating that you are directly cc'd:

  Message-ID: <4D871243.2060001@xxxxxxxxxxxxxx>
  Date: Mon, 21 Mar 2011 16:54:27 +0800
  From: liubo <liubo2009@xxxxxxxxxxxxxx>
  User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
          rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11
          Thunderbird/3.0b2
  MIME-Version: 1.0
  To: Linux Btrfs <linux-btrfs@xxxxxxxxxxxxxxx>
  CC: linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>,
          Andreas Dilger <adilger@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>,
          tytso <tytso@xxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>
  Subject: [PATCH 1/2 v2] Btrfs: add datacow flag in inode flag

Apples and oranges, Ted. You didn't post your change anywhere,
unlike the btrfs guys who did the right thing. Please stop trying to
blame someone else for your actions.

> That being said, you'll note that unlike Dave, I have
> **not** thrown a hissy fit when btrfs grabbed bits from the inode
> field, even though quite a bit more bits allocated for the inode flags
> than the fallocate flags.

IOWs, pointing out that the standard peer review process has been
bypassed is "throwing a hissy fit"? And Linus calls it "being a
pissy bitch". To me this is acknoweldgement of the fact that
something wrong was done, but the actors can't bring themselves to
directly admit it and so are resorting to name calling and
blame-shifting to discredit the messenger and therefore the message.

Or perhaps Linus has given us the go-ahead to push random unreviewed
syscall changes through subsystem trees after holding private
discussions between a handful of developers like has happened here.

Cheers.

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
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/