Re: FileAPI use case: making an image downloading app

On Mon, Jan 10, 2011 at 6:11 PM, Eric Uhrhane <ericu@google.com> wrote:
>> #1) The spec says there is a 5000 file limit or directory.
>
> That's a conservative number I chose for performance reasons, not
> because of hard limits.  While most modern filesystems officially
> support far larger directories than that, I've been warned that many
> bog down quite a bit by the time you hit 10000 entries.  If anyone can
> point me to actual data on the major filesystems, I'm happy to bump
> that number up, but I feel that we should have some limit that
> generally works with decent performance on all the major platforms.
> If that means you have to do some work to work around the limit, well,
> you'd probably have to have done that to work around the slowness
> anyway, if you wanted to write a portable app.

Should specs really limit everything to the lowest common denominator?
 I'd sooner see spec recommendations on minimums: how many files an
implementation should be able to handle without error (assuming disk
space doesn't run out first), and an advisory on how many files it
should be handle without serious performance problems.  That gives
implementors the minimums they should test for, and it tells users the
maximums they should use for widest portability, but it doesn't place
arbitrary limitations on systems that can easily handle more.

If I'm implementing a rasterizer that outputs frames to individual
files, then it's okay if that hits file count limits on FAT32.  NTFS
and XFS end-users shouldn't be forced to have such a directory layout
to work around legacy FAT32 problems that don't exist on their system,
and users doing graphics rendering have known to avoid FAT32 for a
long time.  If I want to support splitting up the directories to
support FAT32 (or for other reasons), then as a developer I'll do so,
but I should be able to decide for myself.  (It may be very
inconvenient for users; for example, a directory like that is likely
to be imported into another application, which may or may not support
that.)

-- 
Glenn Maynard

Received on Tuesday, 11 January 2011 00:10:17 UTC