On Tue, Nov 20, 2012 at 05:14:55AM -0700, Lisa Mitchell wrote: [..] > I tested this makedumpfile v1.5.1-rc on a 4 TB DL980, on 2.6.32 based > kernel, and got good results. With crashkernel=256M, and default > settings (i.e. no cyclic buffer option selected), the dump successfully > completed in about 2 hours, 40 minutes, and then I specified a cyclic > buffer size of 48 M, and the dump completed in the same time, no > measurable differences within the accuracy of our measurements. This sounds little odd to me. - With smaller buffer size of 48M, it should have taken much more time to finish the dump as compared to when no restriction was put on buffer size. I am assuming that out of 256M reserved, say around 128MB was available for makedumpfile to use. - Also 2 hours 40 minutes sounds a lot. Is it practical to wait that long for a machine to dump before it can be brought into service again? Do you have any data w.r.t older makedumpfile (which did not have cyclic buffer logic). I have some data which I collected in 2008. 128GB system took roughly 4 minutes to filter and save dumpfile. So if we scale it linearly then it should take around 32minutes per TB. Hence around 2 hours 8 minutes for a 4TB systems. Your numbers do seems to be in roughly inline. Still 2-2.5 hours seems too long to be able to filter and save core of a 4TB system. We will probably need to figure out what's taking so much of time. May be we need to look into cliff wickman's idea of kernel returning list of pfns to dump and make dump 20 time faster. I will love to have 4TB system dumped in 6 minutes as opposed to 2 hrs. :-) Thanks Vivek
