http://bugzilla.novell.com/show_bug.cgi?id=223773
http://bugzilla.novell.com/show_bug.cgi?id=223773#c53
--- Comment #53 from L. A. Walsh 2009-11-23 17:44:14 PST ---
The problem is that a 'sync', means that the data is written to disk. XFS does
this this just fine, BUT, it may write meta-data into the journal FIRST, and
later copy the final information into place. XFS guarantees the file is on
disk -- which includes being in the journal, but it doesn't guarantee that the
data is in the final position. This can be the case with ANY journaling or
dynamically optimizing file system.
Grub isn't going through the file-system calls to get to the data, Apparently
it's using "DIRECT I/O" on a mounted file system. Anyone with common sense
would know this is just plain dangerous.
A simple 'sync' won't solve the problem. The only way to guarantee everything
is finalized, is to unmount the file system. Then everything *should* sync
under normal circumstances. IF something goes wrong during unmount, XFS could
be prevented from completing it's play of the journal -- as when happens during
a crash. When the file system is remounted, XFS plays the unfinished portion
of the journal. I don't know the timing of fs availability vs. the journal
being played out, but I was under the _impression_ that the journal is played
out before the fs is made ready for use.
So if it is possible, I'd unmount the boot partition then remount it.
However. Someone else in the thread at
http://oss.sgi.com/archives/xfs/2008-07/msg00031.html, made the comment " the
GRUB shell directly to
write it. grub-install doesn't work reliable." Does the GRUB shell work
through the file system, where maybe grub-install does not?
If that's the case, then maybe using a shell script to feed the GRUB shell
commands might be another possible workaround.
It's unlikely GRUB would work on NTFS either, since while file data is written
to disk, the MFT stays resident in memory and locked until the OS goes down.
To rely on the disk being in a static state while mounted is bad programming
and it should be fixed. It's a 1970's mentality with regard to disks. Now
days you want to touch disk as little as possible and disks are getting more
dynamic as volume managers and shadow copies show different views of disks
(even when synced), than what may exist on disk.
I had this same problem with grub -- it didn't use what the file system said --
it used values on disk that were wrong. It had nothing to do with XFS, but
that at the high level I changed the disk labels, and was booting from a
different partition. So what was mounted in /boot (label=Boot), WASN't what
grub was writing to -- it was writing and updating my old boot partition,
because -- meanwhile, yast2 was happy with writing options to /boot -- which
was the new partition that was really mounted, while grub ignored what was
going on at the high level.
All of that has nothing to do with any particular file system, but again -- has
to do with grub not using the file system, but using it's own block commands.
I've never had a problem with grub interacting badly with my XFS based
boot partition, But I have a *dedicated* partition for boot (it's not on root).
So there's very little I/O happening on /boot other than when I copy a new
kernel to it. After that, it takes very little time for XFS to dump it's
buffers and for the disk to be 'idle' again.
The safest thing to do would be to fix grub to use the file system. Then I
wouldn't have run into my bug (forget the bug# but did log it), which _wasn't_
file system related, but entirely related to grub not using the 'high level
view' of the system and mounted file systems. (While Yast and I were
blissfully modifying boot params on the new /boot partition, which had no
effect on grub whatsoever). I was *lucky*, in that I didn't immediately scrub
the hold partition, my system still booted, just that no changes on the 'live'
file system were being used -- grub was now using an inactive partition to boot
from. That would never happen if their code was written correctly.
IF you can't fix grub, then only way to be safe is unmount the file system, and
remount it. (that or check if the grub-run-from-shell is really using file
system calls to do it's housekeeping, then a script might be a solution).
good luck? :-)
-l
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.