Date: Sun, 7 Jul 2002 03:21:30 +0200 From: Bernd Walter <ticso@cicely5.cicely.de> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Bernd Walter <ticso@cicely5.cicely.de>, Terry Lambert <tlambert2@mindspring.com>, Darren Pilgrim <dmp@pantherdragon.org>, ticso@cicely.de, freebsd-hackers@FreeBSD.ORG Subject: Re: How does swap work address spacewise? Message-ID: <20020707012130.GM23704@cicely5.cicely.de> In-Reply-To: <200207070033.g670XoMJ064092@apollo.backplane.com> References: <3D2640A7.3EA2236B@pantherdragon.org> <20020706020656.GL48977@cicely5.cicely.de> <3D2762FE.9D9E0378@pantherdragon.org> <20020706220720.GG23704@cicely5.cicely.de> <3D277274.B5F3CE58@pantherdragon.org> <3D2776BE.A39A1110@mindspring.com> <20020706231346.GJ23704@cicely5.cicely.de> <200207062342.g66NgMri063859@apollo.backplane.com> <20020707001019.GK23704@cicely5.cicely.de> <200207070033.g670XoMJ064092@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 06, 2002 at 05:33:50PM -0700, Matthew Dillon wrote: > > : > :On Sat, Jul 06, 2002 at 04:42:22PM -0700, Matthew Dillon wrote: > :> Negative block numbers are used by UFS to represent the indirect blocks > :> associated with a file, while positive block numbers represent the > :> contents of the file. > : > :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? > > LOGICAL block numbers, not physical block numbers. ufs on disc structures are using logical block numbers. But well I've already found what you mean. > :> These are logical block numbers, which are fragment-sized (1K typically). > :> So, 2^31 x 1K = 2TB. > :> > :> 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. > > test1# vnconfig -e -s labels -r reserve -S 2t vn0 > test1# disklabel -r -w vn0 auto > test1# disklabel vn0 > ... > bytes/sector: 4096 > ... > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 536870912 0 unused 0 0 # (Cyl. 0 - 2097151) > > Theoretically VN can create up to an 8TB virtual disk because the > sector size for a swap-backed VN device is 4K, but I'm not sure I > would want to test the theory. > > > With a regular file: > > test1# vnconfig -e -s labels -T -S 2047g vn0 test.dat > test1# disklabel -r -w vn0 auto > test1# disklabel vn0 > ... > bytes/sector: 512 > ... > c: 4292870144 0 unused 0 0 # (Cyl. 0 - 2 > > test1# ls -la test.dat > -rw---xr-- 1 root wheel 2199023255552 Jul 7 00:31 test.dat > test1# > > (of course, god help you if you tried to 'newfs' the above!) But that's the important point. You can happily create vinum 2T volumes but you can never newfs them, because daddr_t, which is used in struct buf, is signed. This case was tested using real disks. OK you can format a disk using 1k sectors. But I was told that vm internaly always adapts to 512 byte blocks using signed 32bit varables so it wouldn't help. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020707012130.GM23704>