Re: LOCK_SYNC_MIX state makes "getattr" operations extremely slow when there are lots of clients issue writes or reads to the same file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think it’s used to stop that cache object from being frozen.
so that it won’t be exported to other MDS.

Regards,
Dongdong
> 在 2018年2月8日,下午3:19,Xuehan Xu <xxhdx1985126@xxxxxxxxx> 写道:
> 
> On 8 February 2018 at 15:10, Xuehan Xu <xxhdx1985126@xxxxxxxxx> wrote:
>> Hi, everyone.
>> 
>> Actually, in our case, the whole procedure of a single run of
>> "getattr" ops processing is this:
>> 
>> 1. The "finish" phase of the previous "getattr" op processing turn the
>> target inode's filelock state into LOCK_SYNC_MIX if its current state
>> is LOCK_SYNC;
>> 2. mds blocks all other "getattr" operations when the target inode's
>> filelock state is LOCK_SYNC_MIX, and wait for all clients to release
>> caps that are not allowed in LOCK_MIX;
>> 3. When all clients release those not allowed caps, the inode's
>> filelock state is turned in to LOCK_MIX;
>> 4. A new "getattr" op is dispatched to be processed, during which the
>> inode's filelock state is turned back to LOCK_SYNC and the "getattr"
>> op is processed successfully;
>> 
>> If the next op that is to be dispatched to be processed is, again, a
>> "getattr", the whole procedure would be repeated. In our case, the
>> waiting of the mds for all clients to release caps that are not
>> allowed in state LOCK_MIX could take several hundreds of milliseconds,
>> which means only a few "getattr" requests can be processed per second.
>> And because the "getattr" operation is the mostly issued request in
>> our case, the above procedure can repeat so many times that the
>> response time of the process of a single "getattr" request can take
>> 40+ seconds as they have to wait for their previous "getattr" ops to
>> be processed first, and in the meantime, the "setattr" operations that
>> are issued by the writing client can hardly get the chance to be
>> processed
> 
> I'm now trying to read the related source code, however, I found it a
> little hard to understand.
> What does the MDSCacheObject's auth_pin method mean? Does it mean that
> the MDSCacheObject cannot be evicted from the in memory cache?
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux