> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Christopher J. Walker
>
> Metadata operations are always going to be expensive - though I think
> Lustre may well be slower than NFS - though that's experience of 1.8 and
> 2.5 is now out. We made sure our MDS was high spec with a fast CPU and
> disks. It's a small fraction of the total system price, and would be a
> shame to kill performance there.
>
> One thing that does cause extra load is looking up file attributes (as
> colourised ls does).
The problem is anything that stats a whole heap of files,
which coloured ls does, and it exposes an interesting corner
of Lustre's design - most of the metadata lives on the metadata
server (of course) and pure metadata operations can be very fast
if they're basically fairly light streaming reads from the MDS.
What trips Lustre up for statting files is that the MDS keeps a
lazy idea of the file size so that it doesn't need to be kept in
the loop as a client is writing a file to the storage server(s);
that's good, but when you stat a file it forces it to go off to
the storage servers to get the accurate size. So, while statting a
file might sound like a pure metadata operation, in Lustre, it's
not actually a pure metadata server operation.
All that said though, the performance is at a level that I'd
characterise as 'noticeably slower', not 'problematic' - a user
doing a long listing isn't likely to care, but a script doing the
equivalent a lot might.
Ewan
|