Hi,
In short Cengiz, you're going to have to do a little work if you want
to turn off the precreate functionality and go back to the old way of
allocating metadata and data objects. That code isn't being tested or
supported any more; the new way of doing things is simply better for
most
Hi Julian,
Probably I'm being slow, just coming back from the holidays, but I
think that the issue is that your data is noncontiguous in memory?
Current ROMIO doesn't do buffering into a contiguous region prior to
writing to PVFS (i.e., data sieving on writes is disabled). Looking at
the
Drop an assert in there? -- Rob
On Sep 3, 2009, at 11:19 AM, Pete Wyckoff wrote:
mtmo...@clemson.edu wrote on Thu, 03 Sep 2009 11:51 -0400:
In looking at some issues I was having with the encoding of
PVFS_dirent
structs in requests I saw an inconsistency in how here_strings are
encoded and
On Wed, Jul 1, 2009 at 4:00 PM, Rob Ross rr...@mcs.anl.gov wrote:
Do you mean that 2.8.0 is fast and 2.8.1 is slow? Can you describe
the benchmark and how you are doing your measurements?
Rob
On Jul 1, 2009, at 4:43 PM, David Bonnie wrote:
Hello all -
I'm having trouble figuring out a problem
Hi Walt,
Thanks for the explanation. So to make sure I understand how one would
differentiate between servers and clients (if that is importatn),
basically servers would never hand out a capability allowing someone
to perform an operation we didn't want clients to perform (e.g., a
batch
creative so I like to make sure we're on track. I'm sure this
lively discussion is just that - a sign of a good thing! :)
Rob Ross wrote:
Hi Walt,
Thanks for the explanation. So to make sure I understand how one
would differentiate between servers and clients (if that is
importatn
is I'm not sure how important this bulk-create issue really
is - but there are ways to deal with it.
Walt
Rob Ross wrote:
On Jun 25, 2009, at 9:45 AM, Nicholas Mills wrote:
Rob -
You're absolutely correct. The capabilities are trusted and can
only come from servers. If a client gets a hold
:37 AM, Rob Ross rr...@mcs.anl.gov wrote:
I'm not sure how important the bulk-create issue is either, but I
thought I'd bring up the file creation as a related place where a
malicious user could consume lots of resources quickly. Seems like
if we're going to try to address one then we need
Hi Walt,
I'm curious about this too. The only input parameter of note in the
batch_create request is the FSID, so there isn't much to work with in
terms of permission checking...
Nick, are you developing some mechanism to differentiate servers from
clients? Or is there some sort of
not entirely clear what the issue is with all this, I'm hoping
htye will shed some light on it.
Walt
Rob Ross wrote:
Hi Walt,
I'm curious about this too. The only input parameter of note in the
batch_create request is the FSID, so there isn't much to work with
in terms of permission checking
Can we make a -f option do what we want with pvfs2-rm?
Rob
On May 28, 2009, at 9:22 AM, Phil Carns wrote:
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,
I think we've had that bug for a while. Should only happen if you're
adding to the directory as it is readdir'd. -- Rob
On Jan 14, 2009, at 3:06 PM, Walter Ligon wrote:
Hey, I was looking at the readdir rewind bug and wondering, could
this be responsible for reporting the same files
Hey,
For the CALLBACK option, you would use that to have the individual
methods filling in things at the generic BMI layer (for lack of the
right terminology), but the overall user API would be the same?
I don't think that the CONTEXT option is appropriate. I don't want to
expose the
Hi Amit,
What version of PVFS is this?
What does the output of netstat -tan look like?
Thanks,
Rob
On Jan 7, 2009, at 2:03 PM, Kumar, Amit H. wrote:
Hello All,
I am trying to understand the following output from “lsof”.
All/most of our compute nodes (pvfs2 clients) have the following
Yeah a special named context for unexpected message would be a clean
way to have done things... -- Rob
On Jan 6, 2009, at 2:49 PM, Phil Carns wrote:
Yeah, I don't particularly like adding special cases either.
I feel like making the consumer play with timeouts or use an extra
thread would
unexpected messages to have priority, the bmi code itself shouldn't
dictate that priority. We could define interfaces to BMI that allow
the policy to be set, but that's even further from where we are now.
-sam
On Jan 6, 2009, at 2:52 PM, Rob Ross wrote:
Yeah a special named context
, 2009, at 5:03 PM, Rob Ross wrote:
I think if we had this alternative design and one wanted to have
different priorities, one would look for messages under different
contexts as you say. But when you don't care about priority, it
would be nice to be able to get everything in one call.
I
the fact that zoidfs is blocking is irrelevant to how the server
implements servicing the calls. -- rob
On Jan 6, 2009, at 9:15 PM, Sam Lang wrote:
On Jan 6, 2009, at 7:51 PM, Rob Ross rr...@mcs.anl.gov wrote:
Hi Sam,
My take on your email was that you were combining the two issues,
so
is there any way to do a quick verification that the buffer is still
in the right place, on the kernel side, and then force a remapping?
rob
On Nov 21, 2008, at 11:19 AM, David Metheny wrote:
I know this fixes RHEL3 (2.4 kernels) and the RHEL4 U6/U7 (2.6.9
kernels), but testing this with
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 a good alternative.
The kernel does readdir requests 32
stripe dist.
-sam
On Jul 1, 2008, at 8:08 PM, Rob Ross wrote:
I agree that it's best to have it work for everyone with default
parameters.
-- Rob
On Jul 1, 2008, at 4:15 PM, Kyle Schochenmaier
[EMAIL PROTECTED] wrote:
We should use simple stripe in that case, which is why i have
let's try to use at least two letters to describe what kind of data we
are caching, from now on. -- rob
On Jul 1, 2008, at 11:05 AM, Sam Lang wrote:
Hi Walt,
The acache (attribute cache) and ncache (name cache) are both based
on a generic timeout cache interface (tcache). It shouldn't
heh that's fine. thanks! -- rob
On Jul 1, 2008, at 2:02 PM, Walter Ligon wrote:
LOL, ok, that's what I was thinking. How about cap_cache for
capabilities? Or do you not like the underline?
Walt
Rob Ross wrote:
let's try to use at least two letters to describe what kind of data
we
I agree that it's best to have it work for everyone with default
parameters.
-- Rob
On Jul 1, 2008, at 4:15 PM, Kyle Schochenmaier [EMAIL PROTECTED]
wrote:
We should use simple stripe in that case, which is why i have it
defaulted to it now, someone was playing with twod-dist today and
Should we just replace pvfs2-ls with pvfs2-lsplus? -- Rob
On Apr 3, 2008, at 8:07 PM, Phil Carns wrote:
There are a couple of performance bug fixes in trunk and 2.7 branch
now that I thought might be of interest to the list.
The first went in about two weeks ago and fixed a condition
Fine by me. I agree with Sam that the threaded version probably ought
to be the default *eventually*, but that it's really low on the list
of priorities. -- Rob
On Feb 14, 2008, at 5:18 PM, Sam Lang wrote:
On Feb 14, 2008, at 4:34 PM, Pete Wyckoff wrote:
What does everybody think about
New versions will still be able to find bstream files for files
created by old servers? -- Rob
On Jan 18, 2008, at 12:42 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Fri, 18 Jan 2008 11:51 -0600:
On Jan 17, 2008, at 3:26 PM, Pete Wyckoff wrote:
I just noticed this bit in
New versions will still be able to find bstream files for files
created by old servers? -- Rob
On Jan 18, 2008, at 12:42 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Fri, 18 Jan 2008 11:51 -0600:
On Jan 17, 2008, at 3:26 PM, Pete Wyckoff wrote:
I just noticed this bit in
should we bump up MAX_NUM_PATHS while we're at it? -- rob
On Jan 4, 2008, at 1:06 PM, Murali Vilayannur wrote:
yep.. thats right :)
I think it should be safe to change the strrchr to strchr since it
seems to fix both the cases..
thanks,
Murali
On Jan 4, 2008 9:09 AM, Phil Carns [EMAIL
there's bytes
waiting. I guess that's why the call was initially a blocking
recv. I can add a loop around the non-blocking recv while it
returns EAGAIN, unless someone can think of a better work around.
-sam
On Oct 16, 2007, at 8:56 PM, Rob Ross wrote:
sounds good to me. -- rob
Pete
On Dec 7, 2007, at 1:57 PM, Sam Lang wrote:
On Dec 7, 2007, at 1:54 PM, Murali Vilayannur wrote:
I'm confused now. Why do we need a dentry cache timeout?
i.e. only if we wish to take advantage of the kernel provided dcache.
Right now, it is as if the timeout is 0, i..e hits in the dcache
We can do Portals over TCP on the bb nodes. We have IB HW in there
somewhere too, don't we?
Rob
Sam Lang wrote:
Troy,
Mea culpa. This was caused by a lack of testing on my part. I've
attached a patch that should fix these errors. Can you apply and let me
know if it works for you?
All
Sam Lang wrote:
On Oct 9, 2007, at 8:02 AM, Scott Atchley wrote:
On Oct 8, 2007, at 3:56 PM, Sam Lang wrote:
The patch implements a complementary callback function:
bmi_method_addr_forget_callback, to be called by the individual
methods when the connection is closed or the address is
Well done Sam; thanks for tracking this one down. -- Rob
Sam Lang wrote:
The halloween bug (what I'm calling it -- its been haunting us for a
while now) is that we're adding address references to the bmi address
list, and never removing them. In the prelude state machine, we make a
that was too easy. thanks. -- rob
Sam Lang wrote:
Try using ./prepare?
-sam
On Sep 6, 2007, at 1:26 PM, Rob Ross wrote:
hey,
yeah, dangerous, me trying to build stuff...
using latest head on intel OSX. i think that there's a problem with
the bdb tests (they fail because NULL isn't
once that first problem was fixed, and i correctly set CFLAGS to point
to location of db.h, i no longer needed to adjust configure tests.
so we're all good.
rob
Sam Lang wrote:
On Sep 6, 2007, at 1:26 PM, Rob Ross wrote:
hey,
yeah, dangerous, me trying to build stuff...
using latest
hmm. ok. stupid readdir. i think i've fought passing the name for a long
time, but i'm ready to give in.
rob
Sam Lang wrote:
On Sep 5, 2007, at 10:47 AM, Rob Ross wrote:
Are those cookies not somehow tied to a particular client?
No they're not.
-sam
Sam Lang wrote:
On Sep 5, 2007
Hi Dharani,
Posting (virtually) the same message to pvfs2-users and pvfs2-developers
is discouraged. Please keep this on pvfs2-users.
Regards,
Rob
Dharani Vijayakumar wrote:
Hi,
I had to setup the pvfs using the VFS interface today. Whenever i try
creating a file using vim or cat in the
I thought so too :). -- Rob
Sam Lang wrote:
On Aug 30, 2007, at 8:37 AM, Robert Latham wrote:
On Wed, Aug 29, 2007 at 03:43:29PM -0500, Rob Ross wrote:
[catching up]
I've always thought that the immutable bit meant that the data can't
change; deleting is fine.
There's no POSIX standard
[catching up]
I've always thought that the immutable bit meant that the data can't
change; deleting is fine.
Rob
Murali Vilayannur wrote:
Sam,
immutable files are by definition to prevent users from deleting
(including admins who may make a mistake)
Once immutable file bit is set, you
seems like this is something that admins have had to deal with forever;
we're not asking anyone to do anything unusual... -- rob
Murali Vilayannur wrote:
Hi Sam,
You mean remove it for good from the code, right?
A chmod -t does not do the trick. We explicitly reset it internally
sadly :(
I
Since our config file is text, can't we skip any encoding? I agree that
it would be more concise, but we don't send config files around all that
often.
Rob
Sam Lang wrote:
On Jun 20, 2007, at 1:54 AM, Murali Vilayannur wrote:
Hi Sam,
I see..So do you wish that we fallback to parsing from
We need multiple servers per node for failover.
I hate to require TCP/IP just for configuration.
Rob
Sam Lang wrote:
On Jun 20, 2007, at 11:38 AM, Murali Vilayannur wrote:
Hi Sam,
Hmm...well if the server config file isn't specified, why can't the
server just get the hostname instead of
I agree Murali that this is getting handwavy w/out a prototype.
We've got a couple of different topics mixing too :).
One is discovering available servers. It seems like zeroconf/mdns seems
like a reasonable way to do this, at least when UDP works.
Another is just coming up with a way to
i think of zeroconf as just a way of identifying a server from which to
obtain a config file (which could be text). in other words, we could
distribute our *existing* config files via zeroconf plus a getconfig.
rob
Sam Lang wrote:
On Jun 20, 2007, at 7:54 PM, Rob Ross wrote:
Since our
do you mean addition/deletion of servers in running pvfs file system?
rob
Hagai Avrahami wrote:
Hi
I am trying to understand what changes need to be done in the code
To support addition/deletion of file system in running pvfs2-server
without restart
I will be grateful for any help
I like the idea of specifying aliases rather than handle ranges, etc.,
if that is feasible. I also agree that we want this interface to allow
this specification at create time, but then we want to use our existing
scheme for long-term metadata storage (e.g. just keep the handles).
Regards,
Hi David,
I stand corrected; the PNNL team has integrated components into PVFS and
is testing these components. I don't believe that they are using the
FUSE approach that you mention.
Regards,
Rob
Rob Ross wrote:
Hi David,
We have discussed with the group at PNNL the idea of integrating
I'm sure we'll all get sync'd up soon. No worries.
Rob
Jarek Nieplocha wrote:
David,
We have an early prototype work using a different approach than the
original
kernel space implementation of Active Storage. It is done purely in user
space.
One advantage of the approach is that improved
Hi David,
We have discussed with the group at PNNL the idea of integrating some of
their active storage work into PVFS in the future, but that work hasn't
started quite yet.
The idea of using FUSE as a way to hook into the I/O path is pretty
interesting and might be a good way to prototype.
yeah zero the minor when changing the major version. thanks for putting
this together! -- rob
Sam Lang wrote:
Here's a patch with the suggested changes. Handling the comparison
function with a different storage format ended up being a bit uglier
than I expected. Removing the DB_RECNUM
Hi guys,
It's *very* cool to see this all coming together.
Rob
Thomas Ludwig wrote:
Hi all,
Robert Latham wrote:
On Thu, Mar 08, 2007 at 05:50:52PM +0100, Julian Martin Kunkel wrote:
We see a rather strange and wrong behavior with PVFS2 using a file view with
MPI-IO using different levels
Wow, I didn't think that this stuff would come up again soon :).
The current implementation (a) tracks what is free and (b) what is
recently used, (c) lets the server choose the handle to return, and (d)
keeps a global handle space (a handle is unique across all servers).
the point of (a)
(As an aside) fixing statecomp so that you don't have to declare new
states would be a nice simplification.
Rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Fri, 16 Feb 2007 19:07 -0600:
The few times I've ever changed statecomp it was to change the
generated as well, so I would have
Nice Scott! What's the realistic BW limit for this hardware?
Rob
Scott Atchley wrote:
On Jan 5, 2007, at 11:47 AM, Scott Atchley wrote:
I modified perf.c to write 10 times a buffer of 128 MBs. I get:
% mpiexec -n 1 ./perf -fname pvfs2:/mnt/pvfs2/x1
Access size per process = 134217728
Hi Scott,
Good idea to improve on pvfs2-cp some. I see that Pete has followed up
with some ideas on how to push things a little harder.
Thanks, and great to see how far you've gotten!
Rob
Scott Atchley wrote:
Hi all,
What performance do you typically see with a single client and single
This is similar to using O_DIRECT, which has also shown benefits.
With alt aio, do we sync in the context of the I/O thread?
Thanks,
Rob
Phil Carns wrote:
One thing that we noticed while testing for storage challenge was that
(and everyone correct me if I'm wrong here) enabling the
.
This is technically possible with alt aio, though- you would just need
to pass a flag through to tell the I/O thread to sync after the
pwrite(). That would probably be pretty helpful, so the trove worker
thread doesn't get stuck waiting on the sync...
-Phil
Rob Ross wrote:
This is similar
Did we reach any sort of consensus on this idea?
Rob
Phil Carns wrote:
We've run into a couple of scenarios lately where a broken metadata file
can cause the server to crash. The latest one looks like this:
--
- a metadata file exists, but the db entry for its datafile
Hi all,
Our colleagues in Potsdam have performed an analysis of the BMI TCP
module, looking for opportunities for performance improvement:
http://www.cs.uni-potsdam.de/bs/research/cluster/bmi/bmitcp_analysis.pdf
Thanks Lars for letting us know about this!
Rob
the good news is that the new structure that they've added:
struct niovec
{
void __user *iov_base;
__kernel_size_t iov_len;
__kernel_loff_t iov_off; /* NEW */
};
allows one to do a very limited version of list I/O through the kernel.
minor step in the right
it would be worth placing an upper bound on the # of concurrent
operations to see if this has an impact on the 128 client case; could be
that the servers just don't do that well when there are that many
concurrent operations. i note that the 32 server case is the only
alt-aio read case that
Hi all,
We always try to get good documentation on our code, but I don't think
that it is fair to say that the older code is much better than the newer
code. Except that maybe we've had more time go to back and add comments.
I'm not sure what you mean by well written code being a cultural
Hi,
Currently there is no check for free space performed. It would be
difficult to actually *know* if there is enough space or not, because
current interfaces don't actually provide a way to say something about
the size of a file at create time. However, a smarter implementation
could
Sounds like formalizing this would be a good idea. Is there even one
counter-example that we can think of or that exists today?
Rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 19 Oct 2006 16:34 +0200:
We've plugged some similar bugs before by just fixing the specific case
(being more
Sure! I think that the small values really only make sense for systems
where TCP is being used with small kernel buffer sizes.
We're working on a tuning document describing starting points for many
of these parameters on various types of systems.
Rob
Scott Atchley wrote:
On Oct 19, 2006,
A little off-topic, but the sprintf() approach is because MPI chose to
use character strings as a portable format for hints. Very different set
of constraints than us, makes a lot of sense in that set of constraints.
Rob
Sam Lang wrote:
I view the underlying storage of the parameters and the
with XML! ;-)
Walt
Sam Lang wrote:
On Oct 7, 2006, at 2:09 PM, Rob Ross wrote:
I agree completely with Pete. I think we might consider just
adjusting the input parameters on the client side to allow for
inclusion of the list of aliases. There is no reason for these to be
stored as part
I agree completely with Pete. I think we might consider just adjusting
the input parameters on the client side to allow for inclusion of the
list of aliases. There is no reason for these to be stored as part of
the distribution information on the server, as once the objects are
created we
hey,
can you come up with a list of people for the BOF, ask pete what he
thinks, etc? i'd like to see if we can invite people this week.
didn't make it out of ohare until 6am this morning, further behind
schedule...
rob
Robert Latham wrote:
Here's the information about the Ames guys
i apologize for sending this out to everyone, but since i did, please
come to the BOF at SC :).
at least my excuse was imbedded in the email...
rob
Rob Ross wrote:
hey,
can you come up with a list of people for the BOF, ask pete what he
thinks, etc? i'd like to see if we can invite people
as an aside, the accepted way to hide this sync cost is preallocation of
unused objects. just keep them around and drop them into place when needed.
that would cost one direntry write and sync, plus perhaps another
write/sync to note that the object isn't unused any more.
rob
Sam Lang
Hi all,
Since I'm being discussed, I thought that I should chime in :).
I agree that what we're talking about here is just a couple of steps in
the right general direction, not where we would really like to be in the
long run.
The zero-conf concept sounds great to me, conceptually. However,
Results on 9/18 on lain includes:
---
End of Log File
pvfs2_file_read: error writing to handle 3221225471, -- returning -110
pvfs2_file_read: error writing to handle 3221225471, -- returning -110
pvfs2_file_read: error writing to handle 3221225471, -- returning -110
pvfs2_file_read: error
80K clients...
Murali Vilayannur wrote:
Hi Rob,
Quick uneducated question: this isn't automatically done on *every*
mount, right?
yeah, it is done automatically on every *new* mount upcall. Is this a
problem? (I changed the code to this behavior y'day night)
thanks,
Murali
Rob
Phil
this..
Are you ok with having a flag to the isys_fs_add and fs_add API that
determines whether or not we should do these checks and have ping set the
flag to 1 and client-core set to 0?
thanks,
Murali
On Tue, 12 Sep 2006, Rob Ross wrote:
80K clients...
Murali Vilayannur wrote:
Hi Rob,
Quick
RobL or someone may have a file for things to ignore?
Rob
Walter B. Ligon III wrote:
Ignore this - I upgraded valgrind and it went away.
Now if I can just figure out what all this valgrind output means :-(
Walt
Walter B. Ligon III wrote:
has anyone run the server with valgrind?
I have a
Thanks! -- Rob
Scott Atchley wrote:
Hi Rob,
I will ping them. We can easily expand the bits for the peer id to 20
(or even 24).
Scott
On Aug 23, 2006, at 11:13 AM, Rob Ross wrote:
Hi Scott,
You might want to ping your colleagues at ORNL and see how many
distinct peers they expect
Thanks for the update Walt. We eagerly await word that we should start
playing!
Rob
Walter B. Ligon III wrote:
Sam, all of the code is written but I am debugging it as we speak.
There will probably be some more interim checkins on the branch today,
but until my testing is done I won't start
i think that warrants an assert too. using asserts to check
preconditions in functions seems like a reasonable thing to do.
rob
Walter B. Ligon III wrote:
I'm wanting to check the group's collective wisdom on the use of assert
as opposed to a comparable check and error via gossip.
It
aren't we supposed to be converting the BDB error codes to our own
somewhere?
Sam Lang wrote:
On Jun 15, 2006, at 4:06 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 15 Jun 2006 14:59 -0400:
ret = op_p-coll_p-ds_db-get(op_p-coll_p-ds_db,
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 30 May 2006 09:28 -0400:
Which is more common in compilers:
static struct foo foobar = {
field1: value1,
field4: value4
};
OR what's shown below:
static struct foo foobar = {
.field1 = value1,
Thanks Kyle and Pete! -- Rob
___
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
at this point...one extra step for them so that we do the
right thing for the masses seems reasonable...
rob
Robert Latham wrote:
On Thu, May 25, 2006 at 02:05:23PM -0500, Rob Ross wrote:
why don't we add a configure test that executes code to see if we get
ENOSYS?
that might be a good-enough solution
what kernel version(s)? -- rob
Pete Wyckoff wrote:
Lee, I'm forwarding your mail to the developers. Hopefully somebody
will notice and guess what's wrong. I'm having similar issues with
the 2.4 version on some old vendor-supplied kernel too, but figured
it was just a local problem.
good catch on the aiocb stuff avery; that one has been in there for
years i would guess.
rob
Avery Ching wrote:
On Thu, 2006-05-18 at 17:26 -0500, Robert Latham wrote:
Thanks for the patches. tracking down these bugs can be a big pain.
good job, man. just a few questions.
On Thu, May 18,
Hi Antonio,
While it's possible that you're getting misleading error messages, the
most likely problem is that you've got new client libraries but an old
server (thus the Server is too old for your client message).
Have you (or someone) installed more than one version of PVFS2 on the
system
Hi Phil,
Yes, it seems reasonable to just tell the kernel that they aren't there
in the case that ACLs are disabled. However, this might lead to a weird
situation if a user then decides to play with or set these values. Is it
possible for a user to adjust ACLs even if the file system mount
hi dean,
what version were you running prior to this?
thanks,
rob
Dean Hildebrand wrote:
I just tried the latest cvs pvfs2 code, and I'm now getting the
following output on a Intel Xeon 32bit machine running fc4: [D
12:35:21.193168] PVFS2 Server version 1.4.1pre1-2006-05-01-162933 starting.
structures just happened to line up? -- rob
Murali Vilayannur wrote:
Hi,
In src/kernel/linux-2.6/pvfs2-utils.c, I see
pvfs2_inode_setattr
new_op-upcall.type = PVFS2_VFS_OP_SETATTR;
new_op-upcall.req.setattr.refn = pvfs2_inode-refn;
if
what happens in the case where we don't support sendfile and someone
wants to run apache?
i think disabling by default is the right thing to do, allow this to be
turned on with a configure option as you've done here. we will need to
add an additional set of automated tests somewhere to make
Ok. Sounds like we've got a good solution:
- sendfile off by default
- FAQ entry re: Apache suggests:
- EnableSendfile Off, or
- recompile with --enable-sendfile
Build tests mainly, so if something changes we don't find out by a user
having compile problems.
Thanks!
Rob
Murali
Thanks Brian for reporting this. We should be able to hide this at
pvfs2-client.
Rob
Brian D. Haymore wrote:
We have seen an odd quirk twice now. We are using pvfs2-1.4.0 on RedHat
EL 4 AS x86_64 kernel version 2.6.9-34.ELsmp. What we have seen is that
we had one of our 12 IO servers lock
We should fix that misleading server message. -- Rob
Robert Latham wrote:
On Tue, Apr 18, 2006 at 10:44:40AM -0500, Jeff Pummill wrote:
Rob,
It's kinda weird how the -r is behaving...
[EMAIL PROTECTED] sbin]# ./pvfs2-server /etc/pvfs2-fs.conf
/etc/pvfs2-server.conf-pvfs2-meta-server-0-0 -r
, PVFS_BYTE,mem_req);
you help me?
thanks
On 3/29/06, Rob Ross [EMAIL PROTECTED] wrote:
hi antonio,
you want something like this i think:
PVFS_request_hvector(2, 2*N, 3*N, PVFS_BYTE, blk);
count = 2
block length (how many contiguous elements in a block) = 2 * size
stride (skip from one start
behind. At least 1 order of magnitude slower than normal
read/write.
Avery
On Fri, 2006-03-24 at 10:49 -0600, Rob Ross wrote:
Nice Phil. I saw this exact same sort of stalling eight years ago on
grendel at Clemson! But we didn't have alternative schedulers and the
like to play with at the time
No documentation or references on the eager I/O, other than the code itself.
Rob
Peng Gu wrote:
Hi Rob,
I want to test I/O performance on PVFS2, so I want to know what kind
of benchmark do you typically use, especially for small file I/O ( you
are working on eager I/O to address the small
I don't consider rmdirent to be a case that we need to highly optimize,
so if it helps to lookup the name and do the getattr beforehand, that's
cool by me. I'm sure somewhere out there there is a rmdir test that
we'll do a little worse on, but whatever.
You'll still have to getattr again
Sam Lang wrote:
On Dec 19, 2005, at 6:07 PM, Rob Ross wrote:
I don't consider rmdirent to be a case that we need to highly
optimize, so if it helps to lookup the name and do the getattr
beforehand, that's cool by me. I'm sure somewhere out there there is
a rmdir test that we'll do
99 matches
Mail list logo
