Messages in this thread | | | Date | Sun, 9 Jul 2000 10:42:44 +0300 | From | Nimrod Zimerman <> | Subject | Re: linux-2.4.0 breaks grub install into partition |
| |
Hello.
On Sat, Jul 08, 2000 at 08:48:02PM -0400, Alexander Viro wrote:
> > No. It's NOT GRUB's fault.
> No, since you are using the functionality that was never promised to be > there. Example: fs has a perfect right to copy superblock out of the > buffer cache and slam it back whenever it wants, completely ignoring any > changes you've done to buffer cache. Or to keep it in pagecache and don't > have buffer heads hashed. You are _not_ supposed to bypass r/w filesystem > - it has absolute access to the device and that's the end of the story. So > the problem is not just partition vs. disk caches. You have no right to > expect any sort of behaviour from write access to fs mounted read/write. > It's on the mercy of _many_ things, starting with fs itself.
The problem is that this behavior is also evident on unmounted partitions, and it can bite unsuspecting people working with such raw devices for legitimate purposes, such as setting them up. If /dev/hda1 isn't to be accessed from /dev/hda, maybe the kernel should enforce that, or this should be clearly documented somewhere (which is hard). Otherwise, the cache isn't coherent, which is not fun.
To reproduce (with 2.2.14) - /dev/hda is a completely idle, unmounted and unaccessed IDE device on my system, with a single primary partition spanning the entire disk.
dd if=/dev/hda1 skip=100 bs=512 count=1 of=hda1.sector.original dd if=/dev/hda skip=163 bs=512 count=1 of=hda.sector.original
dd if=junk.sector of=/dev/hda1 conv=notrunc seek=100 bs=512 count=1
dd if=/dev/hda1 skip=100 bs=512 count=1 of=hda1.sector dd if=/dev/hda skip=163 bs=512 count=1 of=hda.sector
hda1.sector and hda.sector wouldn't be equal, at this point. After clearing the cache ('dd if=/dev/hdb of=/dev/null ...') and rereading the sectors, the two would be identical.
(Obviously, I'm assuming my personal disk geometry here. As presented above, data-loss would occur. Don't try this at home!).
Nimrod
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |