OK after a bit of rummaging around I found a how-to too get rid of this problem at least temporarily it is fairly simple however I don't have my system set-up with btrfs so I can't confirm this fix.

either comment out or remove this line:

if [ -n ${have_grubenv} ]; then save_env recordfail; fi

or

if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env 

recordfail; fi; fi

in this file

/etc/grub.d/00_header

then run

update-grub

the reason for not editing /boot/grub/grub.cfg directly is that it will be over written every time grub is updated in this case you would only have to "re do" the fix if the grub common packages is updated.

This is the bug on launchpad if you want to add yourself bug #736743

Quoting Colin Watson from the bug report

This is actually a misleading error message: what's happening is that
GRUB's btrfs implementation doesn't implement the file read hook
interface for returning blocklists to calling code. I posted to
grub-devel about this and the upstream maintainer pointed out that,
even aside from multi-device problems, writing to btrfs from GRUB is
fundamentally risky because:

the same block may be used by multiple snapshots every tree
which uses a given block will contain its checksum, and so on
recursively

However, btrfs reserves space at the start for the boot loader. This
space is more than GRUB needs to embed itself, and so we could use 1KB
of it for an environment block.

In any case, this is not a new problem that arose from using
subvolumes, nor does it prevent booting (you get a spurious "Press any
key to continue" prompt, but if you just ignore it it'll boot anyway).
Downgrading to wishlist.

Hope this helps