Re: [njbfs-devel] njb issues (fwd)

[Ben O. <be...@gi...>]

> Ben Osheroff wrote:
>
> > -the njb doesn't like reads at arbitrary locations
>
> Are you sure? Well playing with file seeks, I found the njb is just working
> with high latency at random seeks, but it works - xmms gets the right ID3
> tags at random file positions.

Yeah, I've noticed that behavior too... it seems to seek to the end of the
file and read there just fine, but when some arbitrary block in the middle
of the file is requested, a song just starts over from the beginning.
Did you notice that behavior?

> I do not recommend bypassing the VFS. It saves a lot of code that we would
> have to write then on our own,  e.g. dealing with swapping pages. To manage
> the page cache, you could look at the code in other file systems how they
> managed that situation. It should be safe to let the Linux VM allocate pages
> of 4K for our file buffer operations, delegate the low level stuff to the VFS
> and let njbfs deal with higher level operations.

Yup, I've looked into the nfs code.  I don't wanna go there =).  I have
figured out a way to simply call back into the VFS and request reads,
using do_generic_file_read and some tricky lock bypassing.  It seems to
make seeks work real nice for me... current source is attached if you want
to check it out.

>
> The njb can only be addressed by a single host via USB. I doubt if it can
> manage multiple tracks - opening two files locked up the device. The policy I
> tried to implement is: capture the device, open exactly one file, read from
> it - write to it, close this file, release the device. If there are more
> accesses, they should be explicitly rejected with "device busy" (-EBUSY), not
> with a lock, which only delays I/O access.
>

The only problem I can see with this approach is that some programs
(musicmatch, for instance) will simply require lots of open files at one
time... when you are playing a file, if you add another to the queue, it
will attempt to open that file and read in the id3 tags.  The ID3 tag
faking alleviated this somewhat.

The policy in the code that I've sent is this:
-only request the track from the jukebox when an read is requested that
needs the jukebox.
-if another file is currently being read from the jukebox, close it down
and begin the transfer of the second file

I'm not sure if this is a sane policy... if you're playing a file and
attempt to 'cp' another one off, each will just slowly crawl along,
opening and closing the other file.  I think today I'm going to attempt
reading ahead about 300k into the file being closed to see if I can get
adequate performance... and maybe try sharing the drive on gnutella to see
what happens =)

> Another unfixed problem I fight with, maybe it can be reproduced: xmms
> performs heavy buffer underruns when starting playing an MP3 track from the
> njb directly, resulting in 20-30 seconds missing at the beginning of a song.
> The underrun results because the I/O is asynchronous, I have not found out
> how to synchronize buffer flushes. It seems when xmms has filled the internal
> xmms buffer completely, it will start to play but at the wrong position. When
> reaching the end of time, it will play silence - weird. This can also be a
> buffer problem.

hmmm, weird. I'll have to get my soundcard up under linux and try it out.

-ben