Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-12515

Provide an interface to set OST/client into readonly mode

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.17.0
    • Lustre 2.13.0
    • 9223372036854775807

    Description

      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.

      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.

      Attachments

        Issue Links

          Activity

            [LU-12515] Provide an interface to set OST/client into readonly mode
            pjones Peter Jones added a comment -

            Merged for 2.17

            pjones Peter Jones added a comment - Merged for 2.17

            "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/56304/
            Subject: LU-12515 ofd: allow setting a target to readonly
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: 3483556684a435e71aa69f5d8575ce5e9b437bb7

            gerrit Gerrit Updater added a comment - "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/56304/ Subject: LU-12515 ofd: allow setting a target to readonly Project: fs/lustre-release Branch: master Current Patch Set: Commit: 3483556684a435e71aa69f5d8575ce5e9b437bb7

            "Ronnie Sahlberg <rsahlberg@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/56304
            Subject: LU-12515 ofd: allow setting a target to readonly
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: b9c9ebfd569ffe5e656b1afe7e454889b43cc7b1

            gerrit Gerrit Updater added a comment - "Ronnie Sahlberg <rsahlberg@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/56304 Subject: LU-12515 ofd: allow setting a target to readonly Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: b9c9ebfd569ffe5e656b1afe7e454889b43cc7b1
            adilger Andreas Dilger added a comment - - edited

            Functionality to implement a temporary nodemap with the LU-15451 read-only parameter is proposed in LU-17217.

            adilger Andreas Dilger added a comment - - edited Functionality to implement a temporary nodemap with the LU-15451 read-only parameter is proposed in LU-17217 .
            adilger Andreas Dilger added a comment - - edited

            As an enhancement to the mdt.*.readonly parameter added in patch https://review.whamcloud.com/33892 "LU-11811 mdt: Add a proc entry to set MDT to readonly", 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.

            I think adding the per-OST obdfilter.*.readonly 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 tgt_request_preprocess(). Adding a per-export {obdfilter,mdt}.*.exports.*.readonly parameter that sets a flag in struct obd_export and checks for it in tgt_request_preprocess() should also be fairly straight forward since there is already checking for the per-export OBD_CONNECT_RDONLY connect flag.

            Adding a per-nodemap readonly flag also seems mostly straight forward, since the nodemap is determined in tgt_ost_body_unpack() inside tgt_request_preprocess() 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 tgt_mdt_body_unpack(), which is a bit inconsistent and should be cleaned up but needs some investigation first. It would be possible to just grab the nodemap in tgt_mdt_body_unpack() 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).

            It would make sense to set this by default on MDTs/OSTs when snapshots are being mounted.

            adilger Andreas Dilger added a comment - - edited As an enhancement to the mdt.*.readonly parameter added in patch https://review.whamcloud.com/33892 " LU-11811 mdt: Add a proc entry to set MDT to readonly ", 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. I think adding the per-OST obdfilter.*.readonly 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 tgt_request_preprocess() . Adding a per-export { obdfilter,mdt}.*.exports.*.readonly parameter that sets a flag in struct obd_export and checks for it in tgt_request_preprocess() should also be fairly straight forward since there is already checking for the per-export OBD_CONNECT_RDONLY connect flag. Adding a per-nodemap readonly flag also seems mostly straight forward, since the nodemap is determined in tgt_ost_body_unpack() inside tgt_request_preprocess() 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 tgt_mdt_body_unpack() , which is a bit inconsistent and should be cleaned up but needs some investigation first. It would be possible to just grab the nodemap in tgt_mdt_body_unpack() 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). It would make sense to set this by default on MDTs/OSTs when snapshots are being mounted.

            People

              rsahlberg@whamcloud.com Ronnie Sahlberg
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: