Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!xlink.net!zib-berlin.de!news.tu-chemnitz.de!irz401!narcisa.sax.de!not-for-mail
From: j@narcisa.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Floppy-based tape drive questions.
Date: 6 Jun 1995 13:19:20 +0200
Organization: Private U**x site, Dresden.
Lines: 70
Message-ID: <3r1djo$ggn@bonnie.tcd-dresden.de>
References: <kientzleD97Cru.3nw@netcom.com> <3qhckj$hpf@bonnie.tcd-dresden.de> <3qsqba$4hd@usenet.ucs.indiana.edu>
Reply-To: joerg_wunsch@uriah.heep.sax.de
NNTP-Posting-Host: 192.109.108.139
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Raymond L. Gilbert <pi@bridge.bloomington.in.us> wrote:
> Wow. Sounds great. OK you sold me! I would love to use dump
>for my regular system backups. The question then becomes, how do I go
>about doing this from a floppy-interface drive?
Hmm, pity, i forgot you intented to use it with a floppy-tape drive.
If i would have thought of it in the first place, i wouldn't have
recommended you dump. :-)
Since -- as you've also noticed -- you have to pipe everything through
/sbin/ft, your only chance is
dump 0uBf 120000 - /usr | /sbin/ft "backupname"
(i guess). I doubt it would easily handle multiple volumes though.
>% echo test > /dev/ft0
>
>(or rft0, etc) produce a page fault and reboots my system. [...]
>Is this a "feature" in the ft driver to only let /sbin/ft communicate
>with /dev/[r]ft*, or is it a bug that's fixed in 2.0.5?
The page fault is a bug, the requirement to pipe everything through ft
is a feature. (If you want to fix the bug, try moving the line just
above the #if NFT > 0 within fdstrategy() [sys/i386/isa/fd.c] below
the #if block, and tell me if this fixes it. We are about to fix it
for 2.0.5, but i don't own a floppy tape drive.)
The requirement for /sbin/ft is caused by the software postprocessing
as i've described it in my previous posting. Since the floppy tape
drives are rather ``dumb'', a lot of pre-/postprocessing has to be
done (which is done in hardware for SCSI drives). The author(s) of
the driver decided to put only the really necessary parts into the
kernel to talk to the tape (and it's still an impressing amount of
code), but leave the higher-level work up to a user mode program. One
of them (i forgot who) once told me that strategy()-based floppy tape
i/o is still in consideration, but apparently they are rather tight in
time, and there are not many developers who understand all the guts
and nits of those f**ing floppy tape drives. (Most serious developers
do already own SCSI tape drives, and hence concentrate on other
problems.)
> Also, dump seems geared only to whole filesystems.
Yes, dump bypasses the file system access services of the kernel, hence
it can also work on unmounted file systems. This makes it clear why
it's always operating on a whole file system.
Perhaps you can fake a level 0 dump been done in the past (covering
all the pre-installed files, so they will be out of consideration for
the incremental dumps) by manually editing /etc/dumpdates.
Incremental dumps would then only back up your user files.
> Is dump (or Amanda which won't work if dump doesn't) really
>the answer to my floppy-tape woes? Or should I concentrate my time on
>writing my own incremental tar scripts?
As for the ``whole file system'' vs. ``sub tree only'', i would vote
for tar. I remember a rumour that GNU tar can also handle a two-level
backup scenario, but i dunno. Anyway, the requirement to pipe
everything through /sbin/ft remains also for tar.
--
cheers, J"org private: joerg_wunsch@uriah.heep.sax.de
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)