Data-on-MDT phase II (LU-10176)

[LU-10177] DoM: manual migration MDT-OST Created: 09/Dec/16  Updated: 11/Feb/19  Resolved: 06/Oct/18

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.12.0

Type: Technical task Priority: Major
Reporter: Mikhail Pershin Assignee: Mikhail Pershin
Resolution: Fixed Votes: 0
Labels: DoM2

Issue Links:
Cloners
is cloned by LU-11421 DoM: manual migration OST-MDT, MDT-MDT Resolved
Related
is related to LU-11508 DoM file data missing after doing DNE... Resolved
is related to LU-3285 Data on MDT Resolved
is related to LU-10258 lfs mirror command to read/write spec... Resolved
is related to LU-10910 LBUG with "lfs migrate -c 1 <domfile>" Resolved
Rank (Obsolete): 9223372036854775807

 Description   

Make migration for DoM files with LFS command. This is not working out-of-box for Data-on-MDT files because it is not enough just change layout, data should be moved as well.



 Comments   
Comment by Mikhail Pershin [ 04/Jan/17 ]

1) MDT to OST migration
DOM layout + data on MDT -> OST layout + data on OST

  • create volatile file (OST new layout);
  • move data from DOM file to volatile file;
  • swap layout (old DOM inode + new layout on OST);
  • delete data on MDT by truncating local inode on MDT (*** new step). It is not trivial case too, need special code path.

2) OST to MDT
OST layout + data on OSTs -> DOM layout + data on MDT

  • no sense to create volatile file, because its data will be tied to its new MDT inode, but we want to keep data with the old inode. We need to read data from OSTs stripes and write it to the inode blocks on MDT (like to the DOM file)
  • set DOM pattern to the original file
  • create volatile file with the same OST layout (replica)
  • copy data from it to the old file with DOM pattern
  • delete stripes from the original file layout
  • delete replica
Comment by Andreas Dilger [ 25/Nov/17 ]

This should be able to use the existing FLR code paths on the client to open the MDT and OST components of the file for read/write to write under the other component. For some time at least this would become an FLR mirrored file, which is desirable to allow in any case. For FLR the DoM component would be preferred if the file size is below MDT size limit, and the OST component would be preferred if the file size is larger.

Comment by Gerrit Updater [ 10/Aug/18 ]

Mike Pershin (mpershin@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/32979
Subject: LU-10177 lfs: support DOM-to-OST migration
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: ce9af3080a1cc66eacb647940aa9b3502641c19c

Comment by Andreas Dilger [ 11/Aug/18 ]

How much work will it be to be able to do the reverse - to be able to migrate small files to the MDT? I'm thinking that the FLR resync ioctl to open the MDT component to "write behind" the OST object and then just drop the OST component.

Comment by Mikhail Pershin [ 11/Aug/18 ]

well, my idea was to make that manually first with steps like:

  • lfs mirror extend -N <new DOM layout> <some non-dom file>
  • lfs resync
  • lfs split --mirror-id 1 -d

and make it work, it is not working just out of box and requires code update to make DOM code understand FLR cases, e.g. DOM component can be not first one with FLR, but still should be first one inside a mirror, also we need to allow only one DOM component in all mirrors and so on.
I think that will be good as first step, at least simple script will be able to migrate files to MDT like that and Lustre code will be ready for FLR+DOM configurations. I'd say it shouldn't take a lot of time, but let me do more checks first.

Next step will be implementing that in code as single call, probably with some optimizations.

Comment by Gerrit Updater [ 05/Oct/18 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/32979/
Subject: LU-10177 lfs: support DOM-to-OST migration
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: f651470c13f83bc11237e12f6fdce9cdbf96561b

Comment by Peter Jones [ 06/Oct/18 ]

Landed for 2.12

Generated at Sat Feb 10 02:32:45 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.