Date: Tue, 26 Feb 2008 18:51:02 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: freebsd-hackers@freebsd.org Subject: Re: emulate an end-of-media Message-ID: <20080226075102.GE83599@server.vk2pj.dyndns.org> In-Reply-To: <20080225154455.4822e72a@bhuda.mired.org> References: <op.t63j2veq724k7f@martin> <20080225154455.4822e72a@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2008 at 03:44:55PM -0500, Mike Meyer wrote: >On Mon, 25 Feb 2008 21:19:33 +0100 "Martin Laabs" <martin.laabs@mailbox.tu= -dresden.de> wrote: >> My solution can just close the pipe at the one "end" of the magic >> device which would be realy simple to implement in a script. > >While you're proposing a magic device that catches sigpipe, and >delivers an EOM to make dump -a happy. I'm proposing that dump catch >the sigpipe, and treat it like an EOM if it has -a. This may be >non-workable, in that you have to be able to tell if it was the -P >process or a slave process that generated the sigpipe, but I think >it's the best solution. 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. In the former case, then dump doesn't need to see the physical volume changes. The downside is that a partial restore would be painful as would a media error partway through the dump. 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). This isn't a problem for physical tapes (which report a logical EOM somewhat prior to the physical EOM and will allow writing beyond the logical EOM). 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. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHw8Tm/opHv/APuIcRApYtAJ9ZiqUWBsol5FnKtUEBlyCLTMg+mACgrRtm SQJVZkeQ96ldRMQHOKXtE5Y= =8go8 -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080226075102.GE83599>