Date: Sat, 13 Feb 2010 13:31:04 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Gustau =?ISO-8859-1?Q?P=E9rez?= <gperez@entel.upc.edu> Cc: freebsd-gnome@freebsd.org Subject: Re: Problems accessing files with gvfs-fuse-daemon Message-ID: <1266085864.3346.75.camel@shumai.marcuscom.com> In-Reply-To: <4B76E0CB.6040806@entel.upc.edu> References: <4B6D4624.803@entel.upc.edu> <4B6F1D6B.2070408@entel.upc.edu> <1265573861.24140.3.camel@shumai.marcuscom.com> <4B6F21B3.1020303@entel.upc.edu> <1265574585.24140.6.camel@shumai.marcuscom.com> <4B6F262D.1020509@entel.upc.edu> <1265575770.1685.0.camel@shumai.marcuscom.com> <4B76E0CB.6040806@entel.upc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-eyZmGk1jeLbxhyGBJft8
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
On Sat, 2010-02-13 at 18:26 +0100, Gustau P=E9rez wrote:
> Hello again,
> > Look at what direct_io does, and start there. What is different when
> > that option is specified? That option is never passed to the gvfs code=
,
> > so where in the fuse code does it make an impact?
> >
> > Joe
> > =20
> tried to contact fusefs-{libs|kmod} but I still got no answer. In
> the meantime, I tried to follow the execution of a request, and
> found where it gets stuck.
>=20
> I tried to discover what direct_io does. But fusefs-{libs|kmod} is a
> new world for me, so I decided to investigate gvfs first.
>=20
> It seems that everything fails in function "static gint
> gettatr_for_file", in the $WRKDIR/client/gvfsfusedaemon.c when calling
> g_file_query_info (which is part of the glib20). To be exact, it asks
> for a number of attributes, one of them is
> "G_FILE_ATTRIBUTE_STANDARD_SIZE".
>=20
> If I remove this attribute from the g_file_query_info call,
> gvfsfusedaemon doesn't get stuck anymore. The problem is that no app
> will be able to use file mounted with gvfs, as all the apps want to know
> the size of the files they are working with.
>=20
> So it seems gvfsfusedaemon does not get stuck, but it's me who does
> not know how to solve the problem, because I don't know
> how "g_file_query_info" gets info about a file in $HOME/.gvfs/... I
> think that when g_file_query_info is called (in glib) it
> should in turn try to stat the file, and should be done through fuse,
> which in turn will call again gvfsfusedaemon for the info.
>=20
> I don't know whether I'm right or not. And in if I'm right, I don't
> how to move forward. Does anyone have an idea how to continue ?
This sounds right. Chances are things are locking up somewhere in the
kernel. You should first try breaking into the hung application (and
gvfs-fuse-daemon) with gdb, and get an idea of where in the code path
it's hanging. I'm betting you will then need to break into the kernel
debugger, and see where in the kernel things get stuck.
Joe
>=20
> Regards,
>=20
> Gus
>=20
> =20
>=20
>=20
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-eyZmGk1jeLbxhyGBJft8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEABECAAYFAkt27+YACgkQb2iPiv4Uz4cTLgCggCr9XIRdx8IktIFb1ztjdt+6
GbgAoKzwRyHG2fMaTJ9iPDe7w58J/zS4
=bKPl
-----END PGP SIGNATURE-----
--=-eyZmGk1jeLbxhyGBJft8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1266085864.3346.75.camel>