https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-9424 Lustre <p>I’ve created several composite and non-composite files:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># 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 </pre> </div></div> <p>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:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># 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 </pre> </div></div> <p>It seems like non-composite files should have a count of 1 or, possibly, 0.</p> LU-9424

‘lfs getstripe --component-count’ return nothing for non-composite files

Technical task LU-9349 Critical Resolved Fixed Niu Yawei James Nunez pfl Mon, 1 May 2017 21:36:36 +0000 Sat, 3 Jun 2017 04:23:55 +0000 Sat, 3 Jun 2017 04:23:55 +0000 Lustre 2.10.0 Lustre 2.10.0 0 8 <p>Niu</p> <p>Could you please assist with this one?</p> <p>Thanks</p> <p>Peter</p> <p>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.</p> <p>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?</p> <p>I think that the command needs to return <em>something</em> 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.</p> <p>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) </p> <p>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. </p> <p>Is this change going to be limited in the output of 'lfs getstripe' or are we going to update 'lfs find' as well?</p> <p>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 &lt; 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.</p> <p>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.</p> <p>I think current candidate solutions are:<br/> 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.<br/> 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.<br/> 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.<br/> 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.<br/> 5. 'lfs getstripe' display nothing for comp options, and 'lfs find' doesn't match plain file on comp options. (current behavior)</p> <p>Andreas, Bobi, which one do you prefer? I prefer 4 or 5.</p> <p>I vote 4.</p> <p>My first preference would be #1 with <tt>comp_end=eof</tt>, but second choice would be #4. </p> <p>I vote 4.</p> <p>I vote 4. The reason is that non-PFL file should be handled exactly the same way as single component PFL file.</p> <p>Niu Yawei (yawei.niu@intel.com) uploaded a new patch: <a href="https://review.whamcloud.com/27060" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/27060</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9424" title="‘lfs getstripe --component-count’ return nothing for non-composite files" class="issue-link" data-issue-key="LU-9424"><del>LU-9424</del></a> tools: v1/v3 as composite layout<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 5cdb8dc668ea4e2aaac833d4155a91db2b9dab04</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/27060/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/27060/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9424" title="‘lfs getstripe --component-count’ return nothing for non-composite files" class="issue-link" data-issue-key="LU-9424"><del>LU-9424</del></a> tools: v1/v3 as composite layout<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 013baaa0ccac4a1e376081c604f5daacf828bfea</p> <p>Landed for 2.10</p> Related LU-9362 LU-9349 Development Rank 1|hzzbjz: Rank (Obsolete) 9223372036854775807