On Sat, Oct 19, 2013 at 07:59:55PM +0900, Akira Hayakawa wrote:
> Dave,
>
> # -EIO retuned corrupts XFS
> I turned up
> lockdep, frame pointer, xfs debug
> and also changed to 3.12.0-rc5 from rc1.
>
> What's changed is that
> the problem we discussed in previous mails
> *never* reproduce.
>
>
On Sat, Oct 19, 2013 at 07:59:55PM +0900, Akira Hayakawa wrote:
Dave,
# -EIO retuned corrupts XFS
I turned up
lockdep, frame pointer, xfs debug
and also changed to 3.12.0-rc5 from rc1.
What's changed is that
the problem we discussed in previous mails
*never* reproduce.
However, if I
Dave,
# -EIO retuned corrupts XFS
I turned up
lockdep, frame pointer, xfs debug
and also changed to 3.12.0-rc5 from rc1.
What's changed is that
the problem we discussed in previous mails
*never* reproduce.
However, if I turn off the lockdep only
it hangs up by setting blockup to 1 and then to 0
Dave,
# -EIO retuned corrupts XFS
I turned up
lockdep, frame pointer, xfs debug
and also changed to 3.12.0-rc5 from rc1.
What's changed is that
the problem we discussed in previous mails
*never* reproduce.
However, if I turn off the lockdep only
it hangs up by setting blockup to 1 and then to 0
On Wed, Oct 16, 2013 at 09:17:40PM +0900, Akira Hayakawa wrote:
> Dave
>
> > XFS shuts down because you've returned EIO to a log IO. That's a
> > fatal error. If you do the same to an ext4 journal write, it will do
> > the equivalent of shut down (e.g. complain and turn read-only).
> You mean
Dave
> XFS shuts down because you've returned EIO to a log IO. That's a
> fatal error. If you do the same to an ext4 journal write, it will do
> the equivalent of shut down (e.g. complain and turn read-only).
You mean block device should not return -EIO anyway if
it doesn't want XFS to suddenly
On Wed, Oct 16, 2013 at 07:34:38PM +0900, Akira Hayakawa wrote:
> Dave
>
> > Akira, can you please post the entire set of messages you are
> > getting when XFS showing problems? That way I can try to confirm
> > whether it's a regression in XFS or something else.
>
> Environment:
> - The kernel
Dave
> Akira, can you please post the entire set of messages you are
> getting when XFS showing problems? That way I can try to confirm
> whether it's a regression in XFS or something else.
Environment:
- The kernel version is 3.12-rc1
- The debuggee is a KVM virtual machine equipped with 8
[cc x...@oss.sgi.com]
On Tue, Oct 15, 2013 at 08:01:45PM -0400, Mikulas Patocka wrote:
> On Mon, 14 Oct 2013, Akira Hayakawa wrote:
> > But, XFS stalls ...
> > ---
> > For testing,
> > I manually turns `blockup` to 1
> > when compiling Ruby is in progress
> > on XFS on a
[cc x...@oss.sgi.com]
On Tue, Oct 15, 2013 at 08:01:45PM -0400, Mikulas Patocka wrote:
On Mon, 14 Oct 2013, Akira Hayakawa wrote:
But, XFS stalls ...
---
For testing,
I manually turns `blockup` to 1
when compiling Ruby is in progress
on XFS on a writeboost device.
Dave
Akira, can you please post the entire set of messages you are
getting when XFS showing problems? That way I can try to confirm
whether it's a regression in XFS or something else.
Environment:
- The kernel version is 3.12-rc1
- The debuggee is a KVM virtual machine equipped with 8 vcpus.
On Wed, Oct 16, 2013 at 07:34:38PM +0900, Akira Hayakawa wrote:
Dave
Akira, can you please post the entire set of messages you are
getting when XFS showing problems? That way I can try to confirm
whether it's a regression in XFS or something else.
Environment:
- The kernel version is
Dave
XFS shuts down because you've returned EIO to a log IO. That's a
fatal error. If you do the same to an ext4 journal write, it will do
the equivalent of shut down (e.g. complain and turn read-only).
You mean block device should not return -EIO anyway if
it doesn't want XFS to suddenly shut
On Wed, Oct 16, 2013 at 09:17:40PM +0900, Akira Hayakawa wrote:
Dave
XFS shuts down because you've returned EIO to a log IO. That's a
fatal error. If you do the same to an ext4 journal write, it will do
the equivalent of shut down (e.g. complain and turn read-only).
You mean block device
Mikulas,
> I/Os shouldn't be returned with -ENOMEM. If they are, you can treat it as
> a hard error.
It seems to be blkdev_issue_discard returns -ENOMEM
when bio_alloc fails, for example.
Waiting for a second and we can alloc the memory is my idea
for handling -ENOMEM returned.
> Blocking I/O
On Mon, 14 Oct 2013, Akira Hayakawa wrote:
> Hi, DM Guys
>
> I suppose I have finished the tasks to
> answer Mikulas's pointing outs.
> So, let me update the progress report.
>
> The code is updated now on my Github repo.
> Checkout the develop branch to avail
> the latest source code.
>
>
On Mon, 14 Oct 2013, Akira Hayakawa wrote:
Hi, DM Guys
I suppose I have finished the tasks to
answer Mikulas's pointing outs.
So, let me update the progress report.
The code is updated now on my Github repo.
Checkout the develop branch to avail
the latest source code.
Compilation
Mikulas,
I/Os shouldn't be returned with -ENOMEM. If they are, you can treat it as
a hard error.
It seems to be blkdev_issue_discard returns -ENOMEM
when bio_alloc fails, for example.
Waiting for a second and we can alloc the memory is my idea
for handling -ENOMEM returned.
Blocking I/O
Hi, DM Guys
I suppose I have finished the tasks to
answer Mikulas's pointing outs.
So, let me update the progress report.
The code is updated now on my Github repo.
Checkout the develop branch to avail
the latest source code.
Compilation Status
--
First, compilation status.
Hi, DM Guys
I suppose I have finished the tasks to
answer Mikulas's pointing outs.
So, let me update the progress report.
The code is updated now on my Github repo.
Checkout the develop branch to avail
the latest source code.
Compilation Status
--
First, compilation status.
Mikulas,
> Next, you need to design some locking - which variables are protected by
> which locks. If you use shared variables without locks, you need to use
> memory barriers (it is harder to design code using memory barriers than
> locks).
First I will explain the locking and the shared
Mikulas,
Next, you need to design some locking - which variables are protected by
which locks. If you use shared variables without locks, you need to use
memory barriers (it is harder to design code using memory barriers than
locks).
First I will explain the locking and the shared
On Sun, 6 Oct 2013, Akira Hayakawa wrote:
> Mikulas,
>
> Thank you for your reviewing.
>
> I will reply to polling issue first.
> For the rest, I will reply later.
>
> > Polling for state
> > -
> >
> > Some of the kernel threads that you spawn poll for data in one-second
>
On Sun, 6 Oct 2013, Akira Hayakawa wrote:
Mikulas,
Thank you for your reviewing.
I will reply to polling issue first.
For the rest, I will reply later.
Polling for state
-
Some of the kernel threads that you spawn poll for data in one-second
interval - see
Mikulas,
Thank you for your reviewing.
I will reply to polling issue first.
For the rest, I will reply later.
> Polling for state
> -
>
> Some of the kernel threads that you spawn poll for data in one-second
> interval - see migrate_proc, modulator_proc, recorder_proc,
Mikulas,
Thank you for your reviewing.
I will reply to polling issue first.
For the rest, I will reply later.
Polling for state
-
Some of the kernel threads that you spawn poll for data in one-second
interval - see migrate_proc, modulator_proc, recorder_proc, sync_proc.
26 matches
Mail list logo
