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]

 



> Hmm, that makes some sense but is sad. I think to resolve this we’d
> need the MDS to recognize “repetitions” of the same op type that can
> be serviced in a single lock operation for essentially no extra
> (locking) cost, but I’m not sure how we’d integrate that with the
> capability locking going on.
> I guess that when we do locking operations, if they are a single
> request and don't involve giving the client caps, maybe we could stick
> stick any requests that require the same set of locks on a shared data
> structure? And then run through them all when we get granted locks and
> reply to those requests? That may not involve any real fairness
> tradeoffs, as long as we're careful to only do stuff that doesn't
> require extra effort (beyond queueing up the message send).
>
> But I haven't looked at the data structures enough lately to have any
> idea if something like this is really feasible.
> -Greg

Hi, Greg and Zheng

I've just submitted several patches(listed as follows) that implements
getattr/lookup requests batch reply in MDS and
getattr/lookup/sync_read requests aggregation in kernel client. Please
take a look, when you are free:-) Thanks.

http://tracker.ceph.com/issues/36609
http://tracker.ceph.com/issues/36608




[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