In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
