On Thu, 28 Feb 2019 at 09:50, Xiaoxi Chen <superdebuger@xxxxxxxxx> wrote: > > I doubt throttling can works. > > If your two workloads can stay in separate namespace(i.e not sharing any data), you can easily achieve the isolation by multi-mds +dir_pin. > Hi, thanks for your reply:-) We are an infrastracture department that offer distributed file system service to other departments each of which has a lot of different workloads, some of which maybe bursty while others are not. Each of those workloads is running on a exclusive directory. And what's more, even non-bursty workloads maybe occasionally do some "extra things" which produces lots of metadata requests. It's hard for us to know on which directory there would be a bursty workload, so it's hard for us to predict which directory should be pinned to other MDSes. > If your burst workload and your regular workload are targeting same namespace, then it may cause more lock contention and in general make things worse....e.g "ls -al" which will translate to a readdir and a lot of getattr, and holding the read lock of the dir. If you throttle the getattr which leads the read lock being taken for longer time and blocks those writers. > If client-side throttling is not an option, do you think server-side metadata op qos is feasible? And is dmclock suitable for implementing it? Thanks:-)
