Gave the new version in trunk a test and it seems to handle the
remount problem correctly. Thanks for the cleanup and getting it
applied!
Michael
On Thu, Feb 11, 2010 at 06:07:23PM -0500, Phil Carns wrote:
> Thanks for the new patch and for the explanation. I checked a modified
> version of y
Thanks for the new patch and for the explanation. I checked a modified
version of your patch into trunk. Can you try it out and let me know if
it works on your end?
I made some changes to how client-core exits (and how pvfs2-client
detects it) to make things a little cleaner. On my box the
Attached is the cvs diff with the requested flags. I noticed how useless
the previous patch format I used was when I was applying the cancel I/O
patch :)
It does lead to a pvfs2-client-core restart loop if the connection to
server never comes back. However, the loop will be tempered by the
BMI
Hi Michael,
Could you regenerate this patch with "diff -Naupr" (or "cvs diff
-Naup")? The -u in particular makes it a little easier to read/apply.
I think this is the same issue as described in this open trac entry,
which would be great to knock out:
https://trac.mcs.anl.gov/projects/pvfs
Attached is a patch against head for the issue. The comments largely
describe what's going on. If pvfs2-client-core is re-started due to a
segfault with a previously mounted PVFS filesystem any requests will
cause the process to spin.
The patch adds a check at the end of the process_vfs_request
wh
On Mon, Feb 01, 2010 at 02:04:22PM -0500, Michael Moore wrote:
> We recently saw some strange behvior in pvfs2-client-core when a server goes
> away
> (via segfault) and the client is unable to re-mount the filesystem. The
> pvfs2-client-core process takes up 100% of a core just spinning on
> p
We recently saw some strange behvior in pvfs2-client-core when a server goes
away
(via segfault) and the client is unable to re-mount the filesystem. The
pvfs2-client-core process takes up 100% of a core just spinning on
process_vfs_request -> PVFS_sys_testsome and subsequent calls. Full backtr
On Nov 9, 2006, at 4:00 PM, Walter B. Ligon III wrote:
Thanks ... ah, yes, I get the same behavior with the trunk as I do
with my branch.
So now we know HEAD is broken for 2.4 kernels? That's something
we're going to need to fix I guess.
OK, so I guess next we see how the branch fare
Thanks ... ah, yes, I get the same behavior with the trunk as I do with
my branch.
OK, so I guess next we see how the branch fares on a nightly?
Then what?
Walt
Sam Lang wrote:
Right. Merged the fix to trunk.
-sam
On Nov 9, 2006, at 3:25 PM, Walter B. Ligon III wrote:
Head won't build k
Right. Merged the fix to trunk.
-sam
On Nov 9, 2006, at 3:25 PM, Walter B. Ligon III wrote:
Head won't build kmod24 on RHEL3 - the same makefile problem we had
a couple weeks ago that you fixed (in the branch):
[EMAIL PROTECTED] pvfs2]> make kmod24
/bin/sh: line 1: [: missing `]'
/bin/sh:
Head won't build kmod24 on RHEL3 - the same makefile problem we had a
couple weeks ago that you fixed (in the branch):
[EMAIL PROTECTED] pvfs2]> make kmod24
/bin/sh: line 1: [: missing `]'
/bin/sh: line 1: [: missing `]'
/bin/sh: line 1: [: missing `]'
/bin/sh: line 1: [: missing `]'
/bin/sh: li
Heh. Yep. I was thinking "I'll get those bastards!" ;-)
Yes I generated a lot of output to the client. Here are the relevant parts:
[D 14:20:13.331062] SM next smcb 0x8e6dd70 op 400
[D 14:20:13.331092] SM invoke smcb 0x8e6dd70 op 400
[D 14:20:13.331110] [SM Entering]: (0x8e6dd70) sysdev_unex
On Nov 9, 2006, at 1:51 PM, Walter B. Ligon III wrote:
follow up to this email (which I seem to have sent to myself):
Heh. Did you wonder why you weren't getting a response?
Walter B. Ligon III wrote:
I'm kind of stuck on the branch. ALL of the lib tests seem to
work, but when I try
follow up to this email (which I seem to have sent to myself):
Walter B. Ligon III wrote:
I'm kind of stuck on the branch. ALL of the lib tests seem to work,
but when I try to mount via the kmod, mount returns "mount: Not a
directory"
As far as I can tell from the logs everything compl
No, there's an error. tm_mon is given as "months since January" in the
range 0 to 11. In order to print them as you are you need to add one to it.
I'll fix it in my branch.
Walt
Murali Vilayannur wrote:
Hi Walt,
It is indeed odd. We issue a call to time() and pass that to localtime().
Unles
Hi Walt,
It is indeed odd. We issue a call to time() and pass that to localtime().
Unless the time on your system is wrong, localtime() should print the
correct month etc..
Can you check if the time/date on the machine is right? sorry out of
clues on this one.
thanks,
Murali
On 11/9/06, Walter B.
Hey, the client core prints a date at the point in the log file where it
starts. On my system the month is off by one. Is this unusual?
Walt
--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
___
Pvfs2-developers mailin
17 matches
Mail list logo
