On 03/06/2012 12:20 AM, Andrew Savchenko wrote:
Hello,
On Wed, 22 Feb 2012 10:45:56 -0500 Becky Ligon wrote:
Let us know how it goes.
It goes not that well. For now I test on a double server setup on a
single host (kernel 3.1.10).
I can't get varstrip_dist to work at all. Due to some unknown
It is in the range for server 10.10.8.10, actually. That part looks
ok. It looks like you are setting up a configuration with exactly two
servers; one that is dedicated to metadata and one that is dedicated to
file data. Is that correct?
-Phil
On 01/27/2012 02:38 AM, Dimokritos Stamatakis
Hi Dimos,
You might want to post your current conf file again. In there you
should see a line that says something like RootHandle 1048576. That
is the identifier for the root handle that pvfs2-ping is trying to find
in the file system. If you then look a little further down in the
-developers-ow...@beowulf-underground.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of Pvfs2-developers digest...
Today's Topics:
1. Re: pvfs2 server bind problem (Phil Carns
Hi Dimos,
By default (unless you use the TCPBindSpecific flag in the conf file,
which you are not) the server should just try to bind to listen on
*:3334, no matter what hostname or IP address you put in the conf file.
In other words, it ignores the hostname and just listens for connections
Oh, and as a side note, will your protocol eventually support sizes
larger than 8kb? You probably know this already, but 8kb won't be a
very efficient access size for most hard drives, regardless of your
network characteristics.
-Phil
On 11/23/2011 03:25 PM, Phil Carns wrote:
Hi Mikhail
The pvfs2-server daemon never calls that function directly; it is
internal to BMI. Are you talking about the BMI_set_info(...
BMI_DEC_ADDR_REF ...) calls instead?
-Phil
On 10/25/2011 07:39 AM, ?? wrote:
Hi!
In what cases pvfs2-server calls bmi_addr_drop?
Can server call
On 10/17/2011 02:00 AM, Adam Yee wrote:
Dear developers and users,
The printed error message:
api-server: src/client/sysint/client-state-machine.c:862:
PINT_client_wait_internal: Assertion `smcb' failed.
/var/log/messages
Oct 16 22:54:29 server1 kernel: [ 3135.813404] api-server[10854]:
Great- I'm glad I was able to help.
-Phil
On 10/17/2011 06:58 PM, Adam Yee wrote:
Phil! It was the offset type declared as an int instead of uint64_t.
Thanks for getting back to me so quickly. Super helpful.
Adam
On Mon, Oct 17, 2011 at 12:43 PM, Phil Carns ca...@mcs.anl.gov
mailto:ca
Hi Adam,
I don't have any guesses as to what's going wrong, but you might want to
try running your application through valgrind to see if it gives you any
further information. That segfault that you listed below might not be
the original source of the problem.
-Phil
On 10/04/2011 07:25
Just to clarify, are you talking about multiple buffers in a single
post_recv_list() call, or are there multiple calls to post_recv_list()?
-Phil
On 09/26/2011 07:55 AM, ?? wrote:
Hi,
my bmi method's post_recv_list function tryes to receive N messages. M
messages received
That looks like a bug :) Good catch!
-Phil
On 09/26/2011 03:16 AM, ?? wrote:
Hi,
in bmi.c in function bmi_post_sendunexpected_list:
if (tmp_ref-interface-post_send_list)
{
ret = tmp_ref-interface-post_sendunexpected_list(
id, tmp_ref-method_addr, buffer_list, size_list,
Are you totally sure that the servers are exiting before you restart
them? PVFS uses the SO_REUSEADDR socket option which is supposed to
avoid this problem in most cases.
-Phil
On 07/24/2011 01:47 AM, ??? wrote:
I made some small changes in the process of creating a file
using
belongs inside of the PINT_manager_complete_op function. Thoughts?
Becky
On Thu, Jul 7, 2011 at 5:06 PM, Benjamin Severs
seversbenja...@gmail.com mailto:seversbenja...@gmail.com wrote:
Thanks to some direction by Phil Carns, we've managed to correct
the memory
leak that was affecting
On 07/08/2011 09:44 AM, Becky Ligon wrote:
Thanks for explaining that. So, if we had just freed the op but not
unregistered it, there still would have been a memory leak?
Becky
With the safe_register functions, yes. With the fast_register
functions, no.
-Phil
On 06/24/2011 10:15 AM, Michael Moore wrote:
With some additional offline information from Benjamin the problem has
been tracked down to dbpf_bstream_direct_write_op_svc(). The issue is
that two write calls to different, contiguous, sections of the file
occur without locking around retrieval of
On 06/24/2011 10:43 AM, Michael Moore wrote:
On Fri, Jun 24, 2011 at 10:33 AM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
On 06/24/2011 10:15 AM, Michael Moore wrote:
With some additional offline information from Benjamin the
problem has
been
I share Michael's curiosity as well, but I think it might be possible to
disable the precreate functionality using config file options if you
really need to (not recommended):
Set the FileStuffing option to no to prevent the file system from
using the file stuffing optimization that relies on
how well it would fit.
Michael
On Thu, Jun 2, 2011 at 8:39 AM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
I share Michael's curiosity as well, but I think it might be
possible to disable the precreate functionality using config file
options if you really need
Thanks Becky!
-Phil
On 05/12/2011 07:24 AM, Becky Ligon wrote:
Thanks, Pbil. We will certainly double check it and then add it to the
Orange-branch. Just FYI: we have a warning built into the config
generator that Berkeley 4.8 is now recommended.
Becky
Removing the metadata object for a file does indeed produce the same
symptoms we are seeing. It produces a similar effect on 2.8 as well. I
believe I was working with Sam and possibly you on this a few weeks
ago but had to drop it for something more urgent. Our conversation can
be found
, 2010 at 3:13 PM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
Hi Bart,
Can you run pvfs2-stat on one of the files, and also send along
the fs.conf file? pvfs2-stat might be helpful because it shows
the metadata handle value. We can compare that value
for recent BDB releases, in case anyone else needs to build 2.6 on a
modern box. I also found that I had to use the DBCacheType mmap
option in the server config file. I can't get the kernel module
working, so I stuck to command line utilities.
-Phil
On 10/11/2010 09:23 AM, Phil Carns wrote
On 10/11/2010 11:11 AM, Phil Carns wrote:
I'm not sure how you are getting there yet, but I am able to recreate
this state on my laptop with a single server and the pvfs2 admin
utilities.
The following shows the creation of 4 files. I then get the metadata
handle for one of them (via pvfs2
- how to make pvfs2-rm safely remove what it can (even if via a
force option)
- how to get pvfs2-lsplus (and probably other utilities and/or kernel
module as well) to report a sane error message instead of the
Invalid object message
The attached patch fixes the first problem (assuming I'm
On 10/11/2010 11:42 AM, Phil Carns wrote:
- how to make pvfs2-rm safely remove what it can (even if via a
force option)
- how to get pvfs2-lsplus (and probably other utilities and/or
kernel module as well) to report a sane error message instead of the
Invalid object message
The attached
Hi Bart,
Can you run pvfs2-stat on one of the files, and also send along the
fs.conf file? pvfs2-stat might be helpful because it shows the metadata
handle value. We can compare that value to the handle ranges in the
conf file to narrow down whether it is hitting a metadata object that
has
I think either changing the key or adding separate pools per type would
work fine (and probably require a similar amount of work?).
The former would mean modifying Trove. Trove does not currently expose
the functionality needed to skip to a subset of keys and remove one
(which would
On 06/21/2010 11:51 AM, Bart Taylor wrote:
Hey guys,
We ran into some errors creating large files, and with some direction
from Phil,
tracked it down to the alignment macros in dbpf-bstream-direct.c. You
can see
the problem in a directory set to use one dfile with this command:
strace dd
Thanks Bart! The patch is in CVS now.
This bug affects servers running on 32 bit machines that use the
directio trove method.
-Phil
On 06/21/2010 11:51 AM, Bart Taylor wrote:
Hey guys,
We ran into some errors creating large files, and with some direction
from Phil,
tracked it down to the
Hi Bart,
Is this on 2.8.2? Do you happen to know how many servers are needed to
trigger the problem?
thanks,
-Phil
On 06/17/2010 04:08 PM, Bart Taylor wrote:
Hey guys,
We have had some problems in the past on 2.6 with file creations
leaving bad
files that we cannot delete. Most
On Thu, May 13, 2010 at 3:13 PM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
Whoops. Thanks for your patience Bart. Can you try one more time
with this additional patch applied? If that fails I'll set up
something here to try to reproduce it first hand
Hey Bart,
I haven't really tested this change yet, but can you try the attached
patch and see if that seems to solve the problem? I think this is
follow on to the same bug you guys reported earlier. I just missed
another race issue caused by the last patch.
-Phil
On 05/12/2010 05:18 PM,
was able to run a ping and statfs again, but as soon as I tried to
write that file, the server stalled. What other information can I
get you?
Bart.
On Thu, May 13, 2010 at 12:14 PM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
Hey Bart
out
1+0 records in
0+0 records out
Bart.
On Mon, May 3, 2010 at 11:22 AM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
Can you get a server into this state (where everything works
except for strip size files), turn on verbose logging, and then
try to create a big
Actually, it might be good if you could just send me the fs.conf file
for your test setup.
thanks,
-Phil
On 05/06/2010 02:26 PM, Phil Carns wrote:
Thanks Bart. In your example, what are the names and ports of each of
the servers involved? Are they all on the same node (with different
ports
Ok, I think I was able to reproduce the same thing that you were
seeing. Can you try the attached patch and let me know if it fixes
things on your end too?
thanks!
-Phil
On 05/06/2010 02:34 PM, Phil Carns wrote:
Actually, it might be good if you could just send me the fs.conf file
for your
on my situation?
Bart.
On Fri, Apr 16, 2010 at 1:39 PM, Phil Carns ca...@mcs.anl.gov
mailto:ca...@mcs.anl.gov wrote:
Sadly none of my test boxes will run 2.6 any more, but I have a
theory about what the problem might be here.
For some background
Hi all,
Just wanted to give a warning that there might be some unstable changes
to BMI (networking) in CVS trunk for a little while. In particular, the
current trunk TCP code is not compatibly with 2.8.x.
thanks,
-Phil
___
Pvfs2-developers mailing
Sadly none of my test boxes will run 2.6 any more, but I have a theory
about what the problem might be here.
For some background, the pvfs2-server daemon does these steps in order
(among others): initializes BMI (networking), initializes Trove
(storage), and then finally starts processing
Thanks for tracking that down, Bart. The patch is in CVS now.
-Phil
On 03/11/2010 10:36 AM, Bart Taylor wrote:
After some further digging and off-list help from Phil, we determined
that the pvfs2_inode structures were not being properly initialized.
PVFS2 is using slab cache for the
I'm guessing it may be a conflict in the ioctl numbers across the two
modules. It looks like the compat registration function is global:
http://lxr.linux.no/#linux-bk+v2.6.9/fs/compat.c#L310
Maybe there is something in the error handling after that point that
caused the actual panic.
We
Sounds good. Its in trunk and 2-8 now.
thanks,
-Phil
Michael Moore wrote:
Attached is the patch for the gossip log format if anyone is interested
in applying it.
Michael
On Tue, Mar 09, 2010 at 10:51:38AM -0500, Michael Moore wrote:
Was there a reason for limiting the datetime format in
by the
BMI timeout and retry counts so it should be a reasonably long loop (I
don't recall the defaults off hand, but should only be every couple
minutes).
Michael
On Mon, Feb 08, 2010 at 01:51:16PM -0500, Phil Carns wrote:
Hi Michael,
Could you regenerate this patch with diff -Naupr (or cvs
of sm_p?
Thanks,
Michael
On Wed, Jan 20, 2010 at 08:01:41AM -0600, Phil Carns wrote:
Great! Thanks for testing it out.
-Phil
Michael Moore wrote:
Thanks Phil, that appears to solve the problem! I tested it both against
head and orange branch and didn't see any of the infinite looping or
client
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:
Thanks Michael. I pushed this to trunk and the 2.8 branch with some
comment changes. It actually looks like the 2.8 branch had a partial
fix that wasn't in trunk for some reason, but they are synchronized now.
-Phil
Michael Moore wrote:
I noticed a segfault occuring in dbpf-bstream when
Oh, and that closes an old trac ticket as well:
https://trac.mcs.anl.gov/projects/pvfs/ticket/106
Phil Carns wrote:
Thanks Michael. I pushed this to trunk and the 2.8 branch with some
comment changes. It actually looks like the 2.8 branch had a partial
fix that wasn't in trunk for some
Thanks for the fix, Bart. It's in our CVS tree now.
-Phil
Bart Taylor wrote:
Hey guys,
Attached is a patch fixing some mtime inconsistencies we have seen along
with a related logging update. The compatibility hack and No version
found message in the get-attr state machine were being
Hi Bart,
Should that dd command in there have an extra flag like oflag=direct
to make sure it doesn't just write to the buffer cache when you check
the device? oflag=fsync would probably work too.
-Phil
Bart Taylor wrote:
I attached the patch this time.
On Wed, Dec 9, 2009 at 10:27 AM,
Thanks Bart. This is integrated into CVS now.
-Phil
Bart Taylor wrote:
Attached is a small patch that fixes a problem with handling SIGHUP
signals. The server alias string is freed early in server.c, so garbage
gets passed into PINT_parse_config when a SIGHUP is received. I moved
the free
Thanks Michael. Looks fine to me so I dropped the patch into trunk and
pvfs-2-8-branch.
-Phil
Michael Moore wrote:
While running valgrind I noticed two spots with memory not being free'd,
but having fairly small impact.
In pvfs2-server.c an array for holding BMI addresses of metadata
Erik Nieto wrote:
Hello Everybody:
I have some questions about the create system interface operation
in the 2.8.1 version of pvfs2.
In the earlier version (pvfs-2.7.1), the state machine:
1.- First create a space for the metafile.
2.- Next, create the datafiles in the indicated
-client-core
root 20435 20434 0 Sep14 ?00:00:05 pvfs2-client-core --child -a 5
-n 5 --logtype file -L /tmp/pvfs2-client.log
root 23623 19719 0 15:28 pts/200:00:00 grep pvfs
Any thoughts??? greatly appreciated!!!
-Amit
-Original Message-
From: Phil Carns [mailto:ca
Becky Ligon wrote:
Amit:
This means that the PVFS system cannot access the attributes database
containing the information about the particular file. It also means that
the file is unusable. You need to determine which metadata server is
having problems. If you don't have a backup, then you
Have you actually tried db_recover yet? It can fix some things even
without a transaction log.
I would recommend making a backup of your .db files first. After you
have tried Kevin's suggestion, you can go into the directory for the
collection (where the dataspace_attributes.db and
Hi Nick,
I just put a variation on your patch into cvs trunk. It needed a few
tweaks to work on RHEL4, which has an odd variation on what class
functions are available.
-Phil
Nicholas Mills wrote:
All,
In src/kernel/linux-2.6/devpvfs2-req.c:1037 there is a call to
class_device_create().
Becky Ligon wrote:
I have modified the configure script by adding src/apps/user/module.mk
to the list of files in the definition of $ac_config_files. I also
modified configure.in by adding src/apps/user/module.mk to the
definition of AC_OUTPUT.
Do I need to commit both files to CVS?
Are these
The patch looks good to me. I went ahead and committed it to cvs trunk.
Thanks for tracking that down!
-Phil
David Metheny wrote:
For the RHEL3 systems (2.4.21-27 smp) this was configured with
–disable-epoll, since the systems don’t support epoll.
Attaching with gdb to the
That sounds like a bug to me.
-Phil
Kevin Harms wrote:
Is there any reason for pvfs2-stat not to return a non-zero exit code
when the path doesn't exist? That seems to behavior of a stat shell
command.
fs1:~/bin # pvfs2-stat /pvfs2/path
PVFS_sys_lookup: No such file or directory (error
Bart and I hashed through this a little more off list and got a slightly
modified version of this patch committed to cvs trunk.
Thanks Bart!
-Phil
Bart Taylor wrote:
Hey guys,
I attached a patch for pvfs2-ls that does a few things.
First, there is an off by one error from my previous patch
Thanks David! Patch is in cvs trunk now.
-Phil
David Metheny wrote:
The attached patch fixes the cases where the Filesytem-qla-monitor
script prints out message “ERROR: Filesystem-qla-monitor must specify
fsname!” on a call with command ‘meta-data’. The operation check for
‘meta-data’
Thanks Dries. It looks like fs_struct.h goes back even into the 2.4
series. I went ahead and dropped the change into CVS trunk.
-Phil
Dries Kimpe wrote:
It seems in that, in 2.6.30, fs_struct.h is no longer included from some
other headers, causing acl.c (src/kernel/linux-2.6/acl.c) to fail
failed at
around 200 members of a group, and since the system can't determine the
correct size via sysconf, I just picked something that would take a long
time to break.
-Original Message-
From: Phil Carns [mailto:pca...@gmail.com] On Behalf Of Phil Carns
Sent: Tuesday, March 24, 2009 9:40
There is actually an admin tool (pvfs2-rm-object) that does what Kevin
described (used for testing pvfs2-fsck mainly). That can be used to get
rid of each handle/object in the file, but that would still leave a
directory entry to get rid of...
Does pvfs2-rm not remove the entire file? It
Hi Christina,
I answered some of your specific questions in line below:
Christina Patrick wrote:
Hi All,
I am doing a project where I need to implement simple prefetching in
pvfs. While I was going through the pvfs code, I couldn't understand
the following and hence have to ask the below
Hi Bart,
From your strace output, my guess is that cp is running into trouble
with the value of one of the fstat() fields, but its hard to say which one.
Are you able to reproduce this reliably? Could you run the strace again
with the -v option to see if it gives a full listing of what
03/30 15:18] handle_io_error: flow proto 0x487d8f0 error cleanup
finished, error_code: -1073741959
- Elaine
-Original Message-
From: Phil Carns [mailto:pca...@gmail.com] On Behalf Of Phil Carns
Sent: Monday, March 30, 2009 3:15 PM
To: Elaine Quarles
Cc: pvfs2-developers@beowulf
I just mentioned this on another thread on pvfs2-users, but I'm not sure
if you are having the same problem or not. Could you try compiling the
cvs trunk version of PVFS and let us know if that fixes the problem?
Instructions for how to check out the cvs code can be found here:
Thanks Bart. The patch is applied to trunk now with a minor update to
the --help description.
-Phil
Bart Taylor wrote:
Hey guys,
Attached is a small patch that allows you to enable the TCPBindSpecific
option when running pvfs2-genconfig. It can help simplify setting up a
file system with
Thanks Kyle. Patch is applied in cvs trunk now.
-Phil
Kyle Schochenmaier wrote:
While compiling 2.8.0 I ran into some shadowed function declaration
warnings, I believe the correct solution is to just rename the
offending functions/variables, however the compiler is supposed to use
the correct
Thanks Bart! The patch has been applied to PVFS trunk.
-Phil
Bart Taylor wrote:
Hey guys,
Attached are two patches for giving pvfs2-lsplus (now just pvfs2-ls) a
recursive
option. One patch is for pvfs2-lsplus against pvfs-2-6-branch and the
other is
for pvfs2-ls against HEAD. The output
What version of PVFS are you testing (or is it trunk)? We have had a
couple of permutations of this bug in the past, but I hope it is sorted
out now in trunk.
-Phil
Walter Ligon wrote:
Hey, I was looking at the readdir rewind bug and wondering, could this
be responsible for reporting the
pvfs2-cli 14793 root8r DIR 0,200 5654
infinibandevent
Thank you,
Amit
-Original Message-
From: Phil Carns [mailto:pca...@gmail.com] On Behalf Of Phil Carns
Sent: Thursday, January 08, 2009 2:25 PM
To: Kumar, Amit H.
Cc: 'Rob Ross'; pvfs2-developers
thread.
Nawab, in the zoidfs init code after initializing BMI you need to call:
int check = 0;
BMI_set_info(0, BMI_TCP_CHECK_UNEXPECTED, check);
-sam
On Dec 23, 2008, at 2:01 PM, Phil Carns wrote:
Sam Lang wrote:
Hi All,
I think Nawab has found a bug (or untested code path) in the BMI tcp
method
Sam Lang wrote:
Hi All,
I think Nawab has found a bug (or untested code path) in the BMI tcp
method. He's running a daemon that both receives unexpected requests
(as a server), and receives expected responses (as a client).
In the BMI_testcontext call, if there aren't any completed
Thanks David; patch is now applied to CVS trunk. I hope the source code
still fits on your punch cards :)
-Phil
David Metheny wrote:
This patch #defines out the immutable code during the builds for 2.4.x
kernels. I’m hoping our support of PVFS2 on 2.4.x kernels is nearing the
end, but it
Thanks Bart. I committed a slightly modified version of your patch to
cvs trunk.
-Phil
Bart Taylor wrote:
Hey guys,
This patch fixes an issue with trusted networks. If the TrustedNetworks
field is present in the conf file but there is no value, the file system
is unreachable from any
Thanks Bart. I applied the patches to cvs trunk.
-Phil
Bart Taylor wrote:
I neglected the header file; attached is an additional patch to catch
it. Both of these patches should apply cleanly to head.
Bart.
On Thu, Nov 20, 2008 at 1:54 PM, Bart Taylor [EMAIL PROTECTED]
mailto:[EMAIL
Hi Ankur,
This patch fixes the code so that it does the right thing if you just
return an error code from the tcp_accept_init() function. It is already
applied to cvs trunk.
thanks,
-Phil
Phil Carns wrote:
For an immediate solution you can just mimic the logic in the BIG
KLUDGE comment
Maybe the memory accounting is just handled differently in RHEL5?
-Phil
David Metheny wrote:
I'm running the same types of tests I did with a RHEL3 and RHEL4 system. But
not seeing the same results on the RHEL5 systems. So... I'm not sure if it
really is a problem or not.
Watching 'top' or
Hi Ankur,
I think we could clean up this path some. Just to clarify what you are
looking for though, are you planning to send a response all the way back
to the client? The server does not normally send a response back for a
failed unexpected message. In the case you describe, you would
- Original Message - From: Phil Carns
[EMAIL PROTECTED] To: Ankur G Pai [EMAIL PROTECTED] Cc:
pvfs2-developers@beowulf-underground.org Sent: Thursday, November 20,
2008 10:07:44 AM GMT -05:00 Columbia Subject: Re: [Pvfs2-developers]
bmi-tcp doubt
Hi Ankur,
I think we could clean up this path some
:
Disregarding the connection is fine with me. But what do I return
from bmi_tcp.c. If I return 0, the client call completes. If I return
-1, server crashes. So if I want to disregard the request, what do I
return from tcp_accept_init() ?
Thanks, Ankur - Original Message - From: Phil Carns
[EMAIL
Phil Carns wrote:
Rob Ross wrote:
Should we just replace pvfs2-ls with pvfs2-lsplus? -- Rob
I don't know of any reason not to. They are feature equivalent in terms
of command line arguments and output format.
-Phil
This is done now in CVS. I don't know if anyone needs it, but make
Just a quick update for anyone following this bug report. So far I
haven't been able to reproduce this yet on a single server file system
using either 2.6.3 (patched to increase dirent count) or trunk code. We
are still trying to narrow down what the key factor is.
-Phil
Phil Carns wrote
the MAX_DIRENT_COUNT in the
src/kernel/linux2.6/pvfs2-dev-proto.h and put it back at 0x0020 (32) and
reran the test. The 'ls -Rl' consistently runs in about an hour now, and
finishes correctly.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Phil
Carns
FYI, I reduced the limit (in the kernel only, not pvfs2-ls) down to 96
for the time being in cvs trunk. This avoids the token rewind problem
triggered by bonnie++, but hopefully still keeps some of the ls speed
improvement.
-Phil
Phil Carns wrote:
We recently applied a patch from Bart
those jobs didn't quite stop accesses to the jobs
memory. Phil Carns sent me a patch to fix this.
I've ran a small sample of tests on a single PVFS2 server with a separate
machine for the PVFS2 client. Both machines are running RHEL4 U7 i386 WS.
The short version is that there was little affect
Pai, Ankur G wrote:
Hi Phil, Thanks a lot for replying. So here is the deal. I am working
on an enhanced PVFS with an entirely new set of state machines added
to create a new struct called ecreate. Its working fine (all state
machines and everything). Unfortunately, the guy who made these
Hi Brad,
There is a --without-openssl option to PVFS that keeps it from using
those symbols altogether. That's helped me in a couple of cases where
it was hard to drag the ssl libraries around.
-Phil
Bradley Settlemyer wrote:
Hello,
Has there been any thought on trying to drag in the
It sounds like there are really two problems in this case:
a) the remove takes a long time
b) trove won't work on other metadata operations until the remove completes
I don't know if this is a good idea or not, but here is a potential
quick way to make the remove work in the background:
entries than filldir() can consume.
-Phil
Rob Ross wrote:
Has the internal kernel value changed since we last looked?
Rob
On Sep 4, 2008, at 4:16 PM, Phil Carns wrote:
Sam Lang wrote:
Hi Bart,
Thanks for the patch. For users with that many files in a directory,
using pvfs2-ls is probably
) = 4080
getdents64(3, /* 132 entries */, 4096) = 3168
getdents64(3, /* 0 entries */, 4096)= 0
So even with just 300 entries your patch takes us from 11 getdents
system calls down to 3 to do an ls.
Thanks!
-Phil
Phil Carns wrote:
I looked at the code a little just now. The getdents
Sam Lang wrote:
Hi Bart,
Thanks for the patch. For users with that many files in a directory,
using pvfs2-ls is probably a good alternative.
The kernel does readdir requests 32 entries at a time, so increasing
MAX_NUM_DIRENTS won't help for ls. Long listings requires getting the
size of
Thanks David, and good catch on both counts. The patch has been
committed to trunk.
-Phil
David Metheny wrote:
Attached is a patch against the trunk CVS for the PVFS2 example resource
heartbeat script.
The patch changes the location of the pvfs2-server and
pvfs2-check-server executable
we never got a chance to
test it. Sam added an op_release in namei.c to fix a kmem_cache leak,
and it sneaked in twice without warning. Taking that out fixed the problem.
Bart.
On Tue, Jul 29, 2008 at 8:03 AM, Phil Carns [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I'm having
Phil Carns wrote:
Bart Taylor wrote:
I am having a problem with an LTP test from the 20080630 set of LTP
tests. The
'openfile01' test does 10 threaded opens of 10 files. It is attached
in case you
need a copy. The test completes successfully, but an 'ls' command
immediately
after that hangs
Bart Taylor wrote:
I am having a problem with an LTP test from the 20080630 set of LTP
tests. The
'openfile01' test does 10 threaded opens of 10 files. It is attached in
case you
need a copy. The test completes successfully, but an 'ls' command
immediately
after that hangs and cannot be
not seem to make a difference. I do not see any log message,
client or kernel, that indicate what is happening. The pvfs2-client-core
does die after the long file name commands run though.
Bart.
On Mon, Jun 30, 2008 at 2:10 PM, Phil Carns [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote
1 - 100 of 275 matches
Mail list logo
