We've used lfs migrate on Lustre 1.8 and 2.1.6, and are quite happy with
it. With 2.1.6, the caveat is that the files must not be in use when
they are migrated. I'm not sure what it may be with 2.5.
I run only 5 migrators at once as the limitation is access to the mdt
database. We try to keep the iostat on that device away from the 100%
mark. :-) You could add more migrator processes if that metric looks
good to you. I've never run more that 5 with 2.1.6, but ran as many as
10 with 1.8.
A typical tack I take is to do an "lfs find" with output to a text file,
of all the OST I want to migrate. Split that file N ways, and then run
N migrators (I run them one per client machine), with only those OST you
want to write to enabled for writes.
bob
On 9/4/2014 12:59 PM, Robin Humble wrote:
Hiya,
has anyone used 'lfs migrate [--block]' to live migrate lots of data?
it worked ok?
any hints for best usage? (how many migrates running per OST etc.)
the context is that we've doubled our number of OSTs and now need to
rebalance our ~1 PB of data by moving roughly 1/2 of it onto the new
empty OSTs.
I have yet to chat to anyone who's used 'lfs migrate' (either directly
or via lfs_migrate) in production, so I'm being paranoid and looking
for comforting war stories where it's been used to shift around a lot
of data without problems...
documentation is a bit scarce. maybe just
https://jira.hpdd.intel.com/browse/LU-2445
and 'lfs help migrate'. but with --block it sounds pretty amazing.
it should be able to do the rebalance live and without a downtime
(with some delays to file access).
we're using the latest(?) Intel Enterprise Lustre version 2.0.1.1
(which appears to be 2.5.2 based). we've heard via Intel support that
'lfs migrate' runs a verify pass, which sounds nice.
cheers,
robin
--
Dr Robin Humble
_______________________________________________
HPDD-discuss mailing list
HPDD-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/hpdd-discuss