grub with xfs /boot
I've previously said that sync didn't seem to fix the problems with the
new /boot/grub directory being invisible to the grub shell, and that you
had to remount it read-only to make it actually write it out, making
sync appear broken on XFS. I've just been chatting with some folks on
#xfs, and I now realise it's not broken at all. It does indeed sync all
the data, and the metadata change is already down in the log, so if you
hit the power button, the log would be replayed, and no data would be
lost - the exact point of a journalling filesystem.
The problem is, when reading the XFS filesystem, the grub shell doesn't
consider the log at all (and nor is it really reasonable for it to -
nothing else is capable of replaying the log in memory!), so the newly
written directory's just not visible. Obviously remounting read-only
flushes the log out, but this is kind of risky to do in a script. A
better approach might be to use xfs_freeze, which makes the filesystem
consistent on disk (including flushing the log) for device-based backups
or snapshots, but without prohibiting writes to the filesystem in the
meantime.
So, if you xfs_freeze the filesystem (and then unfreeze it again) after
writing /boot/grub, /sbin/grub will see the new directory, then it will
all work. Of course, this is a hack, the best solution is to make the
grub shell go through the OS to find the block device offsets when it's
running in simulator mode, in exactly the same way that lilo does, but
in the meantime, it might be good to put into grub-install to get rid of
the requirement to warn people away from xfs /boot, which really does
work just fine.
Regards,
Rob
PS: CC me on replies, not on -boot!
Reply to: