lkml.org 
[lkml]   [2011]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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



    \
     
     \ /
      Last update: 2011-03-28 00:27    [W:2.918 / U:0.636 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site