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-6052 Lustre <p>"lfs mv" caused some confusion between mv and lfs mv. So we better to change lfs mv to lfs migrate -M.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[12/18/14, 2:50:08 PM] Andreas Dilger: we could still use "lfs migrate -M {mdt_idx} /path/to/file" to migrate files across MDTs if everyone thinks "lfs mv" is a bad name for the command? [12/18/14, 2:52:34 PM] Andreas Dilger: like "lfs migrate -i {ost_idx} /path/to/file" is to migrate objects across OSTs [12/18/14, 2:53:01 PM] wangdi: yes, we can do that. or just use lfs mdt_migrate as John suggested [12/18/14, 2:53:48 PM] wangdi: but lfs migrate is bounded with lfs_setstripe, not sure whether add another parameter is good thing [12/18/14, 2:53:50 PM] wangdi: {"migrate", lfs_setstripe, 0, "migrate file from one OST layout to " "another (may be not safe with concurent writes).\n" [12/18/14, 2:54:31 PM] wangdi: anyway, either way is fine to me [12/18/14, 2:58:14 PM] Andreas Dilger: Di: lfs_migrate() could parse the "-M" option before calling lfs_setstripe() if just migrating the inode. if it is migrating the objects also, then we may as well just use lfs_setstripe() and create the volatile file on the right MDT in the first place. </pre> </div></div> LU-6052

Change "lfs mv" to "lfs migrate -M"

Bug Critical Resolved Fixed Lai Siyao Di Wang Thu, 18 Dec 2014 23:02:26 +0000 Wed, 29 Jul 2015 15:58:42 +0000 Wed, 29 Jul 2015 15:58:42 +0000 Lustre 2.8.0 Lustre 2.8.0 0 10 <p>Is there a use case for migrating both MDT and OST objects at the same time? If not, then this should be a separate command such as mdt_migrate instead of adding conflicting options to the same command. </p> <p>Robert, it is <em>possible</em> to move the file to both a new MDT and OST(s) at the same time. What would be needed is for lfs.c::lfs_migrate() to specify a desired MDT index when creating the new temporary target file, and then copy the data into this new file. At the end the temporary inode would replace the existing one like lfs_mv() is already doing. That is almost the same as what we were doing with the old code before the MDS could do "client-safe" migration.</p> <p>I don't have any use cases off the top of my head why a user might want to do this. Maybe balancing space for both MDTs and OSTs at the same time?</p> <p>The reason for keeping it in the same command is that the operations are conceptually the same - moving the backing storage of an object from one server to another. I think it should be clear from the context of the command (moving a regular file or directory) whether "stripe count" applies to the number of OST objects or MDT objects, but I haven't looked into the actual implementations to see if there are any other potential conflicts.</p> <p>That said, I don't have a strong opinion on this, just that several people had commented that "lfs mv" was not a very good name for this functionality because it doesn't correspond to moving files to somewhere else in the namespace like "mv" does, and the first choice of command names (namely "lfs migrate") was already used, but I think they are similar enough that they should be the same command.</p> <p>I agree they are conceptually similar, but they are still quite different operations. It's confusing UI to have one command with options to do completely different things, especially when aren't necessarily done together. The set_param mess with -P is an excellent example of that. It's better to have different commands that to perform different operations, and have them all work the same way. Perhaps we can rename the existing migrate to ost_migrate and rename mv to mdt_migrate, and ensure the options for each are consistent where appropriate. Then it's clear which one to use for different types of migration, and they each present the same interface. </p> <p>Actually, I thought the MDT was determined by hashing the filename... How do we support migrating a file to an arbitrary MDT?</p> <p>While the filename in a <em>striped directory</em> determines which directory shard the <em>name</em> is located in, it is possible to store the inode itself on a different MDT, since only the FID determines which MDT the inode is located on, and that can be arbitrarily chosen. It is definitely more efficient to have the name and the inode on the same MDT as the parent directory, but in some cases this isn't possible (remote directories, hard linked files, rename). The <tt>lfs mv</tt> command today will typically migrate whole directory trees to maintain efficiency, but it could be used on individual files if there is a reason to do so (e.g. multi-tiered storage, WAN locality, possibly metadata replication in the future, etc.)</p> <p>As for the name of the lfs sub-commands, I don't see how "mdt_migrate" and "ost_migrate" significantly better than "migrate --mdt-index" (or "migrate -m") and "migrate --ost-index" (or "migrate -o"), but what I really want is something that is easy for users to use and remember.</p> <p>Lai,<br/> Would you be able to take this one?</p> <p>The old <tt>lfs mv</tt> command should be left in place for compatibility reasons, but marked as deprecated.</p> <p>Lai Siyao (lai.siyao@intel.com) uploaded a new patch: <a href="http://review.whamcloud.com/13754" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13754</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6052" title="Change &quot;lfs mv&quot; to &quot;lfs migrate -M&quot;" class="issue-link" data-issue-key="LU-6052"><del>LU-6052</del></a> utils: change "lfs mv" to "lfs migrate"<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 430e16cadf8eeaa04ebcd37431052cf061463c18</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/13754/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/13754/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6052" title="Change &quot;lfs mv&quot; to &quot;lfs migrate -M&quot;" class="issue-link" data-issue-key="LU-6052"><del>LU-6052</del></a> utils: change "lfs mv" to "lfs migrate"<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 849d7d5b1b4cabb7578c3ab5aaf271e90dd33864</p> <p>Landed for 2.8</p> Development Rank 1|hzx2v3: Rank (Obsolete) 16862 Severity