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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:42 EST