atom feed27 messages in org.freebsd.freebsd-hackersRe: How does swap work address spacew...
FromSent OnAttachments
Daniel LangJul 5, 2002 4:35 am 
David SchultzJul 5, 2002 6:34 am 
David SchultzJul 5, 2002 6:38 am 
Terry LambertJul 5, 2002 7:33 am 
Daniel LangJul 5, 2002 4:41 pm 
Darren PilgrimJul 5, 2002 5:57 pm 
Bernd WalterJul 5, 2002 7:06 pm 
Terry LambertJul 5, 2002 11:12 pm 
Matthew DillonJul 6, 2002 1:10 am 
Darren PilgrimJul 6, 2002 2:36 pm 
Matthew D. FullerJul 6, 2002 2:51 pm 
Bernd WalterJul 6, 2002 3:06 pm 
Darren PilgrimJul 6, 2002 3:42 pm 
Terry LambertJul 6, 2002 4:00 pm 
Bernd WalterJul 6, 2002 4:04 pm 
Bernd WalterJul 6, 2002 4:13 pm 
Matthew DillonJul 6, 2002 4:33 pm 
Matthew DillonJul 6, 2002 4:42 pm 
Bernd WalterJul 6, 2002 5:09 pm 
Matthew DillonJul 6, 2002 5:33 pm 
Bernd WalterJul 6, 2002 5:42 pm 
Matthew DillonJul 6, 2002 5:46 pm 
Ian DowseJul 6, 2002 5:49 pm 
Bernd WalterJul 6, 2002 6:21 pm 
Darren PilgrimJul 6, 2002 10:01 pm 
Matthew DillonJul 6, 2002 10:09 pm 
Darren PilgrimJul 6, 2002 10:43 pm 
Subject:Re: How does swap work address spacewise?
From:Ian Dowse (iedo@maths.tcd.ie)
Date:Jul 6, 2002 5:49:45 pm
List:org.freebsd.freebsd-hackers

In message <2002@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 majo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message