Re: The reason to call it 3.0 is the desktop (was Re: [OT] 2.6 not 3.0 - (NUMA))

[Rob Landley]

On Saturday 12 October 2002 12:14 am, Nick LeRoy wrote:
> On Friday 11 October 2002 03:26 pm, Rob Landley wrote:
> > On Friday 11 October 2002 07:53 pm, Hans Reiser wrote:
>
> <snip>
>
> > A little side project I'm working on now (in my copious free time) is
> > mount point relocation support.  (You can mount the same filesystem a
> > second time in another location (mount --bind makes this easy), and they
> > share a superblock so open files should be happy, but you still can't
> > detach the first mount point.  Not with a hacksaw, or explosives...) 
> > It's more an excuse to learn the new VFS layer than anything else, but
> > it's
> > functionality I would in fact have a use for, strange enough...
>
> Not quite sure that I'm following the _why_ of this one, but maybe I'm just
> slow.

I posted it earlier:

Root filesystem is a loopback mounted zisofs image.  The file to be loopback 
mounted lives in the partition that will become /var.

An initial ramdisk mounts the partition on /initrd/var, calls losetup to 
associate /dev/loop0 with the correct file, and exits to let the boot process 
continue.  The boot process remounts /var in the appropriate place.

/var is now mounted twice.  The initrd can't be released because it's got an 
active mount point under it.  That mount point can't be released because the 
root filesystem is loopback mounted from within it, so it has to stay open.

Logically, the second /var mount should be "mount --move /initrd/var /var", 
followed by "umount /initrd" to free up the initrd memory.  Right now it's 
doing "mount -n --bind /initrd/var /var", because /etc is a symlink into /var 
(has to remain editable, you see), and this way the information about which 
partition var actually is can be kept in one place.  (This is an 
implementation detail: I could have used volume labels instead.)

The point is, right now I can't free the initial ramdisk because it has an 
active mount point under it..

> > I'm also looking for an "unmount --force" option that works on something
> > other than NFS.  Close all active filehandles (the programs using it can
> > just deal with EBADF or whatever), flush the buffers to disk, and
> > unmount. None of this "oh I can't do that, you have a zombie process with
> > an open file...", I want  "guillotine this filesystem pronto, capice?"
> > behavior.
>
> Now _this_ I *like*.  I've wanted this for _a long time_.  Not that I have
> that much spare time, but I'd like to help if I can!

I have no spare time at the moment either (hopefully next week), and I 
started out studying the 2.4 vfs layer which seems a bit different in 2.5 
(can't tell how much yet), but I'll get there...

> > Of course loopback mounts would be kind of upset about this, but to be
> > honest: tough.  The loopback block device gives them an I/O error, and
> > the filesystem should just cope.  Floppies do this all the time with dust
> > and cat hair and stuff...
>
> Yup.  This is required sometimes.  Ever have a CD mounted that the (#$)#
> kernel won't let you umount even though lsof and /proc insist that's
> there's nothing open, but all you can do is an fscking reboot?!!!

Yes.  And some scratched CDs can give REALLY interesting results...

Rob