From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] venti arena From: "Russ Cox" In-Reply-To: <434D1620-4B40-11D7-BF2B-000393A941BC@ar.aichi-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 1 Mar 2003 12:05:04 -0500 Topicbox-Message-UUID: 7683410a-eacb-11e9-9e20-41e7f4b1d025 I've never understood all the inconsistencies you just pointed out, so I dug around for a little while. The numbers given by fmtarenas are the real ones. The index uses ``virtual'' addresses which get mapped into (arena-name, offset) pairs. The base for the virtual addresses is 1M. If you had multiple arena partitions you'd see that the index entries for the arenas in that disk start where the previous disk left off. These virtual addresses are the numbers that fmtindex prints. I think checkarenas is just buggy. There are head and tail blocks around each arena's data section, and checkarenas is printing [datastart, datastart+datasize+2*blocksize) instead of [datastart-blocksize, datastart+datasize+blocksize) That is, checkarenas thinks datastart has the blocksize subtracted from it already, but that's not the case. The http://server/index listing uses the same code, and is thus similarly off. This is why the backup script I posted subtracts one block size before using the offset in the listing. (Though that was just trial and error on my part at the time.) Russ