On Thu, 2020-10-08 at 15:02 -0500, Eric Sandeen wrote: > On 10/1/20 11:40 PM, Ian Kent wrote: > > On Fri, 2020-10-02 at 10:27 +0800, Ian Kent wrote: > > > On Thu, 2020-10-01 at 16:22 -0500, Eric Sandeen wrote: > > > > snip ... > > > > > > Backing up a bit, which xfsprogs utility saw this behavior with > > > > autofs mounts? > > > > > > IIRC the problem I saw ended up being with xfs_spaceman invoked > > > via udisksd on mount/umount activity. There may be other cases so > > > I'd rather not assume there won't be problems elsewhere but those > > > checks for an xfs fs that I didn't notice probably need to > > > change. > > > > Looking around further, there may be another assumption that's > > not right. > > > > It looks like xfs_info is being called via udisksd -> libblockdev > > and the xfd_open() triggers the mount not a statfs() call as > > thought. > > > > I can't see why I saw xfs_spaceman hanging around longer than I > > thought it should so I probably don't have the full story. > > probably because recent xfs_info is a shell script that calls > spaceman? > > Tho I wonder what udisksd/libblockdev is doing with xfs_info info ... Haha, I wonder that too. I've only looked very briefly at udiskd so far, enough to know that its object oriented'ish factorization is enough to make it hard to follow. Over the years my impression is that it takes a very special skill to write object oriented code that is maintainable/readable and that's skill is sadly lacking in a lot of cases. But maybe its just my poor old brain that's lacking, ;) Ian
