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

Nick LeRoy
2002-10-12T04:08:21Z

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'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!

> 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?!!!

Thanks

-Nick