Re: NFSv4/pNFS possible POSIX I/O API standards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I don't think that the group intended that there be an opendirplus(); rather readdirplus() would simply be called instead of the usual readdir(). We should clarify that.

Regarding Peter Staubach's comments about no one ever using the readdirplus() call; well, if people weren't performing this workload in the first place, we wouldn't *need* this sort of call! This call is specifically targeted at improving "ls -l" performance on large directories, and Sage has pointed out quite nicely how that might work.

In our case (PVFS), we would essentially perform three phases of communication with the file system for a readdirplus that was obtaining full statistics: first grabbing the directory entries, then obtaining metadata from servers on all objects in bulk, then gathering file sizes in bulk. The reduction in control message traffic is enormous, and the concurrency is much greater than in a readdir()+stat()s workload. We'd never perform this sort of optimization optimistically, as the cost of guessing wrong is just too high. We would want to see the call as a proper VFS operation that we could act upon.

The entire readdirplus() operation wasn't intended to be atomic, and in fact the returned structure has space for an error associated with the stat() on a particular entry, to allow for implementations that stat() subsequently and get an error because the object was removed between when the entry was read out of the directory and when the stat was performed. I think this fits well with what Andreas and others are thinking. We should clarify the description appropriately.

I don't think that we have a readdirpluslite() variation documented yet? Gary? It would make a lot of sense. Except that it should probably have a better name...

Regarding Andreas's note that he would prefer the statlite() flags to mean "valid", that makes good sense to me (and would obviously apply to the so-far even more hypothetical readdirpluslite()). I don't think there's a lot of value in returning possibly-inaccurate values?

Thanks everyone,

Rob

Trond Myklebust wrote:
On Mon, 2006-12-04 at 00:32 -0700, Andreas Dilger wrote:
I'm wondering if a corresponding opendirplus() (or similar) would also be appropriate to inform the kernel/filesystem that readdirplus() will follow, and stat information should be gathered/buffered. Or do most implementations wait for the first readdir() before doing any actual work anyway?
I'm not sure what some filesystems might do here.  I suppose NFS has weak
enough cache semantics that it _might_ return stale cached data from the
client in order to fill the readdirplus() data, but it is just as likely
that it ships the whole thing to the server and returns everything in
one shot.  That would imply everything would be at least as up-to-date
as the opendir().

Whether or not the posix committee decides on readdirplus, I propose
that we implement this sort of thing in the kernel via a readdir
equivalent to posix_fadvise(). That can give exactly the barrier
semantics that they are asking for, and only costs 1 extra syscall as
opposed to 2 (opendirplus() and readdirplus()).

Cheers
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux