I downloaded openmotif and run the command as Mitch mentioned and was able to
recreate the problem locally. And I managed to simplify the command into a very
simple program which can capture the problem easily. See below code:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
static char a[4096*3];
int main()
{
int fd = open("out", O_WRONLY|O_CREAT|O_TRUNC, 0666);
write(fd,a+1, 4096*2);
exit(0);
}
It seems that if we give an unaligned address to btrfs write and the buffer
reside on more than 2 pages. It will trigger this bug.
If we give an aligned address to btrfs write, it works well no matter how many
pages are given.
I use ftrace to observe it. It seems iov_iter_fault_in_readable do not trigger
pagefault handling when the address is not aligned. I do not quite understand
the reason behind it. But the solution should be to process the page one by
one. And that's also what generic file write routine does.
Any suggestion are welcomed. Thanks!
-----Original Message-----
From: linux-btrfs-ow...@vger.kernel.org
[mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Mitch Harder
Sent: Wednesday, March 02, 2011 5:09 AM
To: Xin Zhong
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs file write debugging patch
2011/3/1 Xin Zhong <thierryzh...@hotmail.com>:
>
> Hi, Mitch
> I think you can config ftrace to just trace function calls of btrfs.ko which
> will save a lot of trace buffer space. See below command:
> #echo ':mod:btrfs' > /sys/kernel/debug/tracing/set_ftrace_filterAnd please
> send out the full ftrace log again.
>
> Another helpful information might be the strace log of the wmldbcreate
> process. It will show us the io pattern of this command.
> Thanks a lot for your help!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html
>
I manually ran an strace around the build command (wmldbcreate) that is causing
my problem, and I am attaching the strace for that.
Please note that wmldbcreate does not seem to care when an error is returned,
and continues on. So the error is occurring somewhat silently in the middle,
and isn't the last item. The error is probably associated with one of the
12288 byte writes.
I have re-run an ftrace following the conditions above, and have hosted that
file (~1.1MB compressed) on my local server at:
http://dontpanic.dyndns.org/trace-openmotif-btrfs-v15.gz
Please note I am still using some debugging modifications of my own to file.c.
They server the purpose of:
(1) Avoiding an infinite loop by identifying when the problem is occuring, and
exiting with error after 256 loops.
(2) Stopping the trace after exiting to keep from flooding the ftrace buffer.
(3) Provide debugging comments (all prefaced with "TPK:" in the trace).
Let me know if you want me to change any of the conditions.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
