bin/74567: [patch] [2TB] du doesn't handle sizes >1TB
Brooks Davis
brooks at one-eyed-alien.net
Wed Dec 1 08:10:31 PST 2004
The following reply was made to PR bin/74567; it has been noted by GNATS.
From: Brooks Davis <brooks at one-eyed-alien.net>
To: Sergey Salnikov <serg at citforum.ru>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: bin/74567: [patch] [2TB] du doesn't handle sizes >1TB
Date: Wed, 1 Dec 2004 08:07:10 -0800
On Wed, Dec 01, 2004 at 02:09:33AM +0300, Sergey Salnikov wrote:
> Here goes the patch. Modified du allocates an int64_t for
> every subdirectory and stores the size there and not in
> fts_number.
It seems like off_t would be more appropriate. Using hard coded types
like long is what got us in to this mess in the first place. :) Have you
done any testing to see how expensive this extra malloc is? It might be
cheaper to use fts_number until it overflows and then start doing
allocations. That would certaintly use more code though.
> Maybe fts_number just has to be 64-bit? It will make
> things faster (no need for extra malloc), but
> involves hacking libc.
fts_number can't change size without a library version bump, but I think
you might be able to add a new entry (assuming there isn't any broken
code that uses sizeof(FTSENT).
-- Brooks
More information about the freebsd-bugs
mailing list