From owner-freebsd-hackers Tue Sep 8 13:27:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06971 for freebsd-hackers-outgoing; Tue, 8 Sep 1998 13:27:56 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06960 for ; Tue, 8 Sep 1998 13:27:55 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA00560; Tue, 8 Sep 1998 13:33:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199809082033.NAA00560@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: zhihuizhang cc: hackers Subject: Re: ffs_blkpref() and cluster_save In-reply-to: Your message of "Tue, 08 Sep 1998 15:15:07 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Sep 1998 13:33:43 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On Tue, 8 Sep 1998, Mike Smith wrote: > > > indx refers to the offset of the allocation within the file section. > > > > bap[] is the table of block addresses within the section. It's used to > > locate the previous block in the file in order to make a contiguous > > allocation. > > I am still confused with this small routine: > > (1) If bap[indx-1]==0 means the previous logical block has not been > allocated, does this imply that the file has holes? In this case, we can > not make use of information of previous allocation. Since this also > implies that we are NOT making contiguous allocation, it is OK to guess > by logical block number. Yes, it means that the file has a hole. > (2) bap is actually given as ip->i_db[0] or the last metablock on the path > used to access the data block (see ufs_getlbns()) and indx is the offset > into bap corresponding to the given logical block number. Its value should > be 0..11 or 0..1023. If so, indx has nothing to do with fs_maxbpg. I > mean indx % fs->fs_maxbpg is the same thing as indx == 0. The default > value of maxbpg is 1024 though. I'm not quite sure why the (indx % fs_maxbpg) calculation is there, unless it's intended to short-circuit the case where the allocation should unconditionally move to the next cg.a > (3) Why we always return the same value fs_fpg*cg + fs_frag for ALL direct > blocks (lbn < NDADDR)? Besides, the first fragment address of a chosen > cylinder group cg should be fs_fpg * cg, not fs_fpg*cg + fs_frag. Sorry, I have no idea on this one. Perhaps ask Terry (terry@freebsd.org) and/or Kirk (mckusick@mckusick.com). > By the way, I still can not find where the structure *cluster_save* is > defined (I check all the included head files). I hope someone can tell me > where it is. It doesn't exist. The code referring to it is #ifdef'ed out, although references to pointers to 'struct cluster_save' do exist. -- \\ 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