Date: Mon, 14 Nov 2011 19:22:43 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic Message-ID: <4EC14E63.2090506@FreeBSD.org> In-Reply-To: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> <20111114130857.GC50300@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable on 14/11/2011 15:08 Kostik Belousov said the following: > On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: >> On a more serious note: >> - some code in my latest version of the patch was contributed by or wa= s based >> on the code or ideas contributed by jhb and mdf (so that attributions = are not >> lost) Oops, forgot the most recent and quite big contribution from Attilio. > Please provide me with proper attribution for contributors and testers.= My memory has faded a bit, so let's make it simple. In cooperation with: attilio, avg, jhb, kib, mdf Tested by: avg, Eugene Grosbein <eugen@grosbein.net>, gnn, Steven Hartland <killing@multiplay.co.uk>, glebius, kib [strike out obvious/unnecessary] >> - there was a concern about how sync-on-panic would work >> >> About the latter, I have never really tested it. mdf has suggested to >> move the sync-on-panic code to a place after we ensure that there is >> only one CPU in panic(), but before we stop other CPUs. > sync_on_panic is incompatible with the patch. I argue that it provides > non-zero chance of damaging good filesystems even if panic was unrelate= d > to the fs/bio/device layer. As an example, consider the case when other= > CPU was modifying in-memory representation of the metadata, and panic > happen on this CPU. If you write half-changed block back, you make more= > damage to the filesystem then if you do not. The half-backed sync spoil= s > any journaling or SU consistency guarantees. Not sure how this is different from what we have right now (without the p= atch). Perhaps I misunderstand what you say, but, just in case, the proposal was= to do sync-on-panic before stopping other CPUs. > The issues of multithreading nature of our storage subsystem are second= ary. >=20 > The user who sets either tunable shall know what he does. That has always been the case. and apparently there are people who still want this option to exist. >> I think that I've already sent you a list of the early testers for >> various WIP versions of the patch. > I do not have the list. Included above. > BTW, if you want, feel free to handle the commit youself. You definitel= y > spent much more efforts on the stuff and deserve the credit. >=20 > I was promised in private that a review will be provided during this > weekend. Unfortunately too little time and spare mind capacity to do the commit no= w. I do not care much about the credit (or commit-o-meter) as long as we get= functionality in. It was/is a collective effort in any case. Besides I won't be able to handle any potential regression reports in a sufficiently speedy manner. --=20 Andriy Gapon --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwU5sAAoJEHSlLSemUf4vt/gIAK3ErPHwuIpwBFvSjvgP0OQF clr4Ox7yl8MfvXej43nqRnj00ySRpqpFT+kAbruKlnkiPJoIeD4DOJr1eMSi1/CD lt8J5guUPIon/or5V/e703jnv/KTaR63d2ihHZg9y1GVWww2iFZTamg4M46aGtF5 Y83J1tBWOROEy9MaFHGtyBSaQBgAMIpMLnY+L1ueXerzAaCfXVlXT4osEt95fJRg hPhfgfWK6CDwswwo01aom0x7bVl+xA5rXDUFpDVD8LDcGjpYVAstH181Uh4sO69w 61wQTaC7G9b+1jOx8eALK8k1ssBFamwaJ/pcmsBbXrvBUJCFgdb8wzwX0ZlZGb0= =o+eV -----END PGP SIGNATURE----- --------------enig5D8E014BB4D54A54E4F13B1A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC14E63.2090506>