Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E1425A4.FB7DCD6D@phekda.freeserve.co.uk>
Date: Thu, 02 Jan 2003 11:42:28 +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: <200301011428 DOT h01ESxm14873 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]
> If you're talking about file system block size, no. 4096 seem to be
> relatively common. But as you choose the block size when you create
> the file system there are no set block size. (I'm mainly thinking of
> ext2 here, but other ones should be similar.) Then I wouldn't be
> surprised of there is a file system or two that have a variable block
> size; there're all sorts out there.
[snip]

IIRC NTFS can store small files in the "inode" (whatever its equivalent is
called).

Incidentally, which solution should I code up?

(a) Preferred by me, MartinS: Just return the cluster size as the fundamental
block size. Pros: simple. Cons: not true, if the fundamental block is
considered to be the sector.

(b) Preferred by Eli: Return the sector size as the fundamental block size.
Pros: true. Cons: involves scaling numbers in terms of clusters to in terms of
sectors; may not be able to obtain sector size in probably a small number of
cases (just use 512 instead).

(c) Preferred by Charles: Return 512 as the fundamental block size. Pros: true
in some common cases. Cons: involves scaling numbers again; not true for a
number of common cases - CDs.

Bye, Rich =]

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