From owner-freebsd-hackers  Sat Apr  1 14:38:36 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA03027 for hackers-outgoing; Sat, 1 Apr 1995 14:38:36 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA03013; Sat, 1 Apr 1995 14:38:30 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA21888; Sun, 2 Apr 1995 08:35:46 +1000
Date: Sun, 2 Apr 1995 08:35:46 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504012235.IAA21888@godzilla.zeta.org.au>
To: davidg@Root.COM, terry@cs.weber.edu
Subject: Re: 4 gig st15150n disk setups
Cc: bde@zeta.org.au, bugs@ns1.win.net, gary@palmer.demon.co.uk,
        hackers@FreeBSD.org, jkh@freefall.cdrom.com, tom@haven.uniserve.com
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>>    Just to clarify what Bruce is saying: If someone were to create a file that
>> was >2GB, BAD things would happen. The system currently considers any blocks
>> >2GB and <4GB as file metadata (for containing indirect blocks). Not only
>> would this certainly cause the machine to panic, it would almost certainly
>> cause random filesystem corruption.
>>    I'll try to fix as many of these potential problems as possible before the
>> release.

>I was under the impression that these were atomic block offsets -- NOT
>byte offsets.

David might have it slightly wrong above.  I'm not familiar with the code
that handles negative (block?) numbers in metadata.

The clustering code converts block numbers to byte offsets for some reason,
perhaps just because it wants to compare the byte offset with the file
size and multiplying by the block size is sometimes much more efficient
than dividing the file size by the block size and worrying about rounding.

The multiplications are done as `blkno * size' where `blkno' is usually
of type daddr_t and `size' is usually of type long.  They should be done
as `(off_t)blkno * size'.  This is probably easy to fix - there don't
seem to be many secondary problems.  I gave up on the problem for a
while because it seemed that there were more fundamental problems in
the vm system.

Bruce