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
[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.
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
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.
Mikulas,
Let me ask you about this comment
of choosing the best API.
For the rest, I will reply later.
BTW. You should use wait_event_interruptible_lock_irq instead of
wait_event_interruptible and wait_event_interruptible_lock_irq_timeout
instead of wait_event_interruptible_timeout. The
Mikulas,
Waking up every 100ms in flush_proc is not good because it wastes CPU time
and energy if the driver is idle.
Yes, 100ms is too short. I will change it to 1sec then.
We can wait for 1 sec in termination.
The problem is that if you fill up the whole cache device in less time
than 1
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
Hi
I looked at dm-writeboost source code and here I'm sending the list of
problems I found:
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.
flush_proc correctly
12 matches
Mail list logo