This adds a new field in ext4_group_info to cache the largest available block range in a block group; and don't load the buddy pages until *after* we've done a sanity check on the block group. With large allocation requests (e.g., fallocate(), 8MiB) and relatively full partitions, it's easy to have no block groups with a block extent large enough to satisfy the input request length. This currently causes the loop during cr == 0 in ext4_mb_regular_allocator() to load the buddy bitmap pages for ...

AFAIK simply nobody has done the work and submitted it. Simply adding it would break LVM snapshots though, so there's a compatibility issue. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

https://bugzilla.kernel.org/show_bug.cgi?id=15906 --- Comment #20 from Dmitry Monakhov <dmonakhov@openvz.org> 2010-05-07 09:45:32 --- I can confirm that Jens's fix the original regression for me, so IMHO first part well done. About second one. Proposed patch was posted may be found here: http://marc.info/?l=linux-fsdevel&m=127322500915287&w=2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are ...

https://bugzilla.kernel.org/show_bug.cgi?id=15875 --- Comment #7 from Artem S. Tashkinov <t.artem@mailcity.com> 2010-05-07 07:09:07 --- Whatever fits you, however don't forget that there are immutable and appendable only flags for ext2/3/4 and they should probably dismissed too. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. --

In theory, it is possible to have 2 modes for Ext4 (extents or snapshots) and some would argue that it makes sense to do that. But I think that making that decision can be deferred to a later time, after people have experienced with Next3 and have decided if they would like to have the snapshot feature merged into Ext4 or not. Besides, it would take me a considerable amount of time to merge the snapshot feature into Ext4, and Next3 is ready to be used now. Amir. --

I think that the counter argument would be that moving features into ext3 is probably the wrong thing to do. I don't think that anyone is in a huge hurry given that we have LVM based snapshots with ext3 and btrfs snapshots around the corner. Probably this is most interesting when done to the latest version of the ext family. Best regards, Ric --