Re: Improve processing efficiency for addition and deletion of multipath devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 28.11.2016 v 03:19 tang.junhui@xxxxxxxxxx napsal(a):
Hello Christophe, Ben, Hannes, Martin, Bart,
I am a member of host-side software development team of ZXUSP storage project
in ZTE Corporation. Facing the market demand, our team decides to write code to
promote multipath efficiency next month. The whole idea is in the mail below.We
hope to participate in and make progress with the open source community, so any
suggestion and comment would be welcome.



Hi

First - we are aware of these issue.

The solution proposed in this mail would surely help - but there is likely a bigger issue to be solved first.

The core trouble is to avoid  'blkid' disk identification to be executed.
Recent version of multipath is already marking plain 'RELOAD' operation
of table (which should not be changing disk content) with extra DM bit,
so udev rules ATM skips 'pvscan' - we also would like to extend the functionality to skip rules more and reimport existing 'symlinks' from
udev database (so they would not get deleted).

I believe the processing of udev rules is 'relatively' quick as long
as it does not need to read/write ANYTHING from real disks.

So while aggregation of 'uevents' in multipath would 'shorten' queue processing of events - it would still not speedup scan alone.

We need to drastically shorten unnecessary disk re-scanning.

Also note - if you have a lot of disks -  it might be worth to checkout
whether udev picks  'right amount of udev workers'.
There is heuristic logic to avoid system overload - but might be worth to check if in you system with your amount of CPU/RAM/DISKS the computed number is the best for scaling - i.e. if you double the amount of workers - do you
get any better performance ?

Regards

Zdenek

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux