I captured a log file (attached) of both pvfs2-client and the kernel module after running this:

<mount pvfs2>
cd /mnt/pvfs2
mv dir/file1 dir/file2

The ncache and acache are both disabled in pvfs2-client to try to simplify the scenario.

I tried to get syslog to sync enough to get both pvfs2.ko and pvfs2-client-core messages chronologically in the same file, but it didn't really work out. They are jumbled together in an odd order.

It's probably less confusing to just grep each one out like this if anyone wants to have a look at what's going on:

# for kernel module messages:
grep "kernel: " mv-bug.log

# for pvfs2-client messages:
grep "PVFS2: \[D\]" mv-bug.log

-Phil

Phil Carns wrote:
It looks like dbench is hanging on a rename of a file within a subdirectory. I can replicate it outside of dbench like this:

  root@(none):/mnt/pvfs2# pwd
  /mnt/pvfs2
  root@(none):/mnt/pvfs2# mkdir testdir
  root@(none):/mnt/pvfs2# touch testdir/foo
  root@(none):/mnt/pvfs2# mv testdir/foo testdir/bar

Everything works fine if I instead try to rename something with no subdirectory:

  root@(none):/mnt/pvfs2# touch foo
  root@(none):/mnt/pvfs2# mv foo bar                  # so far so good

I don't think the "mkdir" and "touch" steps are relevant other than just for an example. I think get the same hang if the file and subdir already exist when pvfs is mounted.

-Phil


Attachment: mv-bug.log.gz
Description: GNU Zip compressed data

_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to