Ramana Raja

> What would the mechanism for sending back errors be? Could blocking issues on the librados side be solved by dispatching a separate thread to perform the reread_config() and send...

With this fix, a fuse client with root_squash MDS caps worked as expected (as before). When using a kclient with root_squash MDS caps, the data written by a non-root user...

> > When using root_squash MDS auth caps, a kernel CephFS client is able to write data as a non-root user. However, after it is remounted or forced to drop...

> > > During write as a root user from the kclient, I see the following in MDS log, where I suspect the write is allowed to succeed. > >...

> > > > > During write as a root user from the kclient, I see the following in MDS log, where I suspect the write is allowed to succeed....

> When open a existing file and if the inode is cached in client side: >For the fuse client: >1. Try to open the inode and check the caps issued...

> > > > > @ajarr This looks good to me. Please rebase the PR and remove the draft. Thanks! > > > > > > > > > >...

> > > When open a existing file and if the inode is cached in client side: > > > For the fuse client: > > > > > >...

> > > For the other cases, such as the setattr, if the XxFxAx caps are issued it probably will buffer the changes and then return success to userspace. But...

> > > @vshankar @gregsfortytwo @ajarr > > > To fix this there are two approaches in my mind: > > > 1, Force the setattr and other write OPs...