Messages in this thread | | | Date | Sun, 27 Mar 2011 15:24:58 -0700 | From | Venkateswararao Jujjuri <> | Subject | Re: [V9fs-developer] [PATCH 3/5] 9p: revert tsyncfs related changes |
| |
On 03/27/2011 01:28 AM, Aneesh Kumar K. V wrote: > On Fri, 25 Mar 2011 14:20:04 -0700, Venkateswararao Jujjuri<jvrao@linux.vnet.ibm.com> wrote: >> On 03/25/2011 04:30 AM, Aneesh Kumar K.V wrote: >>> Now that we use write_inode to flush server >>> cache related to fid, we don't need tsyncfs. >>> This help us to do a more efficient server flush >>> for dotu protocol >> Why are you singling out dotu only? won't it be applicable to dotl too? >> > With dotl we can have new operations and so we added tsyncfs. The > primary goal is to add an operation that can flush server cache. We > hooked that to sync(2) on the client. With dotu we cannot add new > operations so we always forced the write on the server in case of dotu > to O_SYNC. That is much slower than doing an fsync on write_inode. But > whether doing an fsync on write inode is better than doing tsyncfs on > sync(2) on client is something i haven't yet measured. Stefan Hajnoczi wants to > see some numbers before we push tsyncfs in the server(qemu). We also don't > want a kernel release with 9p operation which we may remove later. So > the plan now is to get write_inode changes upstream in this merge window > and later get numbers against tsyncfs/write_inode -> fsync and add tsyncfs only > if we see a benefit. BTW NFS use the write_inode approach.
Nice explanation. I looked at NFS and realized that they also follow write_inode approach. So I think you should make it explict that this will be helpful to dotl also and may and TFSYNCFS in the future if needed. With that I ack this.
Reviewed-by : Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
> -aneesh
| |