Hi, before people look for the man page in vain: although there is actually a lfs-migrate(1) man page in 2.8 sources it doesn't seem to be installed...
Page was added in [1] (included in 2.8) but only added to the Makefile.am in [2] (which will be part of 2.10). Regards Henri [1] https://review.whamcloud.com/#/c/17392 [2] https://review.whamcloud.com/#/c/24371 On 04/avril - 22:20 Dilger, Andreas wrote: > There is the "lfs-migrate.1" man page that has a few more details, though it > would be great if someone had the time to add more details on each of the > options. > > On Apr 4, 2017, at 01:18, Henri Doreau <[email protected]> wrote: > > > > 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 <[email protected]> wrote: > >> > >>> On 20/mars - 22:50 E.S. Rosenberg wrote: > >>>> On Mon, Mar 20, 2017 at 10:19 PM, Dilger, Andreas > >>>> <[email protected]> > >>>> 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 > >>> > > Cheers, Andreas > -- > Andreas Dilger > Lustre Principal Architect > Intel Corporation > > > > > > > -- Henri Doreau _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
