Yes, we also successfully use mplayer with gfarm-fuse+autofs, patched
with my earlier patch. The problem now is that sometimes it randomly
hang. Dont' quite sure what's the cause of this problem (maybe cause by
my patch). We're trying to trace the cause of this problem right now.
We've workaround this problem by sending SIGINT to fusermount process
and the frozen process will continue again.
Takuya Ishibashi wrote:
Hello Somsak,
mplayer can play and seek a file ( > 1GB) on GfarmFS-FUSE in my
environment (Fedora Core 5, 32bit).
Can you do it on fusexmp_fh filesystem?
fusexmp_fh is included in FUSE source package.
(Please see README of FUSE)
Regards,
--
Takuya Ishibashi
From: Somsak Sriprayoonsakul <somsak_sr@xxxxxxxxxxxxxx>
Subject: [gfarm-discuss:03644] Re: [Fwd:[Fwd:32bit application segmentation fault on 64bit]]
Date: Thu, 17 Aug 2006 12:13:24 +0700
Dear Noriyuki-san
Here's the strace log of gfarm-fuse with mplayer (NOT the strace log
of running 32bit app, I'm not finish with reompilation & re-installation
of 32bit gfarm yet).
Thank you very much.
-------- Original Message --------
Subject: Re: [Fwd: [gfarm-discuss:03635] Re: 32bit application
segmentation fault on 64bit]
Date: Thu, 17 Aug 2006 10:50:39 +0700
From: Sugree Phatanapherom <sugree_ph@xxxxxxxxxxxxxx>
To: somsak_sr@xxxxxxxxxxxxxx
References: <44E31C98.5040209@xxxxxxxxxxxxxx>
Oops! I'm sorry. It is not exactly _llseek() but _llseek() with read()
----------------> snippet <----------------
open("combination-1531.inp", O_RDONLY|O_LARGEFILE) = 3
_llseek(3, 0, [400910354], SEEK_END) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
_llseek(3, 0, [0], SEEK_SET) = 0
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, 0x880703c, 2048) = -1 EINVAL (Invalid argument)
----------------> snippet <----------------
Sugree
Somsak Sriprayoonsakul wrote:
What's the problem about lseek?
-------- Original Message --------
Subject: [gfarm-discuss:03635] Re: 32bit application segmentation
fault on 64bit
Date: Wed, 16 Aug 2006 21:06:43 +0900
From: SODA Noriyuki <soda@xxxxxxxxx>
Reply-To: gfarm-discuss@xxxxxxxxxx
To: Somsak Sriprayoonsakul <somsak_sr@xxxxxxxxxxxxxx>
CC: gfarm-discuss@xxxxxxxxxx
References:
<452F37AE49199D49B1702D7D45038C4D6B0E13@xxxxxxxxxxxxxx>
<44E2A2A1.3030804@xxxxxxxxxxxxxx>
On Wed, 16 Aug 2006 11:44:17 +0700,
Somsak Sriprayoonsakul <somsak_sr@xxxxxxxxxxxxxx> said:
Maybe it's worthwhile to check out Gfarm-Fuse system. In our
experience,
the Gfarm-Fuse is much more stable in supporting preexisting
applications.
Yes. Actually we already tested that and gfarm-fuse work great in
term of performance. Somehow gfarm-fuse only accept single user per
mounted file system, also it does not support lseek system call,
which is required by some application. That's why we're trying to use
user-level instead.
Hmm? What is the problem about lseek?
As far as I know, lseek just does work with GfarmFS-FUSE.
Thus, if you could allow your users to mount gfarm filesystem via
GfarmFS-FUSE, certainly it could be an option as Wilfred said.
If your problem with lseek was a data coherency problem, please try
"-unbuf" option of GfarmFS-FUSE.
--
-----------------------------------------------------------------------------------
Somsak Sriprayoonsakul
Thai National Grid Center
Software Industry Promotion Agency
Ministry of ICT, Thailand
somsak_sr@xxxxxxxxxxxxxx
-----------------------------------------------------------------------------------
--
-----------------------------------------------------------------------------------
Somsak Sriprayoonsakul
Thai National Grid Center
Software Industry Promotion Agency
Ministry of ICT, Thailand
somsak_sr@xxxxxxxxxxxxxx
-----------------------------------------------------------------------------------
|