Date: Mon, 31 Aug 1998 15:03:27 +0000 From: Mike Smith <mike@smith.net.au> To: zhihuizhang <bf20761@binghamton.edu> Cc: Mike Smith <mike@smith.net.au>, hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: FFS questions Message-ID: <199808311503.PAA01368@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 31 Aug 1998 17:36:41 -0400." <Pine.SOL.L3.93.980831170245.18248A-100000@bingsun2>
next in thread | previous in thread | raw e-mail | index | archive | help
Again, bear in mind that the techniques we're discussing here are deprecated, that is, they are no longer useful and we do our best to avoid using them whenever possible. > > > The comment says it is the number of cylinders per *cycle* in position > > > table. What does the "cycle" mean? > > > > It's the size of the rotational offset table. Starting from position 0 > > on the disk, there are N cycles of fastest-next-block locations as you > > move across the disk. You only need to store one cycle in the offset > > table. > > >From your explanation, it seems that the table is for entire disk (not > constrained to one cylinder) and according to comment in mkfs.c, each > cycle is a rotational pattern. So I guess that each pattern covers fs_cpc > cylinders, or after fs_cpc cylinders the pattern will repeat (on the next > cylinder boundary or immediately?) The pattern repeats every fs_cpc cylinders, which is why you only store that much of it. The pattern always covers a whole number of cylinders, so the repeat is always on a cylinder boundary. > So how is the pattern represented anyway? Is there any relationship > between fs_cpc and fs_nrpos (should be number of rotational positions *per > cylinder*). I guess that in a pattern (cycle), there are fs_cpc * > fs_nrpos different positions. How are these positions represented, by > block numbers or by increments? Each entry in the pattern gives an offset to the next optimally located rotational position, ie. allowing for head/track switch delays, skipping over spares at the end of the track/cylinder, etc. > The macro cbtorpos() converts a block number to a rotational position in a > single cylinder. This position is used to index position table to get > another block number. This block number is in turn used to index the > rotational table to get an increase of it. After increase, the block > number is used again to index the positional table until a free file block > is found.... The use of fs_postbl() and fs_rotbl() seems to construct a > list of blocks available at each rotational position. But they confuses > me. If you have allocated a block, and wish to allocate another to follow it, the ideal case is to find a block that can be read as quickly as possible. This block will be located somewhere after the block that you have just allocated; it may be on the same track, on another track on the same cylinder, or on another cylinder. In each case, you need to consider different factors when calculating this block. The position table contains a precalculated set of block offsets, rather than repeating the calculations each time. When trying to understand why these calculations were necessary, understand that the disk drives being used when this code was developed had no "intelligence" as such; all optimisations for disk behaviour had to be embedded into the filesystem. It is difficult to explain the justification for these optimisations without a lengthy explanation of: - sector interleave - track interleave - command overhead - head switch time - track-to-track time and a number of other subtle factors which modify these and related parameters. Modern disks do not behave like these old disks, which is why we disable these old "optimisations" where possible. > I hope someone can clarify for me on how those blocks for one rotational > position are organized. Blocks in each rotational position are logically contiguous. By default, there were 8 rotational positions on the disk, so for a disk with 32 sectors per track, there would be 4 blocks in each rotational position, 0-3 in #0, 4-7 in #1, etc. These sectors might not be arranged contigously on the disk however. > Any help is appreciated. In studying this code, it's important to remember what I've tried to point out above; it was designed to optimise performance on old hardware, and only worked well if *all* parameters were correct. Modern disk hardware attempts to second-guess the operating system, and usually does a better job. We improve performance by allocating contigous space on the disk wherever possible (no interleave, only one rotational position); this takes advantage of the read-ahead/write behind performed by most modern disks rather than wasting space in the disk cache with intervening blocks that we will not use. -- \\ 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?199808311503.PAA01368>