[PVFS-developers] Faster stats

[Rob Ross]

Ack.

So Phil (who can't get to his email right this second) pointed out that 
the fast stat approach isn't going to work for open files.

The problem is sparse files.  I can write data to one server without 
extending the size on other servers, leading to a case where the original 
"last" byte is still the last byte on that server, but some other server 
has tons of extra data.

So!  We should punt on the open file optimizations, but definitely keep 
the closed file one.

Rob

On Tue, 16 Sep 2003, Porter Don wrote:

> 
> Since you are rolling in patches as of late, I thought I would go ahead and
> try to get this one in as well...
> 
> I noticed that ls -l's on a pvfs volume which either contain a lot of files
> or are under load are extremely slow.  This is because every time a stat is
> called it goes to _every_ iod to tally up the file size.  
> 
> So I thought that perhaps we could store the filesize as of the last stat or
> close on the file in the metadata, which happens to have an unused field for
> filesize (as well as the one in the stat structure). 
> 
> I implemented a check for whether or not a file has changed by calculating
> what the filesize should be on the last iod to be written to.  If this
> filesize has changed, then we know that the others have as well and we
> re-tally the whole thing based on the old algorithm.  If it has not changed,
> we just return the cached size. 
> 
> Further, because the manager tracks which files are open, we only need to do
> this at all on an open file.  Because we write the stat to disk at close
> anyway, we can assume that a closed file has the correct size cached.
> 
> This patch implements this with a run-time flag '-f' (for fast stats).  If
> this flag is not set, the old behavior should be used.  Thus, it is a bit
> more painless switch.  If everyone likes it, we can take out the old code
> and have it always do what is in the 'if(fast_stats){}' loops.
> 
> I have only done performance testing on small clusters with 3 iods, but with
> 3 clients reading and writing a file, a 4th client's ls -l time dropped from
> 8.4 s to 0.6 s.  Under no load on this small cluster, there was on average a
> 50% speedup.  I think that on larger and more loaded clusters the
> performance increase should be more dramatic.
> 
> Like I said, I was waiting to get to do a little testing on a larger
> cluster, but since you are rolling in patches anyway....
> 
> Thanks,
> don
> 
>