On Tue, 2018-11-06 at 15:11 +0800, Marvin Zhang wrote:
> Thanks for your explanation.
> Here is the reason why I want to clearfy the difference between Fs and Fr
> 1. When I open and read a file, Client::_open() will send a
> MetaRequest(CEPH_MDS_OP_OPEN) message to Server.
I'm assuming you close the file after the read here?
> 2. If I try to open this file during 5s, Client::_open() will not send
> MetaRequest to MDS.
> 3. If I try to open this file after 5s, Client::_open() will send
> MetaRequest to MDS, even though the file inode and dentry informations
> exist in client cache.
>
> And here is my question:
> 1. client_caps_release_delay is 5s by default. If I increase this
> number, client will not send MetaRequest(CEPH_MDS_OP_OPEN) too many
> times. Is it OK that I set this value very big, e.g 1h? Is there any
> bad influence?
> 2. in Client::check_caps()
> {
> wanted = in->caps_wanted(); //it will be 0 after release file
> if (wanted)
> retain |= CEPH_CAP_ANY;
> else
> retain |= CEPH_CAP_ANY_SHARED; //why exclude FILE_RD??
> //this will cause drop FILE_RD in below code, so in next
> Client::_open() see the cap don't have Fr, it will send a
> MetaRequest(CEPH_MDS_OP_OPEN) to MSD
> }
> My question is : Is is OK to set retain |= (CEPH_CAP_ANY_SHARED |
> CEPH_CAP_FILE_RD) ?
>
That sounds reasonable at first glance. There are no real hard and fast
rules in the cap handling code. It really comes down to heuristics and
trying to minimize later cap revokes.
Doing what you suggest shouldn't break anything, as far as I can tell.
It's just that in some (possibly common) situations, your MDS might end
up having to send more cap revokes when there is competing access. Maybe
it has to do that already for Fs though?
> Thanks,
> On Tue, Nov 6, 2018 at 6:52 AM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
> >
> > On Sun, Nov 4, 2018 at 10:31 AM Marvin Zhang <fanzier@xxxxxxxxx> wrote:
> > >
> > > Hi guys,
> > > They look very similar from defination. Can anyone tell me the difference?
> > >
> > > Here are defination:
> > > #define CEPH_CAP_FILE_SHARED (CEPH_CAP_GSHARED << CEPH_CAP_SFILE)
> > > #define CEPH_CAP_FILE_RD (CEPH_CAP_GRD << CEPH_CAP_SFILE)
> > >
> > > #define CEPH_CAP_GSHARED 1 /* client can reads */
> > > #define CEPH_CAP_GRD 8 /* (file) client can read */
> >
> > IIRC, GSHARED applies to all capability types (Authority, Xattr, File,
> > and whatever I'm forgetting) whereas GRD is just for File.
> > In terms of FILE_SHARED versus FILE_RD: FILE_RD means the client is
> > allowed to actually do data reads to the OSDs. FILE_SHARED relates
> > to...whatever else that cap covers? Maybe the layout or file size?
> >
> > In particular, if multiple clients hold a file open and are doing
> > activity on it, they will hold the Fs (FILE_SHARED) cap throughout the
> > duration. But if one client is doing reads and one client is doing
> > writes, the reader will be granted the Fr (FILE_RD) cap to perform its
> > reads, and then have Fr revoked while its opposite number is granted
> > Fw (FILE_WR) in order to perform writes.
> > -Greg
--
Jeff Layton <jlayton@xxxxxxxxxx>
