https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-12515 Lustre <p>There was an outage on our site where a script was deleting tons of valuable data from Lustre file systems. It takes some times to figure out the problematic script and kill it.</p> <p>It seems like Lustre lacks of a functionality to set the whole file system into readonly mode, which is useful in this case because it can help stop bleeding immediately.</p> LU-12515

Provide an interface to set OST/client into readonly mode

Improvement Minor Open Unresolved WC Triage Andreas Dilger easy Fri, 5 Jul 2019 20:56:00 +0000 Wed, 13 Oct 2021 23:03:32 +0000 Lustre 2.13.0 0 4 <p>As an enhancement to the <tt>mdt.&#42;.readonly</tt> parameter added in patch <a href="https://review.whamcloud.com/33892" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33892</a> "<tt><a href="https://jira.whamcloud.com/browse/LU-11811" title="Provide an interface to set Lustre MDT into readonly mode" class="issue-link" data-issue-key="LU-11811"><del>LU-11811</del></a> mdt: Add a proc entry to set MDT to readonly</tt>", it would be useful to be able to set all OSTs readonly in a similar manner, or set individual clients or nodemaps as readonly. This would allow a server-side enforcement to avoid modifying the filesystem, either globally or on a per client/group basis.</p> <p>I think adding the per-OST <tt>obdfilter.&#42;.readonly</tt> parameter should be relatively easy to implement, possibly moving this up into generic target request handling code for both the mdt and and obdfilter in <tt>tgt_request_preprocess()</tt>. Adding a per-export {<tt>obdfilter,mdt}.&#42;.exports.&#42;.readonly</tt> parameter that sets a flag in <tt>struct obd_export</tt> and checks for it in <tt>tgt_request_preprocess()</tt> should also be fairly straight forward since there is already checking for the per-export <tt>OBD_CONNECT_RDONLY</tt> connect flag.</p> <p>Adding a per-nodemap readonly flag also seems mostly straight forward, since the nodemap is determined in <tt>tgt_ost_body_unpack()</tt> inside <tt>tgt_request_preprocess()</tt> and could be used to make a per-nodemap decision at that point. However, I don't see the nodemap being accessed in the corresponding <tt>tgt_mdt_body_unpack()</tt>, which is a bit inconsistent and should be cleaned up but needs some investigation first. It would be <em>possible</em> to just grab the nodemap in <tt>tgt_mdt_body_unpack()</tt> for checking the per-nodemap readonly flag, but this seems like it would be duplicating the effort done in various places in the MDT code, and it would be better to do it in only one place. Alternately, when clients connect using a specific nodemap, the per-client export readonly flag could be set, but this may complicate things if the nodemap readonly flag is removed at runtime, or if a client is removed from that nodemap (though these may be corner cases that are not important enough for the first revision).</p> <p>It would make sense to set this by default on MDTs/OSTs when snapshots are being mounted.</p> Cloners LU-11811 Development Rank 1|i00ja7: Rank (Obsolete) 9223372036854775807