[lustre-discuss] lfs_migrate

Henri Doreau henri.doreau at cea.fr
Tue Apr 4 00:18:07 PDT 2017


Hello,

the manpage for lfs(1) lists the available options in 2.8:
"""
lfs migrate -m <mdt_index> directory
lfs migrate [-c | --stripe-count <stripe_count>]
               [-i | --stripe-index <start_ost_idx>]
               [-S | --stripe-size <stripe_size>]
               [-p | --pool <pool_name>]
               [-o | --ost-list <ost_indices>]
               [-b | --block]
               [-n | --non-block] file|directory
"""

Although this is certainly terse, I guess that most parameters are intuitive.

The command will open the file to restripe (blocking concurrent accesses
or not, depending on -b/-n), create a special "volatile" (=unlinked) one
with the requested striping parameters and copy the source into the
destination.

If the copy succeeds, the two files are atomically swapped and
concurrent access protection is released.

In non-blocking mode, the process will detect if the source file was
already opened or if there's an open during the copy process and abort
safely. It is then up to the admin to reschedule the migration later,
maybe with -b.

HTH

Henri

On 02/avril - 14:43 E.S. Rosenberg wrote:
> Thanks for all the great replies!
> 
> I may be wrong on this but 'lfs migrate' does not seem to be documented in
> the manpage (my local one is 2.8 so I expect that but even manpages that I
> find online).
> 
> Any pointers would be very welcome.
> 
> On Thu, Mar 23, 2017 at 12:31 PM, Henri Doreau <henri.doreau at cea.fr> wrote:
> 
> > On 20/mars - 22:50 E.S. Rosenberg wrote:
> > > On Mon, Mar 20, 2017 at 10:19 PM, Dilger, Andreas <
> > andreas.dilger at intel.com>
> > > wrote:
> > >
> > > > The underlying "lfs migrate" command (not the "lfs_migrate" script) in
> > > > newer Lustre versions (2.9) is capable of migrating files that are in
> > use
> > > > by using the "--block" option, which prevents other processes from
> > > > accessing or modifying the file during migration.
> > > >
> > > > Unfortunately, "lfs_migrate" doesn't pass that argument on, though it
> > > > wouldn't be hard to change the script. Ideally, the "lfs_migrate"
> > script
> > > > would pass all unknown options to "lfs migrate".
> > > >
> > > >
> > > > The other item of note is that setting the OST inactive on the MDS will
> > > > prevent the MDS from deleting objects on the OST (see
> > > > https://jira.hpdd.intel.com/browse/LU-4825 for details).  In Lustre
> > 2.9
> > > > and later it is possible to set on the MDS:
> > > >
> > > >    mds# lctl set_param osp.<OST>.create_count=0
> > > >
> > > > to stop MDS allocation of new objects on that OST. On older versions
> > it is
> > > > possible to set on the OSS:
> > > >
> > > >   oss# lctl set_param obdfilter.<OST>.degraded=1
> > > >
> > > > so that it tells the MDS to avoid it if possible, but this isn't a hard
> > > > exclusion.
> > > >
> > > > It is also possible to use a testing hack to mark an OST as out of
> > inodes,
> > > > but that only works for one OST per OSS and it sounds like that won't
> > be
> > > > useful in this case.
> > > >
> > > > Cheers, Andreas
> > > >
> > > You're making me want Lustre 2.9 more :) but for now I'm still stuck on
> > 2.8
> > > and because this is very much production these days I'm more careful with
> > > the update (hoping to finally get hw allocated for a test env soon to
> > test
> > > the update).
> > > Thanks,
> > > Eli
> > >
> >
> > Hello,
> >
> > this safer version of `lfs migrate' (LU-4840) is actually available in
> > 2.8.
> >
> > When used with --non-block flag, a concurrent open of the file being
> > migrated will cause the migration to fail. With --block (or nothing,
> > it's the default behavior) and as Andreas said, concurrent opens will
> > block until the migration completes.
> >
> > Regards
> >
> > --
> > Henri Doreau
> >



More information about the lustre-discuss mailing list