[lustre-discuss] Safest means to delete a previously-used OST index?

[Andreas Dilger]

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 <lustre-discuss at lists.lustre.org> 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
lustre-discuss at lists.lustre.org<mailto:lustre-discuss at lists.lustre.org>
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Cheers, Andreas
—
Andreas Dilger
Lustre Principal Architect
Whamcloud/DDN




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20251103/6a0b7a56/attachment-0001.htm>