On 11/17/2010 03:34 AM, Christoph Hellwig wrote:
On Tue, Nov 16, 2010 at 09:05:06AM -0600, wkendall@xxxxxxx wrote:
Pathname resolution in xfsrestore is about 4x faster if the file
containing dirent names ("namreg") is memory mapped. If xfsrestore is
unable to map the file (e.g., due to virtual memory constraints)
fallback to the existing seek-and-read approach.
The file is mapped after all directory entries have been written to
the "namreg" file. If the caller tries to add additional entries after
the file has been mapped, it will be unmapped and restore will resort
back to seek-and-read lookups.
Signed-off-by: Bill Kendall<wkendall@xxxxxxx>
Reviewed-by: Alex Elder<aelder@xxxxxxx>
Generally looks good to me, but I really hate how namreg_map/unmap
are hidden under namreg_add/flush. As a start instead of adding the
done_adding argument we can easily move the explicit map to the one
caller wanting it, similarly namreg_unmap could be moved to namreg_add,
that is manage to mapping/unmapping explicitly.
I'll rework this.
In fact I'm not sure what the point of the unmap/map cycles is. At
least in Linux concurrent buffer writes and mmap reads are coherent.
Adding an entry extends the file beyond what is mapped. The unmap
code was merely defensive, in case namreg_add is called somewhere
after the file is mapped. I spent some time looking at the callers,
and all namreg_adds occur before the file is mapped. namreg_del is
called after the file is mapped, but as it doesn't do anything this
is not a problem. I'll remove the unmap code.