From: Message-Id: <200212310039.gBV0dlh27254@speedy.ludd.luth.se> Subject: Re: Problem with df reporting the wrong sizes [PATCH] In-Reply-To: "from Richard Dawe at Dec 30, 2002 01:05:32 pm" To: djgpp-workers AT delorie DOT com Date: Tue, 31 Dec 2002 01:39:46 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamScore: s Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk According to Richard Dawe: > I've just taken a look at why df (from fileutils 4.1) reports > the wrong sizes. This problem is with df built against DJGPP CVS. Thanks! > The problem arises because we return inconsistent information > in 'struct statvfs' from statvfs() and fstatvfs(). The f_blocks member > is supposed to contain the number of free blocks of size f_frsize. > f_frsize is the fundamental block size in bytes. In our implementation > f_blocks contains the number of free clusters. f_frsize is a fixed value - > 512 bytes - which represents most common sector sizes. > > Sources: New POSIX standard, draft 7; Single Unix Specification, version 2 > > The amount of free disk space is f_frsize * f_blocks. There's a large > discrepancy between this and the actual free space on my FAT32 disk, > which has 16K clusters. > > There are a few solutions that I can see: > > (a) Set f_frsize to the same size as the cluster size. We pretend > that the fundamental block size is the cluster size. > > This is the simplest solution. There's a patch below. > > (b) Modify the code to find the real sector size. Then scale > the free block size numbers by (cluster size / sector size), > to give the correct figures for free sectors. > > This method could be troublesome, unless we assume that > cluster sizes are always equal to the sector size multiplied > by a power of 2. > > *statvfs() use statfs() to get their information. Looking at > the statfs code, it doesn't look like all the methods for finding > disk space (CD-ROM, Windows '9x, Windows '9x other method) return > the sector size. If not all the methods return the sector size, > then this method can't really be used (we can only really support > the "common lowest denominator"). > > (c) Assume a 512 byte sector size and then scale the free block size > numbers as in (b). 1. Which way does statfs() do it? (We have a statvfs() too!?) None of the above? 2. Why not call or use the statfs() code which has been working well a long time? (3. Personally I like the way statfs() returns cluster size. Why wouldn't cluster size be "fundamental block size"? It surely is in FAT file system, isn't it? Or are you saying the f_frsize is supposed to fixed across all file systems on the OS? That sounds silly.) Right, MartinS