From owner-freebsd-hackers Sat Jul 6 17:52:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FCC937B400 for ; Sat, 6 Jul 2002 17:52:26 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 3420B43E09 for ; Sat, 6 Jul 2002 17:52:25 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Jul 2002 01:50:16 +0100 (BST) To: ticso@cicely.de Cc: Matthew Dillon , Bernd Walter , Terry Lambert , Darren Pilgrim , freebsd-hackers@FreeBSD.ORG Subject: Re: How does swap work address spacewise? In-Reply-To: Your message of "Sun, 07 Jul 2002 02:10:19 +0200." <20020707001019.GK23704@cicely5.cicely.de> Date: Sun, 07 Jul 2002 01:50:07 +0100 From: Ian Dowse Message-ID: <200207070150.aa91552@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020707001019.GK23704@cicely5.cicely.de>, Bernd Walter writes: >I never saw any negative block numbers in on-disc structures. >Now I wonder if it was just hidden behind macros. >What is the reason to handle it that way? >Do you have some code reference for homework? These logical block numbers are not stored on disk; they are just used by the filesystem code to refer to block numbers within a file relative to the start of the file. The on-disk format uses direct and indirect block pointers to refer to the actual filesystem blocks, and it is easy to get from a lbn to the sequence of indirection blocks necessary to find the on-disk data. See ufs_getlbns() in sys/ufs/ufs/ufs_bmap.c for details. >> These are logical block numbers, which are fragment-sized (1K typically) (lbns are actually in block-sized, not fragment-sized units, since a single file block is always contiguous on the disk even if it does not begin on a disk block boundary or is not a full block in size. Physical UFS block numbers (ufs_daddr_t in the code) are in fragment-sized units.) >> Physical block numbers are 512-byte sized, with a range of 2^32 >> in -stable. This also winds up being 2TB. So increasing the fragment >> size does not help in -stable. >It's a proven fact that there is a 1T limit somewhere which was >explained with physical block numbers beeing signed. Yes, the daddr_t type is signed, so the real limit for filesystems is 1TB I think. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message