+akpm So I'm arriving late to this discussion since I've been in conference mode for the past week, and I'm only now catching up on this thread. I'll note that this whole question of whether or not file systems should use GFP_NOFAIL is one where the mm developers are not of one mind. In fact, search for the subject line "fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL" where we recapitulated many of these arguments, Andrew Morton said that it was better to use GFP_NOFAIL over the alternatives of (a) panic'ing the kernel because the file system has no way to move forward other than leaving the file system corrupted, or (b) looping in the file system to retry the memory allocation to avoid the unfortunate effects of (a). So based on akpm's sage advise and wisdom, I added back GFP_NOFAIL to ext4/jbd2. It sounds like 9879de7373fc is causing massive file system errors, and it seems **really** unfortunate it was added so late in the day (between -rc6 and rc7). So at this point, it seems we have two choices. We can either revert 9879de7373fc, or I can add a whole lot more GFP_FAIL flags to ext4's memory allocations and submit them as stable bug fixes. Linux MM developers, this is your call. I will liberally be adding GFP_NOFAIL to ext4 if you won't revert the commit, because that's the only way I can fix things with minimal risk of adding additional, potentially more serious regressions. - Ted -- 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
