On 31 Aug 2023, at 12:28, Jeff Layton wrote: > This doesn't seem worthwhile to me. We have a clear reason to add > WORD0_TYPE to "basic" READDIR, which is that we want to be able to fill > out the d_type for getdents. Yeah, and exposing all the bits might create some interesting effects. > I don't see the same sort of rationale for fetching other attributes. It > would just be priming the inode cache with certain info. That could > useful for some workloads, but that seems like sort of a niche thing. The issues I frequently see around READDIR are that we keep micro-optimizing and regressing in another place. If we set WORD0_TYPE, there's a non-zero chance someone might start yelling about it in awhile because their server takes longer to query the inode. Its nice we have the option to give the power back the user sometimes without needing to grow a mount option, or use a module param (which would appply to the whole system) - so this was a fun example. > Adding more info also reduces the number of entries you can pack into a > READDIR reply, which is makes it easier to trigger cookie problems with > creates and deletes in large directories. I don't think those two things are related for filesystems with stable cookies, or I'm not understanding you. I'm in favor of the default READDIR asking for type. Ben
