On Thu 14-04-16 09:43:05, Jens Axboe wrote: > On 04/13/2016 03:48 AM, Jan Kara wrote: > >On Tue 12-04-16 12:43:51, Jens Axboe wrote: > >>Avoid losing context by propagating the various reason why we > >>initiate writeback. If we are doing more important reclaim or > >>synchronous writeback, the lower levels should know about it. > >> > >>No intended functional changes in this patch. > > > >So far 'reason' is only used for tracing and I'd strongly prefer to keep it > >as such - otherwise the mix of flags like for_sync, for_backround, ... and > >'reason' gets really messy. If you need more information propagated via > >wb_start_writeback() just add more flag arguments (currently there is only > >range_cyclic flag). Since there would be already three flag arguments, > >maybe it would warrant using a 'flags' argument which would be a standard > >bitmask of desired flags... > > It'd be nicer if the tracing just ran off the functional parts, instead of > having a separate argument just for tracing. It's both confusing and fragile > to have two separate sets of information in there, and it's harder to keep > in sync. > > But that's probably better left for another cleanup series. I'll flag this > separately. Well, the point of 'reason' was that there are different call sites that issue the same type of writeback and we wanted to distinguish between them to get more insight into what is happening from the tracing. If we keep 'reason' only to document 'call site', then it is not fragile. I agree with the 'confusing' part though since you are not the first one who has tried to use the 'reason' argument for functional decision :-). Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
