Whamcloud - gitweb
LU-5549 mdc: cl_default_mds_easize not refreshed
The client_obd::cl_default_mds_easize field should track the largest
observed EA size advertised by the MDT, subject to a reasonable upper
bound. The MDC uses cl_default_mds_easize to calculate the initial
size of request buffers. The default value should be small enough to
avoid wasted memory and excessive use of vmalloc(), yet large enough
to accommodate the common use case.
In the current code, the default value is only updated if
client_obd::cl_max_mds_easize is strictly less than
mdt_body::mbo_max_mdsize. This condition is almost never met, because
client_obd::cl_max_mds_easize is computed at client mount-time based
on the number of OSTs in the filesystem, so the MDT won't ever observe
and advertise an EA size larger than that.
As a result, client_obd::cl_default_mds_easize indefinitely retains
its initial value, which is computed at client mount-time based on
the filesystem's default stripe width. Any getattr() requests for
widely striped files will consequently allocate a request buffer
that is too small, forcing reallocations on both the client and
server side. To avoid this, update client_obd::cl_default_mds_easize
independently of the value of client_obd::cl_max_mds_easize.
In addition, this patch includes these changes:
- Add comments to the client_obd structure to clarify what the
cl_{default,max}_mds_{cookie,ea}size values mean.
- Prevent mdc_get_info() from storing uninitialized data in
client_obd::cl_max_mds_cookiesize.
- Use 4096 as an upper bound for the default values. The former
bound of PAGE_CACHE_SIZE is too large on 64k-page platforms
(i.e. PPC), so it fails to prevent the vmalloc() spinlock
contention described in LU-3338. The new value was chosen to
be large enough to accommodate common use cases while staying
well below the 16k threshold at which allocations start using
vmalloc().
- Add test case 27E to ./lustre/tests/sanity.sh.
Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Kyle Blatter <kyleblatter@llnl.gov>
Change-Id: I363017844d6af3e6b67b7c03bd206226f9495116
Reviewed-on: http://review.whamcloud.com/11614
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>