On Mon, Oct 21, 2024 at 11:01:10AM +0530, Anuj Gupta wrote: > > What is the meta_type for? To distintinguish PI from non-PI metadata? > > meta_type field is kept so that meta_types beyond integrity can also > be supported in future. Pavel suggested this to Kanchan when this was > discussed in LSF/MM. > > > Why doesn't this support non-PI metadata? > > It supports that. We have tested that (pi_type = 0 case). What other metadata except for PI and plain non-integrity data do you plan to support? This seems like a weird field. In doubt just leave reserved space that is checked for 0 instead of adding an encondig that doesn't make much sense. If we actually do end up with a metadata scheme we can't encode into the pi_type we can still use that reserved space. > > > Also PI or TO_PI might be > > a better name than the rather generic integrity. (but I'll defer to > > Martin if he has any good arguments for naming here). > > Open to a different/better name. metadata? > > > + /* Exclude meta IO as we don't support partial completion for that */ > > > return req->flags & REQ_F_ISREG || > > > - S_ISBLK(file_inode(req->file)->i_mode); > > > + S_ISBLK(file_inode(req->file)->i_mode) || > > > + !(rw->kiocb.ki_flags & IOCB_HAS_METADATA); > > > } > > > > What partial ocmpletions aren't supported? Note that this would > > trigger easily as right now metadata is only added for block devices > > anyway. > > It seems that this scenario is less likely to happen. The plumbing > seemed a bit non trivial. I have the plan to look at it, once the > initial version of this series goes in. I still don't understand what this is trying to do, especially as it is dead code with the checks above. > > > > > + if (unlikely(kiocb->ki_flags & IOCB_HAS_METADATA)) { > > > > For a workload using metadata this is everything but unlikely. Is > > there a specific reason you're trying to override the existing > > branch predictor here (although on at least x86_64 gcc these kinds > > of unlikely calls tend to be no-ops anyway). > > The branch predictions were added to make it a bit friendly for > non-metadata read/write case. Throwing in these hints unless you have numbers justifying them is not a good idea.