[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