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

update osd-ldiskfs to not depend on dev_readonly patches

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Not a Bug
    • Affects Version/s: Lustre 2.10.0
    • Fix Version/s: None
    • Labels:
      None
    • Rank (Obsolete):
      9223372036854775807

      Description

      I am splitting this from LU-684 that would concentrate on the test-framework side of things.

      Currently osd interface declares dt_ro (osd_ro) operation to mark a device read-only for failover purposes.

      In zfs case it's achieved internally, but for ldiskfs we are carrying a special patch to do it.
      Now, its desirable to do away with the patch.

      In the past James Simmons came up with the approach of using make_request fault location that was vetted down because it also makes reads fail: https://review.whamcloud.com/#/c/6651/3

      Since then apparently no better method appeared to make a similar fault only to fail writes.

      So I wonder if we can play some smart tricks to overcome this?
      Stuff I have in mind are:
      1. We can probably forcefully remount everything readonly (also can patch ldiskfs not to issue any writes). In order to prevent any journal updates from happening, we can also abort journal and I think that causes all writes there to stop as well.

      • This still might cause some cached writes to go to disk flushed by pdflush, we probably can preemptively truncate those?

      2. We might attempt to play some games on the actual underlying block device to render it readonly, like try to hijack the ->make_request_fn() function pointer, but I guess that's kind of shady.

      Any other good ideas I am missing?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                wc-triage WC Triage
                Reporter:
                green Oleg Drokin
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: