On Jun 12, 2007, at 8:09 PM, Pete Wyckoff wrote:
This is awesome work. Fascinating that it takes only 1200 lines to
do a FUSE-based implementation compared to the 15k lines in the
current kernel module.
Its probably around the same considering that FUSE has around 12K LOC
and I am using a lot of the existing PVFS client/sysint code.
I would especially encourage a performance comparison. Looking at
latency, small- and large-block throughputs, etc. would be good work
for a conference submission if you are interested in such things.
Busy with a whole bunch of things right now, but I probably will do a
more thorough performance comparison at some point.
Is it true, for instance, that FUSE generates only page-sized reads
or writes? How does that impact performance? Are context switches
more or less of a problem with the FUSE version (compared to stock
pvfs kernel module)?
As far as I can tell, FUSE does page-sized reads and writes unless
you are using direct_io in which case pages are coalesced into 128K
chunks. I've enabled direct_io by default for performance, but the
tradeoff is that sendfile and mmap don't work with direct_io.
I would guess that context switches would probably be comparable to
the pvfs kernel module since they are in principal very similar.
FUSE is a purely synchronous implementation, apparently. What
happens if two processes (e.g., ls foo & ls bar)
This will work - just that one process would block while the other
continues. FUSE does have multithreaded support. However, when its
enabled in pvfs2fuse, weird things start to happen. I havent been
able to track it down yet, so I've turned off multithreaded support
for now.
Some comments on the patch.
The *-apple-* patch to configure.in should come in a different patch
if it is a useful thing. Ditto with the -L spacing changes in
Makefile.in. And the #if __APPLE__ multiple places elsewhere. And
PINT_FSTAB_TYPE fix. Maybe you could break this up into "apple
fixes" and "fuse patch"?
Some of the __APPLE__ #ifs are not necessary anymore since it looks
like they've been addressed in the latest CVS code. I had put them
in the same fuse patch set because I figured most people who would be
using pvfs2fuse would be Mac users. But I can separate them out if
you want.
Any chance you could fix some of the 10 FIXMEs in pvfs2fuse.c? Are
they important?
Not that important. Some are carried over from PVFS code that I
copied. Some are because I wasnt sure what I should be passing to
PVFS code (I've spent maybe only a week looking at PVFS so I'm not
really up to speed on all the ins and outs of the PVFS code)
There is an errant usleep() in some getattr code. Assuming that can
be safely removed. :)
Yep. Some testing code that didnt get deleted. Actually, that led
me to another bug fix that didnt make it into the patch. I've
updated the patch accordingly.
I don't understand how readdir works:
incount = 32
do {
PVFS_sys_readdir(&outcount)
put returned responses into fuse response
} while (outcount == incount)
What happens for a directory that has 31 or 33 files?
The do{} while loop is there to basically read up to 32 dirents at a
time. If there are only 31 files, outcount will be 31, and you fall
out of the loop. If there are 33, outcount will be 32, and you go
through the loop one more time at which time outcount will be 1.
I can never keep track of the style in pvfs. But I think for ifs
and fors you want:
if ((x && foo) || (x && bar))
{
noting the spaces around the various parens, and after the keyword.
Yeah, I'll go through and clean this up. This is not my usual emacs
default style, so I had to fix the emacs automatic indenting by hand.
Does sendfile work? :)
Nope. Didnt implement it since direct_io doesnt support it.
-- Pete
_______________________________________________
Pvfs2-users mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
