Followup to: <[EMAIL PROTECTED]>
By author: Alexander Viro <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
>
>
> On Sat, 8 Jul 2000, Khimenko Victor wrote:
>
> > In <[EMAIL PROTECTED]> Daniel Stone ([EMAIL PROTECTED])
>wrote:
> > > Torsten,
> > > I indeed stumbled into the same problem, and it seems to be GRUB's fault.
> >
> > No. It's NOT GRUB's fault.
> >
> > > 0.5.93.1 was working *flawlessly* for me, and then 0.5.94 stuffed up - it
> > > reported installing fine, but on boot, it did not do a thing.
> >
> > Yes. Since you are using 2.4.0 with described bug. GRUB 0.5.94 works
>
> 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.
>
Being able to write the boot block (not superblock!) is key, though,
since Linux doesn't provide any other way to perform that operation.
Genesis also relies on this.
Note that the boot block isn't used by the filesystem itself, at least
not for ext2. It's worse for FAT, since it's boot block and
superblock are co-located, but on the other hand you're much less
likely to have a FAT system you cannot umount.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
