From owner-freebsd-bugs@FreeBSD.ORG Wed Dec 1 16:10:31 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F40B216A4CE for ; Wed, 1 Dec 2004 16:10:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEF7143D41 for ; Wed, 1 Dec 2004 16:10:30 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iB1GAUP9078668 for ; Wed, 1 Dec 2004 16:10:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iB1GAURY078667; Wed, 1 Dec 2004 16:10:30 GMT (envelope-from gnats) Date: Wed, 1 Dec 2004 16:10:30 GMT Message-Id: <200412011610.iB1GAURY078667@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Brooks Davis Subject: Re: bin/74567: [patch] [2TB] du doesn't handle sizes >1TB X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Brooks Davis List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 16:10:31 -0000 The following reply was made to PR bin/74567; it has been noted by GNATS. From: Brooks Davis To: Sergey Salnikov 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