From mboxrd@z Thu Jan 1 00:00:00 1970 From: NeilBrown Subject: Re: [md PATCH 09/18] md/raid10: stop print_conf from being too verbose. Date: Fri, 10 Jun 2016 16:47:44 +1000 Message-ID: <87mvmtmtf3.fsf@notabene.neil.brown.name> References: <20160602061319.2939.72280.stgit@noble> <20160602061952.2939.83586.stgit@noble> <22352.32563.81868.525891@quad.stoffel.home> <87d1nzp5q6.fsf@notabene.neil.brown.name> <20160603223909.GD1898@kernel.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: In-Reply-To: <20160603223909.GD1898@kernel.org> Sender: linux-raid-owner@vger.kernel.org To: Shaohua Li Cc: John Stoffel , linux-raid@vger.kernel.org List-Id: linux-raid.ids --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, Jun 04 2016, Shaohua Li wrote: > On Fri, Jun 03, 2016 at 08:48:33AM +1000, Neil Brown wrote: >> On Fri, Jun 03 2016, John Stoffel wrote: >>=20 >> > NeilBrown> raid10 arrays can usefully be very large. When they are, >> > NeilBrown> the noise generated by print_conf can over-whelm logs. So >> > NeilBrown> truncate the listing at 16 devices. >> > >> > Why is this too noisy and how often does this print_conf() happen? >> > And why 16 devices? I guess I don't like the magic number of 16 here, >> > I'd prefer it to be a define, and possibly even something that can by >> > dynamically changed. >>=20 >> print_conf happens whenever a device becomes active in the array, or a >> device is removed from the array (usually because it has failed). >>=20 >> I got 16 by choosing a random number and multiplying by 4 (or maybe by >> raising 2 to that power) :-) >>=20 >> More seriously, I guessed that most arrays were 16 devices or less, so >> this would not affect most arrays. >>=20 >> I definitely don't think it needs a define. I'm very tempted to remove >> print_conf() completely, but it is sometimes useful. So having it >> present as long as it isn't a burden seems reasonable. >>=20 >> If configuration was important I would change it to use pr_debug(), but >> then the default would be to not see the messages at all, and they can >> be useful in diagnosing problems reported on mailing lists. >>=20 >> > >> > But how big a problem is this really? And what about for big RAID5/6 >> > arrays as well? >>=20 >> When you have 2000 devices in your RAID10 and half of them are removed >> at once, it currently reports on 2,000,000 devices. With the patch it >> is only 32000. Still possibly too many. >>=20 >> If you have 2000 devices in your RAID5/6 and half of them are removed, >> you have other problems. >>=20 >> > >> > Or would it be also good to condence the output of print_conf() >> > itself? >>=20 >> Probably a very good idea. Maybe the default could print a fixed-size >> summary and the rest goes in pr_debug()?? >>=20 >> > >> > Of if it's noise, why not just remove it completely? Can this >> > information be found in /proc/mdstat instead? >>=20 >> Its value is historical - trying to understand a past sequence of >> events. For that, something in the logs beats something in /proc. >>=20 >> > >> > Sorry I havent' looked in the code deeply, but this just struck me as >> > a change that might not be ideal. >>=20 >> Fair enough - your comments are very valid. I'm not really sure what is >> best. I only know what is worst :-) and want to avoid that. > > I would prefer pr_debug. pr_debug can be enabled dynamically. If the info= is > helpful for diagnosing, enabling it is simple. Fair enough. Please drop this patch. I'll come up with an improved propos= al and resubmit. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWmKQAAoJEDnsnt1WYoG5KJMP/RzxFc+kRpVIaDZaGwcUE+m2 Y+BLYuChj1uOhZCQ5Ykq0JerDw/M8p/BIk8PSbCfGT+IM6rJfP8QaNWWF2BdMOZX /sWHQo2b7Wyw6FzquHlr91E8l9RQA/Kw0UkblFnnw1ZTYvVK2y4UicxgVo8OVwiX 4H8iaV04Tjk3yJ/WJPMEFpOUP28rYW9WlQKRbxHVVr2G5TRSFo1z76/CNWDa14Pa 7DGisqbvRBNViQrlPGe1n6VnEUMm6ibISs9VUVwZQQfBJXYPBzT424phg6NUxHlt ZosRdvZlyzEXR0bXiIwnouDg7/r7XXi00EgogOvXcgT9kNIICxCQWI5ksXQ+3AxV TdwQ39odIZHUQCYmNOFeSqX3zBO+TEoBWExhQh87bZOLhWpiJZa+xY+MDVH5qP5+ vv7dGxsh+62LnCC5H48lyIJqKq56AabjRIECwrJSdvjTFKxOCLXd7gVFU0fOoEmN uLMK7sV9rOa1YhzTJe+1l2MeVF1NsmrxpYerR6/ZLr9/VfTAWbANoLQ2pNZMGzOd V12+5gPFkflgzCbbusQjWwiSKgzkocZn3MpMBEEoyodlHzXYJ3r6uFhp6w8XomUA 1v87zK3nJ6f13AJP10P7Eyt3xhUg9G4JhkZZea5jibEruCRGOdaNPe5aRr4ihXCK K3tu/eAwJlYpDMJzWNBz =vH1W -----END PGP SIGNATURE----- --=-=-=--