Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-10911 FLR2: Read only erasure coding
  3. LU-20244

FLR-EC: optimize resync of mirrors and ec components

    XMLWordPrintable

Details

    • Technical task
    • Resolution: Unresolved
    • Medium
    • None
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      While resyncing the EC mirrors in a second pass makes the code easier, this is definitely inefficient from a data handling POV. That means potentially reading TB of data twice, once to mirror the data component and then again to generate the EC component.

      It would be much more efficient to do EC generation and write immediately after each RAID set is read to mirror the data component.

      It looks like it should be possible to call llapi_ec_compute_parities() and llapi_ec_write_parities() internally by llapi_mirror_resync_many_params() for each raidset so that it can remain a "one stop shop" for resyncing the file, rather than requiring callers to understand and use llapi_ec_resync_many_params() (which of course users will not even know exists).

      That means moving the EC logic out of this function and into llapi_mirror_find_stale() and llapi_mirror_resync_many_params() (ec_split_stripes(), etc). but I don't see that as a bad thing. That code can determine directly from the components whether it is an EC component or regular mirror that is being repaired.

      Attachments

        Activity

          People

            rsahlberg@whamcloud.com Ronnie Sahlberg
            rsahlberg@whamcloud.com Ronnie Sahlberg
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: