Thanks for the explanation, my previous email was quite offtopic, you only
care about partition table and boot sector issues (you don't care at all
about the rest of the fs).
On Sun, 9 Jul 2000, Khimenko Victor wrote:
>can do privileged oprations just fine. If there are NO way to do so
>via /dev/hda1 it'll be acceptable if it's reliable doable via /dev/hda1 at
>least (it'll require quite a lot of changes in GRUB but if it's the only
>choice then...).
Writing through /dev/hda1 instead of /dev/hda when you want to write to
the bootsector of the first partition will fix your problems in 2.2.x and
2.4.x with ext2 (and I guess that's what lilo does just now). It shouldn't
be too hard for you to change this.
But NOTE that the above enterely depends on the filesystem internals and
that's true only on top of ext2 (with other fs that could not be true).
Also if you require the /dev/hda1 to be a 1k blocksize ext2, then you
should be allowed to write through /dev/hda as you're doing now (so in
such case you wouldn't need any change).
>You are NOT installing GRUB (or LiLo) 10 times per minute. No matter how
>costly synchronization is if we have way to force it we are saved.
In ext2, the superblock is cached in buffer cache, thus if you write
through /dev/hda1 you'll just change the buffer that ext2 is taking pinned
for the superblock so it's just synchronized since you'll reach the cache
entity used by ext2.
>mlock will help here, right ?
That's not an issue, ext2 will never touch the first 512bytes of such
buffer, thus you can sleep in between and so on.
The problem in writing to /dev/hda is that you'll go to write to another
buffer (not the one that ext2 is taking pinned for caching the superblock
information, so at the first change of the superblock ext2 will mark dirty
its superblock with the old previous 512byte and your changes will be
discarded as soon as the superblock will be flushed to disk by kupdate...
in a few seconds).
>I'm not know how to hold superblock lock from userspace unfortunatelly :-/
You don't need this because you never read/write in the area where the
filesystem works so what lilo does is just safe in 2.4.x and there are no
possible races (unless you run two grub/lilo at the sime time of course,
but that's again a "don't do that!" ;).
Andrea
-
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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:11 EST