On Fri, 9 Mar 2001, Alexander Viro wrote:
> On Fri, 9 Mar 2001, Mike Galbraith wrote:
>
> > I think I've figured it out.. at least I've found a way to reproduce
> > the exact errors to the last detail and some pretty nasty corruption
> > to go with it. The operator must help though.. a lot ;-)
> >
> > If you do mount -o remount /dev/somedisk / thinking that that will get
> > rid of your /dev/ram0 root, that isn't the case, and you will corrupt
> > the device you remounted (I did it to a scratch monkey) very badly when
> > you write to the still mounted ramdisk.
>
> Ugh. mount -o remount ignores dev_name argument. It will change the
Ah.. didn't know that.
> flags of fs mounted from /dev/ram0 and will not even touch a /dev/somedisk.
> If you write to device you have mounted... Well, don't expect it to be pretty.
I knew the ramdisk would be history :) It munged the disk though too.
> > You must exec a shell (or something) chrooted to your mounted harddisk
> > to un-busy the old root and then pivot_root/unmount that old root. I
> > tested this, and all is well.
> >
> > I think this is a consequence of the multiple mount changes.. not sure.
> > (ergo cc to Al Viro.. he knows eeeeverything about mount points)
>
> I _really_ doubt that it has anything to multiple mounts. mount -o remount
> never unmounts anything. Never did. The rest is an obvious result - you
> leave fs mounted, you do direct write to its device, you see it fucked.
> The fact that it is a root doesn't matter. Relevant part of manpage:
I started imagining a possible connection when I saw two root entries
in proc/mounts.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
