[LU-9424] ‘lfs getstripe --component-count’ return nothing for non-composite files

• Type: Technical task
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.10.0
• Affects Version/s: Lustre 2.10.0
• Labels: pfl
• Assignee: Niu Yawei (Inactive)
• Reporter: James Nunez (Inactive)

Description

I’ve created several composite and non-composite files:

# touch /lustre/scratch/nocomp
# lfs setstripe -E 1M -E 2M -E 3M /lustre/scratch/threecompfile
# lfs setstripe -E 3M /lustre/scratch/onec
# lfs setstripe -E 1m -E 4M /lustre/scratch/twoc

For non-composite (non-PFL) files, I thought the component count would be 0 or 1, but that’s not the case. Using ‘lfs find –component-count’, I know that the component count for the non-composite file, nocomp, is not 0 and not 1:

# lfs getstripe --component-count /lustre/scratch/nocomp 
# lfs getstripe --component-count /lustre/scratch/onec 
1
# lfs getstripe --component-count /lustre/scratch/twoc 
2
# lfs getstripe --component-count /lustre/scratch/threecompfile 
3

# lfs find --component-count 0 /lustre/scratch
# lfs find --component-count 1 /lustre/scratch
/lustre/scratch/onec

# lfs find ! --component-count 0 /lustre/scratch
/lustre/scratch
/lustre/scratch/twoc
/lustre/scratch/onec
/lustre/scratch/nocomp
/lustre/scratch/threecompfile

# lfs find ! --component-count 1 /lustre/scratch
/lustre/scratch
/lustre/scratch/twoc
/lustre/scratch/nocomp
/lustre/scratch/threecompfile

It seems like non-composite files should have a count of 1 or, possibly, 0.

Issue Links

• is related to: LU-9362 PFL: Files with multiple components should not return multiple values for ‘lfs getstripe’
• is related to: LU-9349 PFL known issues tracking ticket

Comments

[Peter Jones]

Landed for 2.10

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/27060/
Subject: LU-9424 tools: v1/v3 as composite layout
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 013baaa0ccac4a1e376081c604f5daacf828bfea

[Gerrit Updater]

Niu Yawei ([e-mail]) uploaded a new patch: https://review.whamcloud.com/27060
Subject: LU-9424 tools: v1/v3 as composite layout
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5cdb8dc668ea4e2aaac833d4155a91db2b9dab04

[Jinshan Xiong (Inactive)]

I vote 4. The reason is that non-PFL file should be handled exactly the same way as single component PFL file.

[John Hammond]

I vote 4.

[Andreas Dilger]

My first preference would be #1 with comp_end=eof, but second choice would be #4.

[Zhenyu Xu]

I vote 4.

[Niu Yawei (Inactive)]

I think current candidate solutions are:
1. 'lfs getstripe' display comp_count=0, comp_id=0, comp_flags=0, comp_start=0, comp_end=0 (or eof?), and keep 'lfs find' not matching plain file on comp options.
2. 'lfs getstripe' display comp_count=0, comp_id=0, comp_flags=0, comp_start=0, comp_end=0 (or eof?), and change 'lfs find' to match plain file on comp options.
3. 'lfs getstripe' display comp_count=1, comp_id=0, comp_flags=0, comp_start=0, comp_end=eof, and keep 'lfs find' not matching plain file on comp options.
4. 'lfs getstripe' display comp_count=1, comp_id=0, comp_flags=0, comp_start=0, comp_end=eof, and change 'lfs find' to match plain file on comp options.
5. 'lfs getstripe' display nothing for comp options, and 'lfs find' doesn't match plain file on comp options. (current behavior)

Andreas, Bobi, which one do you prefer? I prefer 4 or 5.

[Niu Yawei (Inactive)]

Is this change going to be limited in the output of 'lfs getstripe' or are we going to update 'lfs find' as well?

We need some extra effort if the 'lfs find' is going to be updated as well, for example, if someone try to find component count < 5 files by 'lfs find --component-count=-5', should the plain file (with component-count=0) being matched? I think it's reasonable to match plain file for such kind of 'find' if we regard plain as kind of single component file (with comp_cnt=1, comp_id=0, comp_flags=init, comp_start=0, comp_end=eof), and it could be differentiated with real single component file by comp_id=0.

Another problem is that 'lfs getstripe --component-xxx=optional_args' may print nothing as well (when no component satisfy criterion), should we print an error message or just leave it as-is? I prefer to keep it as-is.

[Andreas Dilger]

I would be ok to return 0 for component ID (which is invalid for composite files), and 0 for component flags (since no flags are set). Returning 0 for component count is also a simple way for scripts to know that this is not a composite file, if they want to scan the filesystem for non-PFL files.