On Fri, 28 Oct 2011 14:34:31 +0900, Kazuya Mio <k-mio@xxxxxxxxxxxxx> wrote: > 2011/10/25 22:40, Jan Kara wrote: > > Please no. Generally this boils down to what do we do with dirty data > > when there's error in writing them out. Currently we just throw them away > > (e.g. in media error case) but I don't think that's a generally good thing > > because e.g. admin may want to copy the data to other working storage or > > so. So I think we should rather keep the data and provide a mechanism for > > userspace to ask kernel to get rid of the data (so that we don't eventually > > run OOM). > > I see. I agree with you. > > >> Do you have any ideas? > > So the question is what would you like to achieve. If you just want to > > unblock a thread then a solution would be to make a thread at > > balance_dirty_pages() killable. If generally you want to get rid of dirty > > memory, then I don't have a really good answer but throwing dirty data away > > seems like a bad answer to me. > > The problem is that we cannot unmount the corrupted filesystem due to > un-killable dd process. We must bring down the system to resume the service > with no dirty pages. I think it is important for the service continuity > to be able to kill the thread handling in balance_dirty_pages(). In fact you are very lucky because dd is just deadlocked, in many cases journal abort result in BUG_ON triggering(if IO load is high enough). This is because transaction abort check is racy. Right now i've no good fix which has reasonable performance. My latest idea is to protect transaction abort check via SRCU. > > Regards, > Kazuya Mio > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
