From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 26 18:45:09 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7705B1065671 for ; Tue, 26 Feb 2008 18:45:09 +0000 (UTC) (envelope-from martin.laabs@mailbox.tu-dresden.de) Received: from mailout2.zih.tu-dresden.de (mailout2.zih.tu-dresden.de [141.30.67.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB2813C457 for ; Tue, 26 Feb 2008 18:45:09 +0000 (UTC) (envelope-from martin.laabs@mailbox.tu-dresden.de) Received: from rmc67-31.zih.tu-dresden.de ([141.30.67.31] helo=server-n) by mailout2.zih.tu-dresden.de with esmtp (Exim 4.63) (envelope-from ) id 1JU4nY-0006bE-5C for freebsd-hackers@freebsd.org; Tue, 26 Feb 2008 19:45:08 +0100 Received: from martin (p5B0ED270.dip.t-dialin.net [91.14.210.112]) by server-n (Postfix) with ESMTP id EAB56100A092 for ; Tue, 26 Feb 2008 19:45:03 +0100 (CET) To: "freebsd-hackers@freebsd.org" From: "Martin Laabs" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <20080226075102.GE83599@server.vk2pj.dyndns.org> References: <20080225154455.4822e72a@bhuda.mired.org> <20080226075102.GE83599@server.vk2pj.dyndns.org> Content-Transfer-Encoding: 7bit Date: Tue, 26 Feb 2008 19:45:03 +0100 Message-ID: User-Agent: Opera Mail/9.25 (Linux) X-TUD-Virus-Scanned: mailout2.zih.tu-dresden.de Subject: Re: emulate an end-of-media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 18:45:09 -0000 Hi, > I'm not sure wheher Martin is trying to create a dump that is a single > logical volume split over multiple physical volumes or a multi-volume > dump. I want to make a real multi-volume dump over multiple media. Because if I had only one big volume I'd - in the worst case - have to insert all media also if i want to recover only one file. And worser: I'd had to read and decompress all media up to the end. I could of cause use another backup backend but I think dump is one of the best and reliablest backup mechanism. (Because it works on inode-basis and not the user file-system level.) > I suspect Martin is trying for the latter case - which has a number of > advantages (like partial restores are much faster and a failed write > can be retried on new media). But it also has some gotchas. The > biggest one is that dump needs to be able to write past EOM (so it can > record an end-of-volume block). Oh - that are bad news. Do you know how many blocks/bytes dump needs afterwards? > [...] But it does mean that > your magic device needs to be able to return EOM to dump early enough > that dump can record end-of-volume and the compressor can dump that > block and any trailing state before it runs out of media. And it makes the idea to convert a sigpipe to an EOM useless. I've to think about that. (I thought I could just change dump in that way that it handle a sigpipe like an EOM which would be very easy.) Maybe I now have to implement the output byte counting of the script or pipe specified by -P when -B was given. Thak you, Martin L.