From owner-freebsd-stable Mon Jul 27 10:26:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25101 for freebsd-stable-outgoing; Mon, 27 Jul 1998 10:26:59 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from admin.dircon.net (philip@admin.dircon.net [194.112.33.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25093 for ; Mon, 27 Jul 1998 10:26:53 -0700 (PDT) (envelope-from philip@admin.dircon.net) Received: (from philip@localhost) by admin.dircon.net (8.8.5/8.8.7) id SAA22760; Mon, 27 Jul 1998 18:26:09 +0100 (BST) Date: Mon, 27 Jul 1998 18:26:08 +0100 (BST) From: Philip Inglesant To: freebsd-stable@FreeBSD.ORG Subject: dump/restore and large filesystem problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This problem was reported by tom@uniserve.com in April, but i haven't seen any convincing answer to it, and it is still a problem for us. I have this exact problem with a large (16GB) file system. It is nothing to do with sparse files, back tapes, networks, or anything else like that. I can dump and pipe it into a restore, and the "hole in dump" happens right away. I did some hacking in the source, and it seems that the "maps" dumped at the start of the tape can exceed TP_NINDIR (which is half a basic tape block, or 512) blocks. The significance of this is that the c_addr table, which has a non-zero value for each block in the ext part of the dump, fits in 512 bytes (look in /usr/include/protocols/dumprestore.h), and the whole header fits in a basic 1kb block. For debugging, I got restore to fprintf the value of c_count, which is the size of the next part of the dump, for which the c_addr table has to have a value for each block. On the type TS_CLRI map (that's map of inodes deleted), on this particular 16Gb file system, it showed a value of 1019. Obviously, on other file systems it would be some other value, but there's no reason at all to assume it will always be < 512. I have a hacked version of dump that puts the two initial maps (cleared inodes and the file dump list) onto tape in much the same way as the actual files - a header guaranteed to be < 1 basic tape block, followed by 512 or fewer blocks of dump, followed by another header and so on as necessary, and a hacked version of restore to read dumps done this way. It seems to work but i haven't really tested it well. Maybe someone with more knowledge of BSD dump/restore would like to comment. Philip Inglesant Direct Connection To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message