[LU-8092] racy striping & default striping cache in LOD

• Type: Bug
• Resolution: Unresolved
• Priority: Minor
• Severity: 3
• Assignee: WC Triage
• Reporter: Niu Yawei (Inactive)

Description

striping & default striping cache in LOD layer looks racy:

1. striping cache

lod_load_striping() is used for loading striping for regular file (LOV) or directory (LMA), caller usually calls lod_load_striping() to load striping into cache first (see lod_object), then performs following operations which relies on the cached striping. However, there isn't a mechanism in LOD to prevent the cache from being freed before the operations done. External means are used to avoid such race in current Lustre:

• For regular file, all the operations (create, setstripe, destroy, chown, lfsck) requires striping information (load striping cache & free striping cache) will hold LDLM ibits lock, that guarantees no concurrent striping free on the object;

• For directory, the striping information (LMV) is immutable in most cases, so there won't be a concurrent striping free (except LFSCK, so it's not 100% race free);

I think we'd reorgnize the code to avoid such kind of race in LOD but not rely on external means.

2. default striping cache

In lod_ah_init(), default striping (both default LOV and LMV) in parent directory will be loaded into LOD cache (see lod_object), then it'll be propagated to the child file/directory being created (child's lod_object). Because multiple lod_ah_init() against same parent could be called in parallel, and the default striping in parent could be changed at the same time, we probably need to protect the whole lod_ah_init() with dt_read/write_lock(parent).

Issue Links

• is related to: LU-7660 FS default striping settings only honored on MDT 0