At Wed, 31 Oct 2001 17:45:00 -0800, [EMAIL PROTECTED] wrote: > My check of the code was not thurough, but the loop device seems to > be the culprit, when the "device" is actually a file. There is > no apparent linkage with the way a "sync" is done, so it looks like > a timing problem with the fact that after writing out the blocks, it > would then have to sync that other filesystem again. There is no > transitive closure for stacked devices in Linux right now.
That's likely to be. Perhaps the reason why I didn't notice that Linux didn't do sync well when I used loop devices is that when using a file as a drive in GRUB, it is unnecessary to mount it via a loop device, since GRUB has the command "device", which is more powerful than Linux's loop devices in a sense. > On the other hand, the "remount" option doesn't seem to be a real > fix either. Taking action with the remount option is not required > for all FSes, and it doesn't cause at least XFS to flush it's log. Uggh... :( > This makes me wonder how LILO solves the problem... I'm going to > check to see if they even try to flush the log before checking the > block-map. My guess is not, but it isn't a problem in general > because they're not copying files and then immediately checking the > filesystem structure for those files. I don't think LILO requires filesystems to be flushed, because LILO uses raw devices only if it wants to read/write something from/to boot sectors, not within filesystems. > The sticky point here is that the "grub-install" script unconditionally > insists on copying those files, which puts the metadata for those files > in flight. A (arguably kind of silly) helpful point might be to do a > "cmp" of the source and destination files beforehand and not copy them > if they're the same. This might help you, but I don't think this could be a Saviour for most people, because ordinary users install boot loaders only when they install OSes from scratch. As a solution, three ways can be considered: 1. Wait for a while, hoping that your data is flushed to disks by chance. This is quite easy and immediate. 2. Fix/Improve the implementations of Linux journaling filesystems. This doesn't fix the problem unless you upgrade the kernel. 3. Make a Linux-specific GRUB installer, instead of the grub shell, like grubinst in the time of GRUB 0.4. This sounds too silly for me, but this would solve that kind of problem in the more silly kernel forever. Okuji _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
