Ellis, OST removal is something that happens relatively rarely in most filesystems, though the filesystem at Stanford is possibly one of the longer-lived Lustre filesystems in use. The process for that filesystem is to delete old OSTs and not re-use the index.
I'm not aware of any reason that the old configuration file is kept around after the del_ost command is run, except that it has never been an issue in the past. It would seem relatively straight forward to imlpement this additional step as part of del_ost. There is an existing ioctl(OBD_IOC_LLOG_REMOVE) that can be used to delete a specific llog, so it should be possible to add this into the del_ost command to clean up the old config log. On Oct 31, 2025, at 13:13, Ellis Wilson via lustre-discuss <[email protected]> wrote: Hi all, With lctl del_ost the process of deleting an OST that you partially or fully added, but don't want any longer is nearly there. However, we have need for a more complete solution, such that a subsequent addition of an OST at the same index works without the need to issue --replace with the mkfs command. I've found that if I remount the MGT mount in a non-lustre mode (e.g., simply mount /dev/<dev> /mnt/mgt), I can locate the OST in question under CONFIGS/<name>. By deleting that file, the OST is accepted in the next time around with a simple non-replacement mkfs invocation. However, this strikes me as very sketchy. Two questions: 1. Why keep the configuration around for a node that is no longer in any of the llogs (post lctl del_ost)? Does it serve any purpose? Would it be better for that del_ost command to also remove that file? 2. If I do this and then remount the MGT "normally" and re-add an OST with the same index, are there issues I'm going to hit (ignoring in-memory stale context on the client-side alluded to in LU-16475)? This is discussed thoroughly in https://jira.whamcloud.com/browse/LU-16475 (which of course I found after my exploration), but the above two questions aren't completely addressed. Thanks for any advice in advance! ellis _______________________________________________ lustre-discuss mailing list [email protected]<mailto:[email protected]> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org Cheers, Andreas — Andreas Dilger Lustre Principal Architect Whamcloud/DDN
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
