== Remove redundant local zero structure ==

`fs/btrfs/ioctl.c:btrfs_is_empty_uuid()` compares the callers uuid argument with a static array of zeros.  That array should be removed.  The memcmp() can compare the caller's uuid with the kernel's global `ZERO_PAGE`.

Taking it further: make a kernel-wide function that tests whether a given buffer only contains zeros.  There's no reason to bring a buffer of zeros in to the cache for this.  (Maybe such a thing already exists somewhere?)

== pack btrfs structures ==

`pahole` is a program that describes the physical layout of C structures.  Some btrfs structures have unused internal padding because the elements are ordered to create holes.  Run {{{ $ pahole -y btrfs_ fs/btrfs/btrfs.o}}} and look for the XXX comments in the resulting annotated structure definitions to find the holes.  We can discuss possible fixes as needed.

== Use WARN_ON()s return value ==

btrfs contains many instances of the code pattern:

{{{
if (condition) {
    WARN_ON(1);
}}}

This is silly because `WARN_ON()` returns its condition argument specifically so that people can use:
{{{
  if (WARN_ON(condition)) {
}}}
It results in clearer source code and the resulting kernel warning message will output the source code line that contains the condition, not just the `WARN_ON(1)` call.

Many many instances of this can be found with grep.  For example:

{{{
 $ grep -B 1 'WARN_ON(1)' fs/btrfs/*.c | head
fs/btrfs/backref.c-		if (!level) {
fs/btrfs/backref.c:			WARN_ON(1);
}}}

== Use `||` in ref_for_same_block ==

`fs/btrfs/backref.c:fs/btrfs/backref.c()` contains code like:

{{{if (a)
  return 0;
if (b)
  return 0;
if (c)
  return 0;}}}

And so on.  For 6 conditions.  It should be rewritten as 

{{{
if (a || b || c)
  return 0;
}}}
== Implement a core btrfs 'find item' interface ==

This one is more advanced, but I thought I'd throw it out there.

There are many btrfs functions that manually search the tree for an item.  They all reimplement the same mechanism and differ in the conditions that they use to find the item.

`__inode_info()` is one such example.  It wants to set the caller's path to point to the first item in the tree after its specified objectid, type, and offset for which objectid and type match the input.

So a core function should be written that does this and `__inode_info()` should call it.

From there we can start identifying other callers that could use the core item searching function.