Date: Sat, 01 Apr 1995 18:57:20 -0800 From: David Greenman <davidg@Root.COM> To: terry@cs.weber.edu Cc: hackers@FreeBSD.org, Bruce Evans <bde@zeta.org.au> Subject: Re: 4 gig st15150n disk setups Message-ID: <199504020257.SAA00332@corbin.Root.COM> In-Reply-To: Your message of "Sun, 02 Apr 95 08:35:46 %2B1000." <199504012235.IAA21888@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504020257.SAA00332>