On 8/29/24 3:51 PM, Miklos Szeredi wrote: > On Fri, 5 Jul 2024 at 14:00, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: >> I'm okay with resuing max_pages as the alignment constraint. They are >> the same in our internal scenarios. But I'm not sure if it is the case >> in other scenarios. > > max_pages < alignment makes little sense. > > max_pages = n * alignment could make sense, i.e. allow writes that are > whole multiples of the alignment. Agreed. > > I'm not against adding a separate alignment, but it could be just > uint8_t to take up less space in init_out. We could have done that > with max_stack_depth too. Oh well... Make sense, as the new added fuse_init_out.opt_alignment is already log2(byte alignment). I think uint8_t is already adequate in this case. (Actually I'm going to rename @opt_alignment field of fuse_init_out to something like @log_opt_align to indicate it's actually a log2() value as Berned previously suggested) Besides, I'm not sure if it's worth adding a new init flag, i.e. FUSE_OPT_ALIGNMENT, as the init flag bits are continually consumed. Maybe we could stipulate that a zero log_opt_align indicates no alignment constraint (the default behavior), while a non-zero log_opt_align indicates an alignment constraint. However IIUC the user daemon may or may not zero the unused fields of fuse_init_out. Thus if a fuse server not supporting opt_alignment doesn't zero fuse_init_out.unused, then the kernel side will enforce an alignment constraint unexpectedly. -- Thanks, Jingbo
