In article <31490263-5a8e-411a-bb57-f7fc5cffc...@eis.cs.tu-bs.de>,
J. Hannken-Illjes 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 failure.
>To take some
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 lo
hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") writes:
>On Dec 6, 2012, at 8:32 AM, Michael van Elst 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
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.
>
>
Date: Thu, 6 Dec 2012 08:23:07 +0100
From: "J. Hannken-Illjes"
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 mechanism into my hea
> Looks like this thread is dead. No one beside David Holland is
> interested and David objects. I take back my proposal.
i'm very interested in this idea.
> David wants to track information about threads running a vnode
> operation from vnode_if.c. I have no idea how this could be done
> with
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
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 sit
On Thu, 6 Dec 2012 08:23:07 +0100
"J. Hannken-Illjes" 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!
> David wants forced un
On Dec 6, 2012, at 10:14 AM, Martin Husemann 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 unmounts instead o
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 8:32 AM, Michael van Elst 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 bugs only.
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) ?
--
--
Michael van Elst
Internet: mlel...@serpens.de
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.
Davi
On Dec 4, 2012, at 4:44 PM, David Holland wrote:
> On Sun, Dec 02, 2012 at 05:29:01PM +0100, J. Hannken-Illjes wrote:
> Also I wonder if there's any way to accomplish this that doesn't
> require adding fstrans calls to every operation in every fs.
Not in a clean way. We would n
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 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 ERESTARTVOP.
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 opt
On Nov 29, 2012, at 5:17 PM, David Holland 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 ERESTARTVOP.
>>
>> - Ch
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
On Nov 28, 2012, at 3:59 AM, David Young 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 longer
> wh
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.comU
22 matches
Mail list logo
