From owner-freebsd-hackers Sat Apr 1 18:59:43 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA20220 for hackers-outgoing; Sat, 1 Apr 1995 18:59:43 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA20212 for ; Sat, 1 Apr 1995 18:59:40 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id SAA20722; Sat, 1 Apr 1995 18:57:26 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id SAA00332; Sat, 1 Apr 1995 18:57:25 -0800 Message-Id: <199504020257.SAA00332@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: terry@cs.weber.edu cc: hackers@FreeBSD.org, Bruce Evans Subject: Re: 4 gig st15150n disk setups In-reply-to: Your message of "Sun, 02 Apr 95 08:35:46 +1000." <199504012235.IAA21888@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 01 Apr 1995 18:57:20 -0800 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. I'm not sure if I see the distinction you're trying to make. The problem is that there are places in the kernel that convert from a block offset to a 32 bit byte offset (and back again in some cases). This isn't intentional - it's simply a matter of the wrong type being used in some cases. The obvious result is a loss of precision. The end result is usually sign extension from the 32bit signed type to the 64bit signed type and thus leads to negative block offsets. In 4.4BSD, negative block offsets refer to file indirect blocks (the indirect blocks are cached in buffers using negative block offsets and are attached to the file vnode in the same way that regular file data is). I don't like caching things this way, but nonetheless, that's the way it is. -DG