The more I think the more I just want to remove forced unmounts.
To take some examples:
- A hard,nointr NFS mount hanging because the server stops responding.
Even if it were possible to use fstrans_ here (and it would become ugly)
it would not help. The root node of the mount will likely be
In article 31490263-5a8e-411a-bb57-f7fc5cffc...@eis.cs.tu-bs.de,
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
The more I think the more I just want to remove forced unmounts.
I think that any operation that cannot be undone (and requires reboot
to be undone) makes the OS less resilient to
hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes:
On Dec 6, 2012, at 8:32 AM, Michael van Elst mlel...@serpens.de wrote:
hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes:
David wants forced unmounts to work even if a thread gets stuck
permanently in a vnode operation.
How can it get
On Dec 6, 2012, at 8:32 AM, Michael van Elst mlel...@serpens.de wrote:
hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) writes:
David wants forced unmounts to work even if a thread gets stuck
permanently in a vnode operation.
How can it get stuck (short of bugs) ?
Here we are talking about
I am interested, but I lack significant vnode clue. So, sorry if answers
are obvious - they are not to me.
About the only situation I ever (and it is almost reproducable at will), in
daily life, wanted to use forced unmounts instead of rebooting a machine (or
before the machine rebooted itself in
On Dec 6, 2012, at 10:14 AM, Martin Husemann mar...@duskware.de wrote:
I am interested, but I lack significant vnode clue. So, sorry if answers
are obvious - they are not to me.
About the only situation I ever (and it is almost reproducable at will), in
daily life, wanted to use forced
On Thu, 6 Dec 2012 08:23:07 +0100
J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
Looks like this thread is dead. No one beside David Holland is
interested and David objects. I take back my proposal.
Have been reading the discussion. Don't assume that no contribution
means no interest!
On Thu, Dec 06, 2012 at 10:32:01AM +, Julian Yon wrote:
I think you could take some inspiration from Linux here: it has a very
handy umount -l which detaches the filesystem from the tree, but defers
the rest of the unmount/cleanup until the fs is no longer busy. This
can help in
On Tue, Dec 04, 2012 at 05:31:59PM +0100, J. Hannken-Illjes wrote:
A suspended fs has the guarantee that no other thread will be inside
fstrans_suspend / fstrans_done of any vnode operation.
Threads stuck permanently as in (c) are impossible to catch.
...doesn't that mean the
Date: Thu, 6 Dec 2012 08:23:07 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
Looks like this thread is dead. No one beside David Holland is
interested and David objects. I take back my proposal.
I'm interested, but I haven't fit enough of the vnode life cycle or
the fstrans
hi,
Forced unmounts will most likely panic the kernel. The main problem is
other threads running a vnode operation when we come to clean and
reclaim an active vnode and therefore change its operation vector and
destroy the file system private data without locking or synchronisation.
One
Looks like this thread is dead. No one beside David Holland is
interested and David objects. I take back my proposal.
David wants to track information about threads running a vnode
operation from vnode_if.c. I have no idea how this could be done
without knowing file system implementation.
On Sun, Dec 02, 2012 at 05:29:01PM +0100, J. Hannken-Illjes wrote:
I'm convinced -- having fstrans_start() return ERESTART is the way to go.
Ok then :-)
Also I wonder if there's any way to accomplish this that doesn't
require adding fstrans calls to every operation in every fs.
On Dec 2, 2012, at 5:00 AM, David Holland dholland-t...@netbsd.org wrote:
On Thu, Nov 29, 2012 at 06:19:37PM +0100, J. Hannken-Illjes wrote:
In short the attached diff:
- Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
restart a vnode operation once it returns
On Thu, Nov 29, 2012 at 06:19:37PM +0100, J. Hannken-Illjes wrote:
In short the attached diff:
- Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
restart a vnode operation once it returns ERESTARTVOP.
- Changes fstrans_start() to take an optional `hint
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
In short the attached diff:
- Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
restart a vnode operation once it returns ERESTARTVOP.
- Changes fstrans_start() to take an optional `hint vnode' and
On Nov 29, 2012, at 5:17 PM, David Holland dholland-t...@netbsd.org wrote:
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
In short the attached diff:
- Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
restart a vnode operation once it returns
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
Comments or objections?
I'm wondering if this will fix the bugs in 'mount -u -r /xyz' where a
FFS is mounted read-write at /xyz? Sorry, I don't remember any longer
what the bugs were.
Dave
--
David Young
dyo...@pobox.com
On Nov 28, 2012, at 3:59 AM, David Young dyo...@pobox.com wrote:
On Mon, Nov 26, 2012 at 03:06:34PM +0100, J. Hannken-Illjes wrote:
Comments or objections?
I'm wondering if this will fix the bugs in 'mount -u -r /xyz' where a
FFS is mounted read-write at /xyz? Sorry, I don't remember any
19 matches
Mail list logo
