[PVFS-users] pvfs becoming unavailable/deathly slow

Robert Latham robl at mcs.anl.gov
Tue Jan 4 09:45:22 EST 2005


On Tue, Jan 04, 2005 at 08:51:22AM -0500, Brian K. Jones wrote:
> lstat64("/mnt/pvfs/jonesy/hrdavid/eyes6-sweep-0-trans--07-rot-63-sub-0_xf.ply", {st_mode=S_IFREG|0644, st_size=11878266, ...}) = 0
> getxattr("/mnt/pvfs/jonesy/hrdavid/eyes6-sweep-0-trans--07-rot-63-sub-0_xf.ply", "system.posix_acl_access", (nil), 0) = -1 EOPNOTSUPP (Operation not supported)
> ============================================================================
> 
> 
> Any clues on how to get rid of these messages? If it weren't for these
> attempts to resolve things that apparently aren't supported by the
> filesystem, standard linux "ls" would be fine. 

PVFS doesn't support extended attributes (the getxattr system calls).
I don't think that's much of your delay, as unsupported VFS routines
can be handled w/o a network round trip.  (we don't provide a pvfs1
function to handle the kernel's generic getxattr).  The delay is
because for each file in the directory, the metadata has to contact
every IO server to compute the file size.  All these round trips add
up.  If it makes you feel any better, it used to be worse :>

Offhand, I can't think of ways to make linux ls a whole lot faster in
PVFS1.  You might see better performance with a newer version of
PVFS1, but linux ls on directories with a lot of files is just
something PVFS1 can't do so quickly.

==rob

-- 
Rob Latham
Mathematics and Computer Science Division    A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA                B29D F333 664A 4280 315B


More information about the PVFS-users mailing list