Date: Sat, 29 Aug 1998 15:45:02 +0000 From: Mike Smith <mike@smith.net.au> To: zhihuizhang <bf20761@binghamton.edu> Cc: hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Macro cbtorpos() in fs.h Message-ID: <199808291545.PAA08998@word.smith.net.au> In-Reply-To: Your message of "Sat, 29 Aug 1998 15:06:39 -0400." <Pine.SOL.L3.93.980829145113.18319A-100000@bingsun2>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I am trying to understand the macro cbtorpos() defined below: > > #define cbtorpos(fs, bno) \ > (((bno) * NSPF(fs) % (fs)->fs_spc / (fs)->fs_nsect * (fs)->fs_trackskew + \ > (bno) * NSPF(fs) % (fs)->fs_spc % (fs)->fs_nsect * (fs)->fs_interleave) % \ > (fs)->fs_nsect * (fs)->fs_nrpos / (fs)->fs_npsect) > > > First I assume that the hard disk sectors are numbered from one cylinder > to another, moving from top track to the bottom track before moving to the > next cylinder. (This is the vertical mapping as described at the site > http:/www.tomshardware.com/hdd.html). Otherwise, the macro might not make > any sense. Yes. Logically block numbers are ordered in ascending order by track, head, cylinder. However it's worth considering, before you get too involved here, that most disks these days don't have the geometry that inspired these calculations, and when building filesystems we deliberately attempt to defeat these caclulations. > So bno * NSPF % fs_spc / fs_nsect will give us the track number and bno * > NSPF % fs_spc % fs_nsect will give us the sector count within that track. > However, the rest part of the macro is confusing to me. If I understand it correctly, the macro calculates the rotational position of the block number (bno) in the filesystem (fs). This is used for two things in ffs_alloc.c - When allocating a block, in the code which attempts to find the optimal block based on the filesystem's idea of the disk geometry. We defeat this code by setting fs_nrpos to 1 when building filesystems. - When accounting for block usage, it's used to generate an offset into the free block table for a given cylinder. Because we defeat much of the calculation with our filsystem layout, particularly by only distinguishing one rotational position per cylinder, I suspect that for FreeBSD filesystems the macro will normally return 0 (it might be a small optimisation to detect this case and avoid the calculations involved therin). In particular; fs_nsect will normally be == fs_npsect, and fs_rpos will be 1, so the entire macro reduces to (X) % ((z * 1) / z). You can see the fs_nsect and fs_npsect calculations in the newfs source, where fs_nsect is set from nsectors and fs_npsect is set from nphyssectors, and nphyssectors = nsectors + trackspares where trackspares is normally set to 0. For filesystems from other operating systems (eg. NetBSD), who don't optimise their filesystem layout for modern hardware, it will return an appropriate offset to suit the layout. Similarly if the optimised defaults used by FreeBSD's newfs are overridden when the filesystem is being generated. > I assume that fs_nsect + unused sectors = fs_npsect That would appear to be valid from the above. > and the C operators %, /, and * all > have same precedence. You can check /usr/share/misc/operator for that one. The policy implemented in ffs_alloc.c is discussed in "The Design and Implementation of the 4.4BSD Operating System", McKusic, Bostic, Karels and Quarterman, ISBN 0-201-54979-4 in section 8.2, subheading "Allocation Mechanisms" starting on page 277. Rotational positions are discussed on page 280. Our local policy changes are documented mostly in the CVS repository, and many are summarised in src/sbin/newfs/newfs.c. I hope this is at least a little helpful. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199808291545.PAA08998>