On Thu, 16 Nov 2006, Andrew Morton wrote: > On Thu, 16 Nov 2006 12:15:16 -0800 > Mingming Cao <cmm@xxxxxxxxxx> wrote: > > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote: > > > > > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has > > > gone infinite. I don't see why, but more staring is needed. > > > > The loop should not go forever, it will stops when there is no window > > with free bit to reserve in the given block group. > > It seems to have done so in Hugh's testing, but there's some question there > now. Although I didn't check to see if there's a significant difference > between Hugh's patch and mine. After four days of running, the EM64T has at last reproduced the same hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv, repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove (perhaps not in that order). But somehow I've screwed up, and before I'd extracted any new info, kdb was spinning on its own kdb_printf_lock, and then the box completely frozen: nothing for it but to reboot. Grrrr. Well: at least this resolves the doubt I raised earlier, whether I'd been testing with the right ext2 patch. This time was definitely with your patch not my two-liner: your original patch from Tuesday 14 Nov, ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix Various other patches have come into -mm (one gone) since then, but I've been running just with that: so far as I can see, none of the later ones should be important in my case - the filesystem is too small for the difference between int and ext2_fsblk_t to become important, and neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout. I'll do a little staring at the code myself: I'm unlikely to notice anything you've missed, but there's just a chance staring at it will direct me to some detail I've jotted down from before. Hugh - 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
