lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877hbl0xxq.fsf@linux.vnet.ibm.com>
Date:	Sun, 27 Mar 2011 13:58:33 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Venkateswararao Jujjuri <jvrao@...ux.vnet.ibm.com>
Cc:	v9fs-developer@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [V9fs-developer] [PATCH 3/5] 9p: revert tsyncfs related changes

On Fri, 25 Mar 2011 14:20:04 -0700, Venkateswararao Jujjuri <jvrao@...ux.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.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ