delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/12/31/06:27:29

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>
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/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019