From: Dave Chinner <david@fromorbit.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v3] fs: record task name which froze superblock
Date: Tue, 3 Mar 2015 08:33:39 +1100 [thread overview]
Message-ID: <20150302213339.GI18360@dastard> (raw)
In-Reply-To: <20150302043828.GA2516@mguzik>
On Mon, Mar 02, 2015 at 05:38:29AM +0100, Mateusz Guzik wrote:
> On Sun, Mar 01, 2015 at 08:31:26AM +1100, Dave Chinner wrote:
> > On Sat, Feb 28, 2015 at 05:25:57PM +0300, Alexey Dobriyan wrote:
> > > Freezing and thawing are separate system calls, task which is supposed
> > > to thaw filesystem/superblock can disappear due to crash or not thaw
> > > due to a bug. At least record task name (we can't take task_struct
> > > reference) to make support engineer's life easier.
> > >
> > > Hopefully 16 bytes per superblock isn't much.
> > >
> > > TASK_COMM_LEN definition (which is userspace ABI, see prctl(PR_SET_NAME)) is
> > > moved to userspace exported header to not drag sched.h into every fs.h inclusion.
> > >
> > > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >
> > Freeze/thaw can be nested at the block level. That means the
> > sb->s_writers.freeze_comm can point at the wrong process. i.e.
> >
> > Task A Task B
> > freeze_bdev
> > freeze_super
> > freeze_comm = A
> > freeze_bdev
> > .....
> > thaw_bdev
> > <device still frozen>
> > <crash>
> >
> > At this point, the block device will never be unthawed, but
> > the debug field is now pointing to the wrong task. i.e. The debug
> > helper has not recorded the process that is actually causing the
> > problem, and leads us all off on a wild goose chase down the wrong
> > path.
> >
> > IMO, debug code is only useful if it's reliable.....
> >
>
> It can be trivially modified to be very useful to support people.
>
> Actually this patch clears saved task name on unfreeze, so in this
> particular scenario we would end up with no data.
It only clears it i thaw_super(), which is *not called* until the
last nested thaw_bdev() call is made.
When the system is hung what we actually need to know is who is
responsible for *thawing* the filesystem and then we can work out
why that hasn't run. What this code tries to do is identify who
froze the filesystem and so indicate who *might* be responsible for
thawing it. If we mis-identify the agent who holds the freeze
status, then we fail to identify who needs to run the thaw and hence
we're still stuck not knowing WTF happened....
I understand why you want to record this - I'm not arguing that we
shouldn't do this. My point is that we should *make it reliable* and
not in any way ambiguous, otherwise we failed to solve the problem
it was intended for.
Cheers,
Dave.
--
Dave Chinner
david at fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Mateusz Guzik <mguzik@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>, Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
swhiteho@redhat.com, cluster-devel@redhat.com
Subject: Re: [PATCH v3] fs: record task name which froze superblock
Date: Tue, 3 Mar 2015 08:33:39 +1100 [thread overview]
Message-ID: <20150302213339.GI18360@dastard> (raw)
In-Reply-To: <20150302043828.GA2516@mguzik>
On Mon, Mar 02, 2015 at 05:38:29AM +0100, Mateusz Guzik wrote:
> On Sun, Mar 01, 2015 at 08:31:26AM +1100, Dave Chinner wrote:
> > On Sat, Feb 28, 2015 at 05:25:57PM +0300, Alexey Dobriyan wrote:
> > > Freezing and thawing are separate system calls, task which is supposed
> > > to thaw filesystem/superblock can disappear due to crash or not thaw
> > > due to a bug. At least record task name (we can't take task_struct
> > > reference) to make support engineer's life easier.
> > >
> > > Hopefully 16 bytes per superblock isn't much.
> > >
> > > TASK_COMM_LEN definition (which is userspace ABI, see prctl(PR_SET_NAME)) is
> > > moved to userspace exported header to not drag sched.h into every fs.h inclusion.
> > >
> > > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >
> > Freeze/thaw can be nested at the block level. That means the
> > sb->s_writers.freeze_comm can point at the wrong process. i.e.
> >
> > Task A Task B
> > freeze_bdev
> > freeze_super
> > freeze_comm = A
> > freeze_bdev
> > .....
> > thaw_bdev
> > <device still frozen>
> > <crash>
> >
> > At this point, the block device will never be unthawed, but
> > the debug field is now pointing to the wrong task. i.e. The debug
> > helper has not recorded the process that is actually causing the
> > problem, and leads us all off on a wild goose chase down the wrong
> > path.
> >
> > IMO, debug code is only useful if it's reliable.....
> >
>
> It can be trivially modified to be very useful to support people.
>
> Actually this patch clears saved task name on unfreeze, so in this
> particular scenario we would end up with no data.
It only clears it i thaw_super(), which is *not called* until the
last nested thaw_bdev() call is made.
When the system is hung what we actually need to know is who is
responsible for *thawing* the filesystem and then we can work out
why that hasn't run. What this code tries to do is identify who
froze the filesystem and so indicate who *might* be responsible for
thawing it. If we mis-identify the agent who holds the freeze
status, then we fail to identify who needs to run the thaw and hence
we're still stuck not knowing WTF happened....
I understand why you want to record this - I'm not arguing that we
shouldn't do this. My point is that we should *make it reliable* and
not in any way ambiguous, otherwise we failed to solve the problem
it was intended for.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2015-03-02 21:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-14 18:55 [Cluster-devel] [PATCH] fs: record task name which froze superblock Alexey Dobriyan
2015-02-14 18:55 ` Alexey Dobriyan
2015-02-16 9:38 ` [Cluster-devel] " Jan Kara
2015-02-16 9:38 ` Jan Kara
2015-02-18 7:34 ` [Cluster-devel] " Alexey Dobriyan
2015-02-18 7:34 ` Alexey Dobriyan
2015-02-18 7:36 ` [Cluster-devel] [PATCH v2] " Alexey Dobriyan
2015-02-18 7:36 ` Alexey Dobriyan
2015-02-18 9:13 ` [Cluster-devel] [PATCH] " Jan Kara
2015-02-18 9:13 ` Jan Kara
2015-02-18 10:18 ` [Cluster-devel] " Steven Whitehouse
2015-02-18 10:18 ` Steven Whitehouse
2015-02-20 11:42 ` [Cluster-devel] " Alexey Dobriyan
2015-02-20 11:42 ` Alexey Dobriyan
2015-02-20 12:15 ` [Cluster-devel] " Jan Kara
2015-02-20 12:15 ` Jan Kara
2015-02-28 14:22 ` [Cluster-devel] " Alexey Dobriyan
2015-02-28 14:22 ` Alexey Dobriyan
2015-02-28 14:25 ` [Cluster-devel] [PATCH v3] " Alexey Dobriyan
2015-02-28 14:25 ` Alexey Dobriyan
2015-02-28 21:31 ` [Cluster-devel] " Dave Chinner
2015-02-28 21:31 ` Dave Chinner
2015-03-02 4:38 ` [Cluster-devel] " Mateusz Guzik
2015-03-02 4:38 ` Mateusz Guzik
2015-03-02 4:46 ` [Cluster-devel] " Mateusz Guzik
2015-03-02 4:46 ` Mateusz Guzik
2015-03-09 15:14 ` [Cluster-devel] " Alexey Dobriyan
2015-03-09 15:14 ` Alexey Dobriyan
2015-03-02 21:33 ` Dave Chinner [this message]
2015-03-02 21:33 ` Dave Chinner
2015-03-04 15:14 ` [Cluster-devel] " Alexey Dobriyan
2015-03-04 15:14 ` Alexey Dobriyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302213339.GI18360@dastard \
--to=david@fromorbit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.