[LU-2445] add "lfs migrate" support

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Story Points: 3
• Assignee: Jinshan Xiong (Inactive)
• Reporter: Andreas Dilger

Description

Once the "layout swap" support in LU-2017 (http://review.whamcloud.com/4507) is landed, the client will have an API to atomically swap the layout between two files.

In order for this functionality to be useful for users, the llapi_layout_swap() function needs to be wrapped in some additional code compared to lfs swap_layouts to ensure that the file isn't changing during the copy, and to do the actual copy.

I propose an lfs migrate command that takes the same arguments as lfs setstripe (calling into lfs_setstripe() to create the target file, for simplicity and compatibility, though with some option to make it an open-unlinked file via LU-2441), gets an exclusive lock on the file (group lock or client-side layout lock), and then copies the file contents from the source to the target. By reading the whole source file, this will natually cause any clients with unwritten data to flush their caches when their write-extent locks are cancelled. Once the copy is completed (optionally verifying the data checksum after flushing the client cache?) the llapi_layout_swap() function is called, and the "new" open-unlinked file descriptor layout (which now points to the old objects) is closed, causing those objects to be destroyed. The exclusive lock can be dropped.

If the MDS does not support MDS_SWAP_LAYOUTS then lfs migrate should return an -EOPNOTSUPP error, so that users are aware that atomic layout swap is not available.

The lfs_migrate script should call the lfs migrate command to do the migrate/copy (instead of rsync + mv). but lfs_migrate probably needs to fall back to rsync+mv again. The lfs_migrate script has not previously guaranteed atomic migration, so it should continue to work using rsync+mv as it has in the past if "lfs migrate" returns EOPNOTSUPP, with a comment to the effect that this functionality should be removed after Lustre 2.10 or so.

Issue Links

• is related to: LU-4293 lfs_migrate is failing with a volatile file Operation not permitted error

Comments

[Andreas Dilger]

This was primarily landed in Lustre 2.4.0, but a number of related fixes have been landed since then.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/12627/
Subject: LU-2445 lfs: fixed support for lfs migrate -b
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 04cc64d30160bd424f7ff151592b43ed0e68571c

[Frank Zago (Inactive)]

Minor fix: http://review.whamcloud.com/12627

[Keith Mannthey (Inactive)]

Thanks I will look at expanding the testing a bit.

[Andreas Dilger]

There is sanity.sh test_56w(), though it doesn't appear this verifies the data...

[Keith Mannthey (Inactive)]

+1 on this being a very cool thing. "lfs migrate [--block]" allows in filesystem data migration. Is there a lustre-test for this?

[Andreas Dilger]

Before this bug can be closed, we need to update the user manual to describe this feature.

[Jinshan Xiong (Inactive)]

With the landing of the latest patch, is it now safe to do "lfs migrate [--block]" on a file that is in use and actively undergoing IO?

Yes.

[Andreas Dilger]

With the landing of the latest patch, is it now safe to do "lfs migrate [--block]" on a file that is in use and actively undergoing IO? If yes, this would be a great feature coming from the HSM to announce for 2.4, even though the full HSM functionality is not yet available.

[Peter Jones]

Dropped priority because patch landed for 2.4