[Bug 736743] Re: environment block not implemented on btrfs

[Luiz Angelo Daros de Luca]

* grub does not write to btrfs because of its checksum/cow stuff.
* btrfs is aware but doesn't seems to care as it says on its FAQ: "grub needs btrfs to support a reserved area" (and not "btrfs needs to implement reserved area")
* ubuntu is hit by this problem for years but it is something for either grub or btrfs to solve.

I love this "Somebody else's problem" way to deal with complicated
problems...

Both grub and btrfs devs seems to not want to fix this problem by
themselves as it is not a problem that hit them directly. Only distros
that glue them together that face this problem. So, a distro or a
"volunteer expert devel user" (that's not me) might be the one that
proposes the fix.

SLES and OpenSuSE already uses btrfs rootfs for some time. Does it mean
that grub-once simply does not work with them (and they are fine with
it)?

I'm no Btrfs nor grub specialist but it is difficult to understand why
is to difficult to write 1k from grub in today's multi TB disks...

Thinking about btrfs:

Btrfs already support nodatacow for a single file (chattr +C). Probably
this is not enough but a little more might be.

If nodatacow files does not use checksum, one more problem is solved. If
not, maybe it is the case to implement a "chattr +K" for "disable
checksum for file". Some metadata like ctime/mtime would be out-of-sync
but this is a minor issue.

For snapshots, it deals with nodatacow file doing a one-time cow (it
increases the reference count). Again, a new "chattr +n" for "duplicate
file blocks on snapshot" would keep the file block dedicated for that
"copy" (duplicating data). An alternative would be grub checking the
"reference count" of grubenv and avoid a write if >1. In a "best
effort", ubuntu should duplicate the grubenv file whenever its
"reference count" is >1 on shutdown.

Maybe all too complicated...

Thinking about grub:

In old disk format, where the first partition starts at sector 63, I
guess it is already difficult to have btrfs support in grub. The last
time I tried, it failed to write all needed modules. So, writing to
btrfs is the last problem to deal as there is no space even for reading
btrfs. For new partitions, grub has plenty of space as the first
partition starts at sector 2048. In this case, grub do have a spare 1k
in 1M of space. So, load_env could accept an alternative storage
location based on blocks or just after the last module. This might be
easier than write to any FS out there. The only problem is that grub-
editenv would need to write directly to the block device. This solution
is ideal as it might solve all FS write problems related to load_env
(and not only for btrfs).

And, for the record, include me in the "me too"s list of affected
people.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/736743

Title:
  environment block not implemented on btrfs

Status in grub:
  New
Status in grub2 package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: grub2

  I just installed natty alpha 3 on a samsung NC10 netbook. When booting, immediately after the grub screen I see the error message:
  'sparse file not allowed. 
  press any key to continue'
  after pressing any key the boot continues as normal.

  This is with btrfs on / and a separate ext4 partition for /home. I had
  created the btrfs partition manually (i.e. in a shell outside
  ubiquity) simply running mkfs.btrfs /dev/sda1 and it was not
  reformatted in ubiquity.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: grub-pc 1.99~rc1-4ubuntu1
  ProcVersionSignature: Ubuntu 2.6.38-6.34-generic 2.6.38-rc7
  Uname: Linux 2.6.38-6-generic i686
  Architecture: i386
  Date: Thu Mar 17 11:14:52 2011
  EcryptfsInUse: Yes
  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110302)
  ProcEnviron:
   LANGUAGE=en_GB:en
   LANG=en_US.UTF-8
   LC_MESSAGES=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: grub2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/grub/+bug/736743/+subscriptions