Re: [HPDD-discuss] lfs migrate

I have used lfs migrate --block in the past to move files that were in use. It works for files that are being read, but will fail with a message if they are being written to (as expected). Seems to be safe for files in either case. I'd limit the # of migrates per OST to a traditional number, optimally 1, but 2 or 4 at most. I generally used it when trying to increase the stripe width on a file that was being read heavily, and it's a great tool for that. It seems to do a pretty slow copy, single threaded, so it's not the fastest method. I've written scripts that will launch a job per file and use this to rebalance file systems, and it seemed to work well for a decent set of data, but not nearly 500 TB. For that amount of data you might want to consider weighing the costs of a lfs migrate (time spent burning up compute nodes/data mover nodes) vs. the time you'd spend with a high speed parallel copy (dcp) + a resync at a downtime. I assume you don't have a purge policy where you could just let the file system rebalance naturally over time? Shawn On Thu, 2014-09-04 at 12:59 -0400, Robin Humble wrote: