Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E117F1A.2DD85AD@phekda.freeserve.co.uk>
Date: Tue, 31 Dec 2002 11:27:22 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Problem with df reporting the wrong sizes [PATCH]
References: <200212310039 DOT gBV0dlh27254 AT speedy DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

ams AT ludd DOT luth DOT se wrote:
[snip]
> 1. Which way does statfs() do it? (We have a statvfs() too!?) None of
> the above?

statfs is only interested in clusters. But it does have access to the sector
size in some (but not all) cases.

> 2. Why not call or use the statfs() code which has been working well a
> long time?

statvfs does call statfs. But statfs does not return the sector size and its
measurements are in clusters. So either everything returned by statvfs is in
terms of clusters or we have to do some scaling.

> (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.)

I think we should return the cluster size as the fundamental block size.

Currently f_frsize is returned as 512 bytes, which is the usual sector size.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]