Skip to contentSkip to conversation

ceph:Update the file time after mmap-write.

PATCH In review majianpeng 3 participants 8 messages Jul 11, 2013 – Jul 12, 2013 Ceph client

lore
Share & tools
lore

majianpeng

author
#0 lore raw

PATCH 1/1 ceph:Update the file time after mmap-write.

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.

---
 fs/ceph/addr.c | 8 ++++++++
 1 file changed, 8 insertions(+)
fs/ceph/addr.c +8 -0
index 38b5c1b..52f7c7c 100644
@@ -1231,10 +1231,18 @@ static int ceph_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 
 	ret = ceph_update_writeable_page(vma->vm_file, off, len, page);
 	if (ret == 0) {
+		int dirty;
+		struct ceph_inode_info *ci = ceph_inode(inode);
 		/* success.  we'll keep the page locked. */
 		set_page_dirty(page);
 		up_read(&mdsc->snap_rwsem);
 		ret = VM_FAULT_LOCKED;
+
+		spin_lock(&ci->i_ceph_lock);
+		dirty = __ceph_mark_dirty_caps(ci, CEPH_CAP_FILE_WR);
+		spin_unlock(&ci->i_ceph_lock);
+		if (dirty)
+		       	__mark_inode_dirty(inode, dirty);
 	} else {
 		if (ret == -ENOMEM)
 			ret = VM_FAULT_OOM;
Signature · 1 line
1.8.1.2
#1 lore raw
Quoted 3 lines · majianpeng

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

Quoted 31 lines
---
 fs/ceph/addr.c | 8 ++++++++
 1 file changed, 8 insertions(+)
fs/ceph/addr.c +8 -1
index 38b5c1b..52f7c7c 100644
@@ -1231,10 +1231,18 @@ static int ceph_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 
        ret = ceph_update_writeable_page(vma->vm_file, off, len, page);
        if (ret == 0) {
+               int dirty;
+               struct ceph_inode_info *ci = ceph_inode(inode);
                /* success.  we'll keep the page locked. */
                set_page_dirty(page);
                up_read(&mdsc->snap_rwsem);
                ret = VM_FAULT_LOCKED;
+
+               spin_lock(&ci->i_ceph_lock);
+               dirty = __ceph_mark_dirty_caps(ci, CEPH_CAP_FILE_WR);
+               spin_unlock(&ci->i_ceph_lock);
+               if (dirty)
+                       __mark_inode_dirty(inode, dirty);
        } else {
                if (ret == -ENOMEM)
                        ret = VM_FAULT_OOM;
--

1.8.1.2

author
#2 lore raw
Quoted 9 lines · majianpeng
Quoted 3 lines

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.

Thanks, i'll add this check and resent.

Jianpeng Ma

Quoted 34 lines

Yan, Zheng

Quoted 31 lines
---
 fs/ceph/addr.c | 8 ++++++++
 1 file changed, 8 insertions(+)
fs/ceph/addr.c +8 -1
index 38b5c1b..52f7c7c 100644
@@ -1231,10 +1231,18 @@ static int ceph_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 
        ret = ceph_update_writeable_page(vma->vm_file, off, len, page);
        if (ret == 0) {
+               int dirty;
+               struct ceph_inode_info *ci = ceph_inode(inode);
                /* success.  we'll keep the page locked. */
                set_page_dirty(page);
                up_read(&mdsc->snap_rwsem);
                ret = VM_FAULT_LOCKED;
+
+               spin_lock(&ci->i_ceph_lock);
+               dirty = __ceph_mark_dirty_caps(ci, CEPH_CAP_FILE_WR);
+               spin_unlock(&ci->i_ceph_lock);
+               if (dirty)
+                       __mark_inode_dirty(inode, dirty);
        } else {
                if (ret == -ENOMEM)
                        ret = VM_FAULT_OOM;
--

1.8.1.2

author
#3 lore raw
In reply to Yan, Zheng
Quoted 5 lines · majianpeng
Quoted 3 lines

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.

Quoted 7 lines

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?

Thanks!
Jianpeng Ma

#4 lore raw
Quoted 9 lines · majianpeng
Quoted 9 lines · majianpeng
Quoted 3 lines

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.

Quoted 9 lines
Quoted 3 lines

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

Quoted 2 lines

Thanks!
Jianpeng Ma

author
#5 lore raw
Quoted 20 lines · majianpeng
Quoted 9 lines
Quoted 9 lines · majianpeng
Quoted 3 lines

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.

Quoted 9 lines
Quoted 3 lines

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?

Quoted 7 lines

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

Thanks your suggestion.
Unless we get the Fcb cap, we can do the mmap-io.How about this? Because the cap can change,so we can using Fx to lock the file, so cap can't change.

Quoted 3 lines
Quoted 3 lines

Thanks!
Jianpeng Ma

#6 lore raw
In reply to Yan, Zheng
Quoted 20 lines · Zheng
Quoted 9 lines · majianpeng
Quoted 9 lines · majianpeng
Quoted 3 lines

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.

Quoted 9 lines
Quoted 3 lines

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?

Quoted 6 lines

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

#7 lore raw
Quoted 28 lines · Gregory Farnum
Quoted 20 lines · Zheng
Quoted 9 lines · majianpeng
Quoted 9 lines · majianpeng
Quoted 3 lines

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.

Quoted 9 lines
Quoted 3 lines

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?

Quoted 6 lines

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

Quoted 4 lines

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?

For mmap write, the kernel has no way to know when an write operation is finished,
so it can't do synchronous write to the OSD.

Yan, Zheng
Regards

Quoted 2 lines

-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com