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! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
