I'm not saying that other OS'es (*BSD) aren't in this respect since I haven't tried, but here goes my annoyance.
I'm developing a kernel bootable by grub. The floppy image file is formatted to FAT32 and mounted on some directory. When I want to test a new version of the kernel, I copy the kernel executable file to the directory where the floppy image is mounted and run bochs. However, the change is not propagated to the underlying floppy image file! Bochs still runs the old kernel version. I have to explicitly type "sync" in order for the change to be flushed to the floppy image file.
Doesn't linux globally maintain data consistency? Are its FS buffers per filesystem? Why is it done in such a stupid way?
skip to main |
skip to sidebar
This is the repository of my wild thoughts, general comments and ideas that I don't have the time to actually work on.
5 comments:
I assume that you've copied the file to floppy and haven't umounted - and neither waited for VFS to do its periodic sync and used Bochs to do a raw-device read?
Yes, "raw device" in this case being an ordinary file loop mounted.
Maintaining data consistency leads to synchronous disk operation, synchronous disk operation leads
to slower disk writes, slower disk
writes leads to frustrated users,
frustrated users leads to WinXP market percentage rising. Sync is a path
to the dark side...
I've recently worked on bootable
floppy image with frequent testing
in Bochs, and I've come up with a
very small shell script to automate
it for me. Here's an excerpt:
sudo mount -o loop bootdisk.img /tmp/.l4img
sudo cp -R bootdisk-data/* /tmp/.l4img
sudo umount bootdisk.img
This way, I'm always working only
in bootdisk-data directory, and
syncing with boot image just before
I run QEMU.
No, it doesn't lead to synchronous disk operations. It leads to duplicated memory usage as the kernel, obviously, has different buffers for 1) the file system containing the image file, and 2) the mounted image file. So when I change something in 2), the kernel doesn't realize that 1) should also be changed (i.e. consistency is not maintained.. there are two copies of the same data in RAM).
No synchronous disk writes are required, just a smarter buffer handling code.
But raw access and FS access are rather *different* in nature and I really wouldn't object on such behaviour as it is well known and documented. I doubt that other Unices appear different in this case.
I somehow doubt that raw-device and FS buffers can be easily unified - and I'm curious if you have found other Unices to have such feature? Mixing raw and mounted calls for trouble.
Post a Comment