[bookport] Re: Large CF card concerns, plus a reliable way to crash your bookport.
- From: buhrow@xxxxxxxxxxxxxxxxxxxxx (Brian Buhrow)
- To: bookport@xxxxxxxxxxxxx
- Date: Mon, 28 Nov 2005 14:39:01 -0800
I'm seeing it with about 366 files in a subdirectory. Remember, I'm
talking physical files, not items in the browse list. Each item in the
browse list represents 2 or 3 files, depending on whether or not you've
listened to the item. The length of the files doesn't matter, but the
length of the file names themselves probably does. The shorter the file
name, the more files you need to exhibit the behavior. The key, I think,
is that the directory must be multiple clusters in length, and because the
cluster size varies with filesystem size, the actual number of files
needed varies from filesystem size to filesystem size.
-Brian
On Nov 28, 4:17pm, "Richard Ring" wrote:
} Subject: [bookport] Re: Large CF card concerns, plus a reliable way to cra
} 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
}
}
}
}
>-- End of excerpt from "Richard Ring"
Other related posts:
