[fuse-devel] Fwd: Read: zero size??!!

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

---------- Forwarded message ----------
From: Stef Bon <st...@gm...>
Date: 2011/7/19
Subject: Re: [fuse-devel] Read: zero size??!!
To: John Haechten <jha...@cr...>

Yes,

thank you for your reaction. I was completely stuck here. Somehow the
problem here is solved, but I do not know how. Below a log, and you
can see here the problem with zero size is solved.

Maybe the application was doing this (vlc media player). It also tries
to open the file more than once, you see multiple OPEN calls for the
same file.
The fs blocks the second attempt. My fs considers the open of a
virtual entry (=decode file) as exclusive.

Now I still do have it working, the decoder does not read anything. I
will get back when I've got this working.

Stef

Jul 16 21:45:35 clfs20091030 basefs: OPEN
Jul 16 21:45:35 clfs20091030 basefs: determine_localhost_path
Jul 16 21:45:35 clfs20091030 basefs: virtual entry test.aiff, looking
for path of real entry
Jul 16 21:45:35 clfs20091030 basefs: abspath: /home/sbon/testdir/root/test.flac
Jul 16 21:45:35 clfs20091030 basefs: determine_fuse_path:
Jul 16 21:45:35 clfs20091030 basefs: relpath: test.flac
Jul 16 21:45:35 clfs20091030 basefs: fd: 3
Jul 16 21:45:35 clfs20091030 basefs: open_virtual, test.flac
Jul 16 21:45:35 clfs20091030 basefs: fopen file
/home/sbon/testdir/root/test.flac
Jul 16 21:45:35 clfs20091030 basefs: creating new flac-aiff decoder context
Jul 16 21:45:35 clfs20091030 basefs: fusepath: test.flac
Jul 16 21:45:35 clfs20091030 basefs: determine_localhost_path
Jul 16 21:45:35 clfs20091030 basefs: abspath: /home/sbon/testdir/root/test.flac
Jul 16 21:45:35 clfs20091030 basefs: relpath: test.flac
Jul 16 21:45:35 clfs20091030 basefs: fd: 3
Jul 16 21:45:35 clfs20091030 basefs: open_virtual, test.flac
Jul 16 21:45:35 clfs20091030 basefs: already open..
Jul 16 21:45:35 clfs20091030 basefs: open nreturn: -13
Jul 16 21:45:35 clfs20091030 basefs: thread 9: set state to not busy
Jul 16 21:45:35 clfs20091030 basefs: open nreturn: 0
Jul 16 21:45:35 clfs20091030 basefs: thread 8: set state to not busy
Jul 16 21:45:35 clfs20091030 basefs: mainloop: sem post for thread 0
Jul 16 21:45:35 clfs20091030 basefs: thread 0 waking up, setting state to busy
Jul 16 21:45:35 clfs20091030 basefs: data found, start fuse_session_process
Jul 16 21:45:35 clfs20091030 basefs: STATFS
Jul 16 21:45:35 clfs20091030 basefs: determine_fuse_path:
Jul 16 21:45:35 clfs20091030 basefs: fusepath: test.aiff
Jul 16 21:45:35 clfs20091030 basefs: statfs, B, nreturn: 0
Jul 16 21:45:35 clfs20091030 basefs: thread 0: set state to not busy
Jul 16 21:45:35 clfs20091030 basefs: mainloop: sem post for thread 1
Jul 16 21:45:35 clfs20091030 basefs: thread 1 waking up, setting state to busy
Jul 16 21:45:35 clfs20091030 basefs: data found, start fuse_session_process
Jul 16 21:45:35 clfs20091030 basefs: READ, offset 0 and size (>0) 4096
Jul 16 21:45:35 clfs20091030 basefs: read_virtual, offset 0 and size 4096
Jul 16 21:45:35 clfs20091030 basefs: calling aiffread from read_virual
Jul 16 21:45:35 clfs20091030 basefs: AiffRead with offset 0 and size 4096
Jul 16 21:45:35 clfs20091030 basefs: read, 0 bytes read
Jul 16 21:45:35 clfs20091030 basefs: thread 1: set state to not busy
Jul 16 21:45:35 clfs20091030 basefs: mainloop: sem post for thread 2
Jul 16 21:45:35 clfs20091030 basefs: thread 2 waking up, setting state
to busy
Jul 16 21:45:35 clfs20091030 basefs: data found, start
fuse_session_process
Jul 16 21:45:35 clfs20091030 basefs: RELEASE
Jul 16 21:45:35 clfs20091030 basefs: release virtual
Jul 16 21:45:35 clfs20091030 basefs: release, nreturn 0
Jul 16 21:45:35 clfs20091030 basefs: thread 2: set state to not busy

2011/7/18 John Haechten <jha...@cr...>:
> I have worked in the storage industry for many years, in the FC storage router business.  This read will translate into a SCSI READ Cmd of Zero Length.  These do occur and have to be handled.  I do not know what information is gained from a Zero Length Read other than READ Access is granted to the file.  The Media can not change position or move.  If it was for 4 or 8 bytes, I'd say that the application is getting the size of the file, but Zero really has no use other than the application miscalculated something, possibly.
>
> John Haechten
>
>
> -----Original Message-----
> From: Stef Bon [mailto:st...@gm...]
> Sent: Saturday, July 16, 2011 12:05 PM
> To: fus...@li...
> Subject: [fuse-devel] Read: zero size??!!
>
> Hi,
>
> I've a strange problem. My fs is a simple overlay fs, mounted at
>
> /home/sbon/testdir/mount
>
> where the backend is
>
> /home/sbon/testdir/root
>
> In the root is testfile, which also appears correctly, with the right size.
>
>
> But with reading a file, after open, I get a zero size:
>
> Jul 16 18:46:48 clfs20091030 basefs: OPEN
> Jul 16 18:46:48 clfs20091030 basefs: determine_fuse_path:
> Jul 16 18:46:48 clfs20091030 basefs: fusepath: testfile
> Jul 16 18:46:48 clfs20091030 basefs: determine_localhost_path
> Jul 16 18:46:48 clfs20091030 basefs: abspath: /home/sbon/testdir/root/testfile
> Jul 16 18:46:48 clfs20091030 basefs: relpath: testfile
> Jul 16 18:46:48 clfs20091030 basefs: fd: 3
> Jul 16 18:46:48 clfs20091030 basefs: open_localhost
> Jul 16 18:46:48 clfs20091030 basefs: open_localhost, opening via fd
> Jul 16 18:46:48 clfs20091030 basefs: open_localhost: fd: 13
> Jul 16 18:46:48 clfs20091030 basefs: open nreturn: 13
> Jul 16 18:46:48 clfs20091030 basefs: thread 5: set state to not busy
> Jul 16 18:46:48 clfs20091030 basefs: mainloop: sem post for thread 6
> Jul 16 18:46:48 clfs20091030 basefs: thread 6 waking up, setting state to busy
> Jul 16 18:46:48 clfs20091030 basefs: data found, start fuse_session_process
> Jul 16 18:46:48 clfs20091030 basefs: READ, offset 0 and size 0
> Jul 16 18:46:48 clfs20091030 basefs: read_localhost
> Jul 16 18:46:48 clfs20091030 basefs: read, 10 bytes read
> Jul 16 18:46:48 clfs20091030 basefs: thread 6: set state to not busy
> Jul 16 18:46:48 clfs20091030 basefs: mainloop: sem post for thread 7
> Jul 16 18:46:48 clfs20091030 basefs: thread 7 waking up, setting state to busy
> Jul 16 18:46:48 clfs20091030 basefs: data found, start fuse_session_process
> Jul 16 18:46:48 clfs20091030 basefs: READ, offset 0 and size 0
> Jul 16 18:46:48 clfs20091030 basefs: read_localhost
> Jul 16 18:46:48 clfs20091030 basefs: read, 10 bytes read
> Jul 16 18:46:48 clfs20091030 basefs: thread 7: set state to not busy
> Jul 16 18:46:48 clfs20091030 basefs: mainloop: sem post for thread 8
> Jul 16 18:46:48 clfs20091030 basefs: thread 8 waking up, setting state to busy
> Jul 16 18:46:48 clfs20091030 basefs: data found, start fuse_session_process
> Jul 16 18:46:48 clfs20091030 basefs: RELEASE
> Jul 16 18:46:48 clfs20091030 basefs: release_localhost, fd: 13
> Jul 16 18:46:48 clfs20091030 basefs: release, nreturn 0
>
>
> I've never seen this before. READ starts at offset 0 AND size 0!
> Well my fs allocates a buffer with size size, so this will return
> nothing, that's not suprising, but the size
> as parameter is zero (the READ callback is called with zero size)??
>
> Stef
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> fuse-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>