From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41560 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzPjd-0000Yd-NQ for qemu-devel@nongnu.org; Tue, 15 Mar 2011 04:36:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzPjc-0002yp-BM for qemu-devel@nongnu.org; Tue, 15 Mar 2011 04:36:09 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:45285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzPjb-0002yP-PT for qemu-devel@nongnu.org; Tue, 15 Mar 2011 04:36:08 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp07.au.ibm.com (8.14.4/8.13.1) with ESMTP id p2F8a21f031884 for ; Tue, 15 Mar 2011 19:36:02 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2F8a0RK2326722 for ; Tue, 15 Mar 2011 19:36:02 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2F8ZxHA011284 for ; Tue, 15 Mar 2011 19:36:00 +1100 From: "Aneesh Kumar K. V" Subject: Re: [Qemu-devel] [PATCH -V3 2/8] hw/9pfs: Add file descriptor reclaim support In-Reply-To: References: <1299347533-17047-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1299347533-17047-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <87d3lurgpo.fsf@linux.vnet.ibm.com> Date: Tue, 15 Mar 2011 14:05:54 +0530 Message-ID: <87oc5cwzkl.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Mon, 14 Mar 2011 10:13:59 +0000, Stefan Hajnoczi wr= ote: > On Sun, Mar 13, 2011 at 6:57 PM, Aneesh Kumar K. V > wrote: > > On Sun, 13 Mar 2011 16:08:29 +0000, Stefan Hajnoczi wrote: > >> On Sat, Mar 5, 2011 at 5:52 PM, Aneesh Kumar K.V > >> wrote: > >> > @@ -107,7 +108,12 @@ static int v9fs_do_closedir(V9fsState *s, DIR *= dir) > >> > > >> > =C2=A0static int v9fs_do_open(V9fsState *s, V9fsString *path, int fl= ags) > >> > =C2=A0{ > >> > - =C2=A0 =C2=A0return s->ops->open(&s->ctx, path->data, flags); > >> > + =C2=A0 =C2=A0int fd; > >> > + =C2=A0 =C2=A0fd =3D s->ops->open(&s->ctx, path->data, flags); > >> > + =C2=A0 =C2=A0if (fd > P9_FD_RECLAIM_THRES) { > >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0v9fs_reclaim_fd(s); > >> > + =C2=A0 =C2=A0} > >> > >> I think the threshold should depend on the file descriptor ulimit. > >> The hardcoded constant doesn't work if the ulimit is set to 1000 or > >> less (it would cause other users in QEMU to hit EMFILE errors). > > > > Yes. That is suppose to be a follow up patch. I had that set to 100 for > > all the early testing. >=20 > Using getrlimit(2) to choose a good threshold at runtime shouldn't be > a lot of code. Please add it to this patch so the threshold isn't > arbitrary and possibly ineffective due to ulimit. ok. >=20 > >> > @@ -2719,7 +2806,11 @@ static void v9fs_remove(V9fsState *s, V9fsPDU= *pdu) > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D -EINVAL; > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto out; > >> > =C2=A0 =C2=A0 } > >> > - > >> > + =C2=A0 =C2=A0/* > >> > + =C2=A0 =C2=A0 * IF the file is unlinked, we cannot reopen > >> > + =C2=A0 =C2=A0 * the file later. So don't reclaim fd > >> > + =C2=A0 =C2=A0 */ > >> > + =C2=A0 =C2=A0v9fs_mark_fids_unreclaim(s, &vs->fidp->fsmap.path); > >> > >> This poses a problem for the case where guest and host are both > >> accessing the file system. =C2=A0If the fd is reclaimed and the host > >> deletes the file, then the guest cannot access its open file anymore. > >> > >> The same issue also affects rename and has not been covered by this pa= tch. > >> > > > > Currently virtFS don't handle the host rename/unlink. That we walk > > a name and get the fid and then use the fid to open the file. In between > > if the file get removed/renamed we will get an EINVAL. > > > > All that will go away once we switch to handle based open. >=20 > Can you explain this more? Will multiple entities be able to safely > use the file system (e.g. host and guest)? handles are stable across renames. So even if host rename the file, qemu will be able to access it. But we still won't be able to handle unlink on host. But that is true with even other file servers. They do get ESTALE in that case. -aneesh