On Thu, Jul 11, 2013 at 2:03 AM, Yan, Zheng <ukernel@xxxxxxxxx> wrote: > On Thu, Jul 11, 2013 at 3:53 PM, majianpeng <majianpeng@xxxxxxxxx> wrote: >>>On Thu, Jul 11, 2013 at 9:17 AM, majianpeng <majianpeng@xxxxxxxxx> wrote: >>>> Although, mmap-write of ceph update the time of file using >>>> file_update_time.Because it don't mark the relative cap so the time >>>> can't save. >>> >>>I think cephfs' mmap IO support is still broken. mmap IO does not respect >>>ceph capabilities at all. It's possible that the kclient has no Fw cap when >>>ceph_page_mkwrite is called. >>> >>>Yan, Zheng >>> >>> >> Hi Yan, >> For the read of mmap, i think we also add cap-check. >> And i think we can rewrite the filemap_fault ect ceph_filemap_fault. >> In ceph_filemap_fault, most code from filemap_fault, we only add cap-check for read-operation. >> How about this or can you suggest anthor method? >> > > This doesn't work. if a file is opened by multiple clients, the MDS > doesn't issue Fcb caps to the client. > If we add cap check to filemap_fault and page_mkwrite, they can block > forever. To make mmap IO work > properly, I think the only solution is introducing a new cache > coherence protocol for mmap IO I'm not familiar with the mmap IO paths here at all, but is there some reason we need Fcb for it? Not having those just means everything needs to be synchronous to the OSD, which is going to be hella slow but should be legal? -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- 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
