> 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). > 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. > > > static bool need_complete_io(struct io_kiocb *req) > > { > > + struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw); > > + > > + /* 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. > > > + 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.