[bookport] Re: Large CF card concerns, plus a reliable way to crash your bookport.
- From: "Richard Ring" <ring.richard@xxxxxxxxxxxxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Mon, 28 Nov 2005 16:31:54 -0600
That is helpful. I tend not to put music on my Bookport, however, that
could change and I was simply wondering how many files could bring on
trouble.
I suppose that the wisest course of action here is to create more
folders with fewer files in each rather than fewer folders with lots of
files in them.
-----Original Message-----
From: bookport-bounce@xxxxxxxxxxxxx
[mailto:bookport-bounce@xxxxxxxxxxxxx]
Sent: Monday, November 28, 2005 4:28 PM
To: bookport@xxxxxxxxxxxxx
Subject: [bookport] Re: Large CF card concerns, plus a reliable way to
crash your bookport.
I have experienced the sluggishness issue, but only after a folder had
somewhere over 100 files in it. I suspect some of this has to do with
file names, but don't know much other than that.
-----Original Message-----
From: bookport-bounce@xxxxxxxxxxxxx
[mailto:bookport-bounce@xxxxxxxxxxxxx]On Behalf Of Richard Ring
Sent: Monday, November 28, 2005 4:18 PM
To: bookport@xxxxxxxxxxxxx
Subject: [bookport] Re: Large CF card concerns, plus a reliable way to
crash your bookport.
So, how many files are we talking about here?
Your message is quite technically detailed but this piece of information
seems to be missing, unless I've missed one again.
And, does the size of individual files seem to make a difference or is
it simply the number of files in a given directory/folder?
I am asking as I have never experienced this.
-----Original Message-----
From: bookport-bounce@xxxxxxxxxxxxx
[mailto:bookport-bounce@xxxxxxxxxxxxx] On Behalf Of Brian Buhrow
Sent: Monday, November 28, 2005 12:54 PM
To: bookport@xxxxxxxxxxxxx
Cc: buhrow@xxxxxxxxxxxxxxxxxxxxx
Subject: [bookport] Large CF card concerns, plus a reliable way to crash
your bookport.
Hello. Before I begin, I want to warn you that this is long,
and I
appologize, but I'm not sure how to fully explain my concerns without
giving the whole story.
The Bookport, at least with firmware version 2.1, doesn't handle
directories with a lot of files in them, gracefully at all. A lot of
files, for those technically minded, means enough directory entries to
cause a directory to be more than one filesystem cluster in size. For a
1
GB filesystem, for example, the cluster size is 16384 bytes, or about
16K.
When a directory contains enough items to cause its size to grow
beyond the initial cluster, browsing through the directory with the *
and #
keys becomes sluggish, especially as one nears the end of the directory.
Starting and stopping the reading of a given file, again, especially
files
near the end of the directory, becomes painfully slow, taking up to 15
seconds for the Bookport to finish writing its bookmark file in the
directory, before the Bookport becomes responsive to the user's requests
again. If the file you're listening to is an MP3 file, skipping forward
and backward from index marker to index marker also becomes sluggish,
the
bookport can take as much as 1.5 or 2 seconds to jump from mark to mark.
Also, if one is listening to an MP3 file, again, especially one near the
end of a large directory, and one hits the "stat" key, the 8 keyy, after
one has listened to more than half the file, the most likely result is a
spactacular crash where Bookport says the following:
"Fs panic, buffer claim error", followed by intermittent bits of the MP3
file, interspersed with the words, "Audio file read error". This crash
varies in detail, leading me to speculate that there is a fairly common
race condition in the Bookport firmware whereby two threads or processes
inside the Bookport are trying to access the filesystem at once, with
less
than desirable results.
OK, you say, so don't create directories with large numbers of
files
in them. Well, one can do that, but as filesystems get larger, i.e. as
the
2GB limit is broken, then the 4GB limit, then the 8GB limit, etc. the
desire to put more and more on the Bookport will, I think grow. Having
an
effective limit to the size of non-root directories places, I believe,
some
fairly unfriendly user interface constraints on the Bookport. For
example,
I like to keep my music files in one directory on the Bookport. By
doing
this, I can turn on automatic file advancement, and turn my bookport
into a
continuous music player without having to fiddle around with making sure
that it's reading from the "correct" music directory. Also, given the
relatively complex operations needed to get the Bookport transfer
software
to create a vertical directory structure on the Bookport, I think most
people will "laze out" and tend to stuff their files into one directory
until Bookport's directory limitations become more obvious.
In short, while I don't consider Bookport's current behavior a
show
stopper, I know how to avoid the spactacular crashes associated with
this
problem, I do consider that it will become more of an issue as the size
of
the medium Bookport supports grows larger and larger. Perhaps the good
folks at APH are already aware of this behavior, and, as part of the
changes necessary to support larger filesystems, they've addressed the
issue. If that's so, then that's great, and I'll be quiet. :) If, on
the
other hand, they're not aware of the issue, I'd like to bring it up, and
politely suggest that it be looked into as part of the retooling process
necessary to support larger filesystems. Right now, the apparent race
condition doesn't appear to cause filesystem corruption on the CF card,
but
if the issue cropped up more often on larger CF cards, I could see how
it
might. In any case, I think, left unchecked, this issue might become a
thorn in the support desk's side, which, given their helpful and
friendly
nature, would be a shame. :)
-Brian
Other related posts:
