[lustre-devel] make fs ro for migration

Andreas Dilger adilger at whamcloud.com
Wed Oct 30 13:50:02 PDT 2024


On Oct 29, 2024, at 16:48, Defazio, Gian-Carlo <defazio1 at llnl.gov<mailto:defazio1 at llnl.gov>> wrote:

We’re doing another file system migration. We’d like users to have read-only access to the existing filesystem during and then for a while after the final sync.

The 2 mechanisms we’re looking at are setting the MDTs read-only using “lctl set_param mdt.*.readonly=1” and remounting the filesystem on all the clients using “mount -o remount,ro”.

My impression is that in the case of setting the MDTs read-only, files already opened in write mode will still be writable. For remounting, if files are opened in write mode the remount will fail and complain that the file system is busy. Our current plan is to do the remounting of all clients because it’s easier to see if some user has some file open in write mode.

Is there a way to make the file system read-only that’s minimally disruptive to users but doesn’t have the potential problem of having to chase down every process writing to the filesystem?

In 2.15 the mdt.*.readonly=1 parameter is the only option.  There is patch https://review.whamcloud.com/56304 ("LU-12515<https://jira.whamcloud.com/browse/LU-12515> ofd: allow setting a target to readonly") which missed the cutoff for 2.16.0 that can also set the OSTs read-only.

My suggestion would be to set the mdt.*.readonly=1 parameter sooner rather than later, then let the open write handles "peter out" over some days before or during an initial data migration pass (which will likely take some days itself).  You can then likely remount all/most of the clients read-only since the running jobs will have finished and/or deal with the few remaining clients processes that have open-for-write handles and then do a final resync pass to catch any changes afterward.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Whamcloud







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20241030/03d612a7/attachment.htm>


More information about the lustre-devel mailing list