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> >