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

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

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 s...
• is related to: LU-9349 PFL known issues tracking ticket

Comments

[Peter Jones]

Niu

Could you please assist with this one?

Thanks

Peter

[Niu Yawei (Inactive)]

hmm, I think the key problem here is that should we regard non-composite file as component-count=0 file? My original implementation treats them differently, because I don't think it's not proper to define the component count of a non-composite file as 0 or 1.

So component count of a non-composite file is neither 0 nor 1, it should match both "! comp_count=0" and "! comp_count=1", isn't it?

[Andreas Dilger]

I think that the command needs to return something in this case, otherwise it makes it difficult to write a script which handles the results. Returning a component count of "0" makes sense to me, since it is not a composite file and it has no (zero) components.

[Niu Yawei (Inactive)]

Then what about --component-id, --component-flags, etc? Should we return error message when user try to use component options for a non-composite file? A side effect of returning error message is it will interfere the output parsing for a mixed options getstripe (when user perform getstripe with mixed options to a set of files)

[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.

[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.

[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.

[Zhenyu Xu]

I vote 4.

[Andreas Dilger]

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

[John Hammond]

I vote 4.

[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.

[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

[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

[Peter Jones]

Landed for 2.10