On Tue, Jan 28, 2014 at 6:12 AM, Philip Guenther <guent...@gmail.com> wrote: > On Tue, Jan 28, 2014 at 2:03 AM, Andres Perera <andre...@zoho.com> wrote: >> On Tue, Jan 28, 2014 at 4:55 AM, Philip Guenther <guent...@gmail.com> wrote: > ... >>> I'm no expert on softdeps, so maybe you have a better explanation for >>> why Kirk made the choice he did to have it panic in some cases? >> >> well, i'm no expert either. now that we have presented our >> credentials, let's go back to what was already conjecture > ... >> do you want the kernel to figure these out after the fact and >> retroactively panic() for each occurence, neatly queueing them boot >> after boot or do you want to grow a pair of balls instead? > > You ignore my pointer to the actual engineering and logic in this area > and prefer to expand upon the conjecture. I cannot help in that area > and am unwilling to have you reorder my TODO list to suit your > pleasure. >
the comments pertain to your misrepresentation of McKusick's softdep paper. this being a public forum, your todo list is your personal business, and in any case not for others to be shoehorned into when blatant mistakes need correction the paper does not support the notion that metadata cache flushing failures lead to complete system instability meriting a panic. quote the relevant text or stop pretending that it's there. meanwhile, there are cases where synchronous writing of metadata can also allow the unavailability and corruption of a previously succesful system call's pervasive effects. the onus is on you, or in your imaginary representation of the paper, to prove that halting the system is justifiable in BOTH circumstances. the paper does not discuss alternatives, eg, mounting read only and preserving references to unflushed data until unmount... so thread along if you find looking for a solution uninteresting. that's better than lying. > Instead I look forward to your diff fixing this bug in softdeps. > Please send that diff to the list and not me directly, as I find your > submissions uninteresting. > > > Philip Guenther
