On Thu, 8 Feb 2018, Douglas Fuller wrote: > > On Feb 8, 2018, at 8:11 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > > > On Thu, 8 Feb 2018, Yan, Zheng wrote: > >> On Thu, Feb 8, 2018 at 10:47 AM, Chengguang Xu <cgxu519@xxxxxxxxxx> wrote: > >>> Hi Cepher, > >>> > >>> Current statfs(2) in ceph kernel client provides raw capacity information of total/used/avail, > >>> but in the point of view of filesystem I think we actually more willing to see real data capacity instead of raw. > >>> > >>> So I have a suggestion to translate raw capacity to real data capacity, it can be simply implemented by > >>> taking advantage of num.object_copies, the result may be not very accurate but still having reference significance. > >>> > >> > >> It's not that simple when there are multiple data pools. > > > > I seem to remember someone (Doug or Jeff?) working on a patch that would > > adjust the statfs result for a given directory based on the data pool and > > the usual "max avail" style calculation that 'ceph df' uses per pool > > (which is based on replication/ec multiplier and most-full osd)…? > > I did that in: https://github.com/ceph/ceph/pull/16378 > <https://github.com/ceph/ceph/pull/16378> . This only works for the case > where the filesystem uses a single data pool. In other cases, it falls > back to the old behavior. FWIW, statfs(2) takes a path and fstatfs(2) takes an fd, so at least the user-facing API should be able to handle it. And in the kernel the statfs call super_operations takes a dentry. So it should be possible to do this? sage
