On Fri 27-05-11 23:20:57, Manish Katiyar wrote: > changes from v1 -> v2 : > *) Update start_this_handle to take extra parameter to specify whether > to retry the allocation or not. > *) Added jbd allocation flags for callers to control the transaction allocation > behavior. Callers can pass JBD2_TOPLEVEL if allocation needs to be done using GFP_KERNEL. The above changelog should be below where (*) is. Also - this is mainly for Ted: I've looked at where we JBD2_TOPLEVEL could actually be enabled and the results are: Pretty much nowhere. The problem is that with ext4, we need i_mutex in io completion path to end page writeback. So we cannot do GFP_KERNEL allocation whenever we hold i_mutex because mm might wait in direct reclaim for IO to complete and that cannot happen until we release i_mutex. And pretty much every write path in ext4 holds i_mutex. So JBD2_TOPLEVEL looks like a useless excercise to me and I'd just don't do it. > Pass extra flags in journal routines to specify if its ok to > fail in the journal transaction allocation. Passing JBD2_FAIL_OK means caller is > ok with journal start failures and can handle ENOMEM. > > Update ocfs2 and ext4 routines to pass JBD2_NO_FAIL for the updated journal > interface by default, to retain the existing behavior. > > Signed-off-by: Manish Katiyar <mkatiyar@xxxxxxxxx> > --- > fs/ext4/ext4_jbd2.h | 2 +- > fs/ext4/super.c | 2 +- > fs/jbd2/transaction.c | 44 ++++++++++++++++---------------------------- > fs/ocfs2/journal.c | 8 ++++---- > include/linux/jbd2.h | 13 +++++++++---- > 5 files changed, 31 insertions(+), 38 deletions(-) (*) HERE > +/* JBD2 transaction allocation flags */ > +#define JBD2_NO_FAIL 0x00000001 > +#define JBD2_FAIL_OK 0x00000002 > +#define JBD2_TOPLEVEL 0x00000004 > + I guess there's no need for JBD2_FAIL_OK - if NOFAIL is not set, we can fail. Otherwise the patch looks OK. 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
