Details
-
Technical task
-
Resolution: Won't Fix
-
Major
-
None
-
Lustre 2.5.0
-
None
-
17,895
-
8423
Description
In order to submit the raid5-mmp-unplug-dev patch upstream, this needs to be updated for the latest kernel. Unfortunately, the affected code seems to have changed since the patch was written, so I'm not sure whether a simple "best guess update" of the patch will be correct.
I'll attach my "best guess" patch, but it needs to be verified by someone who actually understands the MD RAID code better.
Attachments
Issue Links
- is related to
-
LU-20 patchless server kernel
-
- Resolved
-
Activity
I don't think _META is less used than _SYNC. It is often used for metadata IO requests to increase the priority in the scheduler. I think it is probably best to try with a new REQ flag and see what the upstream MD maintainer thinks. This is a generic bug with ext4 MMP, and not Lustre specific, so there should be some kind of solution possible.
James, a problem I've just noticed since I looked at this patch in detail for upstream submission is that overloading READ_SYNC/REQ_SYNC to mean "bypass MD RAID cache" is that this can negatively impact other filesystems such as Btrfs, OCFS, and others that now use READ_SYNC to distinguish reads that are being waited upon by processes from readahead requests.
That is fine for Lustre server kernels, but isn't necessarily fine for general usage. One option is to make a separate REQ_NOCACHE flag or similar, but that needs a much bigger patch that is only useful for ext4 MMP.
Hopefully someone who understands the RAID and block layer details better can come up with a solution.
Since this patch is more a bug fix it might even make it into 3.10. Time to send it to dm-devel@redhat.com
Ok, so let's go for a new flag.
But having a look to the MD/Raid5 source code I am now concerned about the real need for md_wakeup_thread() call at the end of make_request() if flag is set, seems to me that it should have been already called within release_stripe[_plug]() call and underlying routines. Thus, even if ineffective it could be considered as useless and costly.