Whamcloud - gitweb
LU-1303 mds: integration lod/osp into the stack
- config handler recognizes MDS config and replace LOV/OSC devices
with LOD/OSP
- the devices in MDS stack are setup from bottom to top using
obd_connect() namely MDT->MDD->LOD->OSD, when new OSPs arrive,
they connect to the OSD and LOD connects to every OSP). all the
devices are referenced by exports, preventing them from early
release.
- once the whole configuration is processed, prepare() method of the
top device is called, that in turn call ->prepare() down through
the stack, etc. at this point the stack is considered ready to
access storage, start recovery and do regular processing.
- at umount ->ldo_process_config(LCFG_CLEANUP) is called down through
the stack asking devices to release the resources (like objects
referenced for internal purposes), then the series of calls to
obd_disconnect()'s starting from the top MDT causes all the devices
to become unreferenced and subject to release by zombie thread.
- obd_notify() mechanism is not used by MDT/MDD/LOD/OSD, it's still
used by OSP to be aware of current state:
- to learn when the first connection to OST happens and let
clients to connect to MDS, MDS uses obd_health_check() and
caches positive result.
- during object creation LOD uses dt_statfs() and data returned
by OSP tells LOD whether specific OST active/inactive, space
available, number of precreated objects, etc.
- LOD takes care of striping: it maintains the list of available OST
represented locally by OSP devices. on create, LOD finds suitable
OSPs, create objects by means of OSD API and stores striping info
into a local object. similarly LOD handles object destroy and
UID/GID changes: load striping and execute on them.
- llog is used by OSP as a local library, cookies are not visible out
side of OSP. thus neither MDT nor MDD needs to care about cookies,
prepare buffers. MDD doesn't need to send RPCs to destroy objects
on behalf of evicted clients. all is hidden behind OSP's object
destroy method.
- OSP generates llog records for OST object being destroyed and, once
corresponded local transaction is committed, send OST_DESTROY RPC.
once OST_DESTROY is reported to be committed, corresponded llog
record is cancelled.
- the same logic is used for UID/GID changes.
Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Change-Id: Ifb282ace94f583ffa86020b763f22922e5d0b032
Reviewed-on: http://review.whamcloud.com/4087
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <tappro@whamcloud.com>
28 files changed: