On Tue, Nov 6, 2018 at 8:16 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> 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?
[Marvin] Yes. I tested it when I close files and reopen them .
>
> > 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>
>
