On Thu 28-04-11 09:28:53, Amir Goldstein wrote: > On Wed, Apr 27, 2011 at 11:44 PM, Allison Henderson > <achender@xxxxxxxxxxxxxxxxxx> wrote: > > On 4/25/2011 10:44 AM, Amir Goldstein wrote: > > Hi All, > > > > I did some looking around with the idea of using an allocation_request > > instead of a flags parameter, but I noticed that ext4_new_meta_blocks is > > already setting up an allocation_request to pass to ext4_mb_new_blocks. > > Would it make sense then that we add an "ar_flags" parameter instead of a > > "flag" or another "ar" parameter? That way, ext4_new_meta_blocks can just > > add the flags to the ar that it already has, and we wouldn't have to change > > the ext4_mb_new_blocks parameters. And then USE_ROOTBLKS can be added on to > > the EXT4_MB_HINT scheme instead of starting a new scheme. That would avoid > > the extra ar initializing. What does everybody think? Would this work for > > the HINT_COWING flag? > > I think this would be perfect. > ext4_new_meta_blocks() is not much more than a helper to setup the ar struct, > so passing 'flags' (in that context I see no reason to call it > ar_flags) to it makes sense. > The important thing is that USE_ROOTBLKS is added to the EXT4_MB_HINT scheme > and passed all the way down to has_free_blocks with the 'ar' struct. > > This discussion makes me wonder (CC'ing Jan and Eric for that), wasn't > there ever an intention > to allow the use of reserved space for allocation of any metadata blocks? Not that I know of. > The use case is delayed allocation combined with async mmap writes. > Do we always account for enough metadata blocks when doing delayed allocation? > Both for extent and indirect mapped files? Yes, both should make appropriate upper estimates on the number of needed blocks and reserve that amount. With indirect blocks it's kind of tricky but the code should be correct. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
