Comments questions below... On Fri, 2004-09-03 at 09:57, Dan Stromberg wrote:> Is anyone else seeing slow response from lustre under the following > conditions? > > 1) Start up a large, single-file transfer into a lustre filesystemHow large? and what striping configuration? How is the data being written? I.E. is there a large blocking factor, or are small blocks being written?> > 2) Try to ls (no options needed) a directory in the same lustre > filesystem, from the same lustre clientHow many files are int he directory?> > 3) ls takes a looong time, though not quite as long as it takes for the > file write to completeIf you strace this processes does it slowly make progress during this time? can you run this ls as ''\ls'' so that any coloring, or stat''ing of each file does not happen.> > I saw an ls take 170 minutes yesterday under these conditions. > > Does anyone have a workaround? Or does lustre "just" need finer-grained > locking?This is hard to say, as I dont have a good idea of your configuration or system specifications. Evan -- Evan J. Felix Pacific Northwest National Laboratoy Home of HPCS2 - Top500 #5(Nov2003) #9(June2003) evan.felix@pnl.gov
Dan Stromberg
2006-May-19 07:36 UTC
[Lustre-discuss] slow response due to concurrent access?
Is anyone else seeing slow response from lustre under the following conditions? 1) Start up a large, single-file transfer into a lustre filesystem 2) Try to ls (no options needed) a directory in the same lustre filesystem, from the same lustre client 3) ls takes a looong time, though not quite as long as it takes for the file write to complete I saw an ls take 170 minutes yesterday under these conditions. Does anyone have a workaround? Or does lustre "just" need finer-grained locking? Thanks. -- Dan Stromberg DCS/NACS/UCI <strombrg@dcs.nac.uci.edu>