Date: Wed, 1 Dec 2004 16:10:30 GMT From: Brooks Davis <brooks@one-eyed-alien.net> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/74567: [patch] [2TB] du doesn't handle sizes >1TB Message-ID: <200412011610.iB1GAURY078667@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/74567; it has been noted by GNATS. From: Brooks Davis <brooks@one-eyed-alien.net> To: Sergey Salnikov <serg@citforum.ru> Cc: FreeBSD-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412011610.iB1GAURY078667>