Path: katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Message-ID: Date: 12 Apr 1994 10:00:21 GMT Organization: Software Research Associates, Inc.,Japan In-reply-to: t-yosida@ccs.mt.nec.co.jp's message of 12 May 93 11:58:30 GMT Newsgroups: fj.sys.sun Subject: Re: Exabyte for sun Distribution: fj References: あまりの follow の遅さが議論の妨げになっていたらごめんなさい。 記事 で t-yosida@ccs.mt.nec.co.jp (Tadashi Yoshida) さんいはく > 今 Sun3/260 SunOS 4.1.1 + Exabyte 8200 + 別売りSCSI > 今 Sun4/370 SunOS 4.1 + Exabyte 8500 > > で使用しています。 > これらの装置を利用して私のところでは、ホームおよびプロジェクトのdai > lyおよび長期休暇前のバックアップに利用しているのですが、dumpのオプシ > ョンを何にするのがもっとも効率的なのかがわかりません。現在は昔のまま > の値を使って、 > > dump 0udsf 10000 20000 /dev/XXX YYY > > のようにしていますが、この 10000 20000 がマジックNoになっています。 > 8200/8500(圧縮/非圧縮)等で、これらの値は計算して求められるのでしょう > か？ 　d や s は、どうせテーブの長さの計算にしか使わないので、あまり神経質 にならなくていいのじゃないでしょうか。実際、厳密な計算はしないで使って いる人が多いはず（後で引用する記事でもわかるように、IRG の値まで知って ないと計算ができないが、そんなの普通の人はどうやって知るのでしょう？） ですが、問題になったという話は聞きません。 　一応 SUN OS の dump(8) では、8200（非圧縮）の場合 ds 54000 6000 が推 奨されていますね。 　不思議なことに、この SUN OS の値が一人歩きして、他の OS でも "ds 54000 6000" を使っているケースがしばしば見られます。SUN や NEWS で dump したファイルは、（ とか dump(5) の記述が SUN や NEWS では若干違うのにもかかわらず）SUN と NEWS で相互に restore できます。こうした互換性から、dump とrestore のコマンドパラメータの与 えかたまで同じであるという誤解があるようです。例えば NEWS-OS の「アド ミニストレイターズガイド」では全く別な値が推奨されています。そもそも b option でブロックサイズを変えていながら、d や s を調整する必要があるこ とは意識されない場合が多いようです。（もちろん知っていても敢えて放って ある場合も多い。） 　実例をひとつ出してみましょう。中に含むファイルやディレクトリが同一で あるようなファイルシステムを Sun と NEWS-OS 上に準備して両者のdump が テープ量をどう見積もるのか見くらべてみます。 ext221# cat /etc/motd SunOS Release 4.1.1-JLE1.1.1 (SPARC75) #2: Thu Aug 8 18:11:36 JST 1991 ext221# df /dev/sd0a Filesystem kbytes used avail capacity Mounted on /dev/sd0a 7573 5929 886 87% / ext221# dump 0fbds /dev/null 126 54000 60 /dev/sd0a . . . . . DUMP: estimated 13534 blocks (6.61MB) on 0.35 tape(s). sran229# cat /etc/motd NEWS-OS Release 4.2C #0: Tue Jul 21 14:13:30 JST 1992 sran229# df /dev/sd01f Filesystem kbytes used avail capacity Mounted on /dev/sd01f 7453 5929 778 88% /mnt sran229# dump 0fbds /dev/null 63 54000 60 /dev/sd01f . . . . . DUMP: estimated 6710 tape blocks on 0.28 tape(s). 注：63 tape blocks on NEWS == 126 tape blocks on SUN (cf. SUN と NEWS の restore(8)) というように、かなり違ってますよね。 　c option などを使うと違いすぎてめちゃめちゃになります。（SONY の dump(8) には c option が載っていませんが、cartiridge に dump する際に は c option を必ずつけるべきだという記事が fj に投稿されたこともありま す(ちなみに SONY に所属の方の投稿でした)から、その主張の正否はともかく、 少なくとも c option は minor な option ではないとみていいですよね？） 　Chris Torek さんも、必要なテープ量の見積り方は dump の実装によって異 なるという記事を書いていました。なんでも、ブロック間ギャップの値が #ifdef sun で分けられているとか。参考になると思うので、この記事の最後 に引用しておきますが、ご愛敬で計算間違いが入っていることに注意して読ん でください。 　というわけで、非常に厳密な話をすると 「d,s などはマニュアル推奨の値を使わねばならず、これは各機種で異なる」 と思えます。もっとも、そんなこと気にしていたら、b option も使えないこと になってしまうし、テープの容量の見積りが多少ちがってても読み書きできな くなるわけでもなんでもないので、気にすることはないと思います。 -- 渡邊克宏＠ＳＲＡ From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.admin Subject: Re: How does dump do it? Message-ID: <17057@dog.ee.lbl.gov> Date: 29 Aug 91 23:59:12 GMT References: <1991Aug29.195209.25349@bwdls61.bnr.ca> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 175 X-Local-Date: Thu, 29 Aug 91 16:59:12 PDT >In article <1991Aug29.195209.25349@bwdls61.bnr.ca> pww@bnr.ca (Peter Whittaker) writes: >>According to the SunOS 4.1.1 manpage for dump and various other bits >>of relevant literature, the default parameters for dump with an 8mm >>tape (i.e. EXB-8200) are bpi=54000 and size=6000 ft. Doing the math >>(such as it is) gives: >> >>54000 bits/inch * 12 inch/ft * 6000 ft * 1byte/8bits ‾= 486MB. In article poulson@cs.widener.edu (Joshua Poulson) writes: >Let's modify your formula somewhat. Since many tape drives record data >on tracks on the tape, they actually are storing 54000 bytes per inch. >Our nine-track mag tape units do this, and I think that the Exabytes do >the same kind of thing. Well, no. A nine track drive does in fact store $k$ bytes per inch when running at $k$ bits per inch, because it stores eight data bits plus a ninth parity bit (hence `nine track drive'). Exabytes are different. Both of you are making the assumption that dump knows what you are talking about. (in your best Sgt. Schultz voice from `Hogan's Heroes':) Dump knows nothink! Nothink! Seriously: The problem is that, as Joshua Poulson notes, dump thinks that everything is a nine track tape. It does not know or care that an Exabyte tape is completely different. >So we have: > 54000 bytes per inch * 12 inches per foot * 6000 feet of tape > = 3.888 x 10^9 bytes = 3.797 x 10^6 Kb = 3.708 x 10^3 Mb = 3.621 Gb > >This 3.6 Gb is the theoretical maximum amount of data you could store on >a perfect tape with this density and 6000 foot-long blocks. > >To get a realistic answer, you must calculate using a realistic block >size. When a block is written to tape, it is followed by a 0.5 inch gap >which helps the software and hardware synchronize with the tape. Of course, it is not ... but dump *thinks* it is. This is the key point. Dump believes it is talking to a nine track tape. It is going to calculate how much space there is on that nine track tape. It thinks such tapes have block sizes (Exabytes do in one mode, but use fixed 1024-byte blocks in the usual mode) and have gaps (Exabytes do not), so you must LIE to dump to make it work. >On mag tapes we use block sizes up to 32Kb, but the block size used by >default is 54000 bytes. This means that the Exabyte drives are more >reliable with blocks this size... or that tapes have less errors... or >that the density is really working out well for us. :) (This makes no sense at all.) Versions of dump later than about 1986, including that shipped with SunOS now that it is 1991, raise their nine track block size from 10240 bytes to 32768 bytes whenever the density is >= 6250 bpi. This of course has no effect on the Exabyte in its usual 1024-byte block mode ... but dump *thinks* it does. In addition, dump thinks that there is between each blcok, not a 0.5 inch gap, but rather a 0.8 inch gap---except when running at exactly 6250 `d', when there is a 0.5 inch gap. But wait, there is more. If the preprocessor symbol `sun' is defined, this changes to a .6 inch gap at 6250 and a 1.2 inch gap at other densities. The code literally reads: #ifdef sun /* sun has long irg's */ tenthsperirg = (density == 625) ? 6 : 12; #else tenthsperirg = (density == 625) ? 5 : 8; #endif (dump works internally in 0.1-inch units). Now how little would you pay? But wait! All of this is only if the `cartridge' flag is not set. If cartridge is set, dump assumes 1.6 inch gaps, with smaller gaps between the (presumably streamed) blocks on the Archive tape controller! If you thought it could not get worse.... Well, ignore the cartridge and maybe it will go away. Now that we have three utterly irrelevant factors, we calculate the number of tapes we think we will need as blocks | bytes | inches blocks | IRG | inches --------+-------+-------- + --------+-------+-------- | block | byte | block | IRG (where `blocks' is in terms of TP_BSIZE, which happens to be 1024). This is the total number of inches we will need. Thus, with dump sd 6000 54000 we can reverse these calculations and fill in (knowing 6000 ft = 72000 in): X blks | 32768 B | 1 in X blks | 1 IRG | 0.8 in --------+-----------+---------- + --------+---------+--------- = 72000 in | 1 blk | 54000 B | 32 blks | 1 IRG then solve for X: 32768 X 0.8 X --------- + ------- = 72000 54000 32 (1048576 + 43200) X --------------------- = 72000 1728000 1091776 X = 72000 * 1728000 X ‾= 113957.4 or that many 1024-byte blocks, or 113,957 kbytes, or 111 MB, which means I have made some error above (the number is unreasonably small, but I have been up for over 23 hours straight). >From our number above we have 54000 bytes per inch which gives us a one >inch data portion for our block. Add the 0.5 inch gap and we have 1.5 >inches per block. > >Let's figure out how many blocks we have: > 6000 feet of tape * 12 inches per foot / 1.5 inches per block > = 48000 blocks on the tape This will not work out properly because, while we do compute with 54000 bytes per inch, we only have one inter-record gap, of 0.8 inch, for every 32 1024-byte blocks, or 0.606 inch; so we get 32k per 1.4 inches, or 6000 ft * 12 (in/ft) / 1.4 (in/32k) = 51428 32k-blocks or 1645696 kB or 1607 MB or 1.56 GB (which seems a *bit* more reasonable). >Now, we can find the capacity for our tape: > 54000 bytes per block * 48000 blocks per tape > = 2.592 x 10^9 bytes = 2.53 x 10^6 Kb = 2.472 x 10^3 Mb = 2.414 Gb > >I rounded things off, but you get the picture. However, unless your dump is very different from everyone else's, this is not the right picture. I *think* my second numbers above are close. Note that I recommend dumping with `d 6250' and `s 43000', which gives one gap per 32 kB 32 kB / 6250 (B/in) = 5.242 in + 0.5 in gap ‾= 5.75 in/32k 40000 ft * 12 (in/ft) / 5.75 (in/32k) ‾= 83478 32k-blocks 83478 blocks * 32 kB/block = 2671304 kB = 2608 MB = 2.55 GB This is an overestimate, but the numbers are easy to remember. (A length of 36113 gives almost exactly 2.3 GB.) Anyway, in all of this nonsense we probably lost sight of the real point, which is that you MUST *lie* to dump to get it to do the right thing. The numbers you feed it are not important: they merely serve to make its computations work out. It would be better if you could simply tell dump `this many megabytes fit on the tape'.... Of course, as it happens, 2.3 GB exceeds the 31-bit `off_t' offset, so depending on whether your kernel allows negative offsets on tape drives, you may not be able to write this much anyway. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov new area code as of September 2, 1991: +1 510 486 5427