Could it be, that, once SmartPools walks a particular part of the file system tree, and it records which files need to be moved, and then goes to another part of the tree to take further inventory, any new files written get skipped, until the job runs again? No, it doesn't work that way. A recent discussion suggests that the use of a folder designation in the filter, rather than "*", may work better.  Would it? No, this should work just as well. For that matter, what is the best practice for directing any newly written, or "in flight" data, to the new NL400 nodes only? What you did sounds pretty appropriate to me.  I'm not sure exactly what you mean by "still collecting in the old node pool". Are you noticing specific files, or merely seeing nonzero utilization? Once the file pool policy was changed to set everything to the NL400 and the SmartPools job finished, all file data should be on the NL400 pool. There are a couple of potential exceptions why that might not be the case including files or directories being manually managed or the SmartPools job not having completed yet, or system data such as the LIN tree being stored on the old nodes. If you're aware of an example of a file that should be on NL400 according to the file pool policy but isn't, you can examine its attributes to help determine what's going on.  Do you know whether there are any files or directories on the cluster which are (intentionally) manually managed? If not, the easiest solution is probably to tell SmartPools to override that and move manually managed files as well.  Using SmartPools for migration will make the eventual removal of the 108NLs faster, but once they're down to very low utilization, you can SmartFail them. It's not like they have to be to absolute 0 before that.
Hi,  We recently upgraded a cluster of Isilon 108NL nodes (OneFS 7.0.1.2) by adding six NL400 nodes to it, which then formed their own node pool. Since we want to retire the old 108NL nodes as part of the upgrade, we ran a SmartPools job whose filter simply was [File name matches "*"] and whose operation was to [Save data to "NL400 pool"] and it successfully moved all the data, hundreds of terabytes, to the new nodes.  However, SmartPools jobs continue to run against data that is, for some reason, still collecting in the old node pool.  Why?  Could it be, that, once SmartPools walks a particular part of the file system tree, and it records which files need to be moved, and then goes to another part of the tree to take further inventory, any new files written get skipped, until the job runs again?  A recent discussion suggests that the use of a folder designation in the filter, rather than "*", may work better.  Would it?  For that matter, what is the best practice for directing any newly written, or "in flight" data, to the new NL400 nodes only?  Any advice appreciated.  Thanks, Don Pichette
Using SmartPools to manage "in flight" data?