petitp@cui.UUCP (PETITPIERRE Dominique) (07/12/88)
First here is an answer to <655@rphroy.UUCP> Contest: dump(8) parameters for DC300XL 1/4" cartridge tape : My dump favorite parameters for a 600ft cartridge (I don't use 'c') dump 0udsbf 1000 5100 1000 /dev/nrst8 ... the b option is there only in order to stream the tape as much as possible and depends on the memory available. With these parameters around 60 Megabytes can be stored on a tape. The 'nrst8' device is used so that the tape is left positioned at the end of the dump, and another dump can be stored on the same tape, with (the 's' parameter reduded appropriately). Apart of that wouldn't it be a good time to have a general discussion about 'is dump really dumb?': - Why doesn't 'restore -t' give you the name of the file system stored on the tape? - Why isn't it possible to specify many file system to be stored on the same tape (cartridge). You can do it by hand (see 'nrst8' above) but except for the first file system, dump will think that the space left on the tape is in fact the size of a full tape, and will not use properly the space on the second tape (impossible to dump two fs of 30MB on two 40MB cartridges) - Is it true that restored files will have their modification time always set to the time of the restore command? (no 'p' option like for tar). Thats what happend to me with a level 0 dump. - Why isn't it possible to specify the size of the tape in (mega) bytes rather than this cumbersome combination of density, length and mysterious 'c' option? At least for streamer tape cartridges that we use, there is no indication of their density in bits per inches. In fact why doesn't dump use all the space available on the tape without being told how much on the command line? - Why can't dump work on active file systems? At least for incremental dumps that would be quite useful to run dump in multi-user mode! - Why is dump always interactive? Especially because you have to wait till every user logs out, it would be nice to have dump run at night, unattended, and properly coping with tape errors, as a big boy (and mail to 'root' the results). You can see I have a lot of anger against dump. But I cannot understand so many flaws in such a crucial and often used program. Maybe it is because I don't know how to use it (and then I would be glad to hear about the proper way to do things), or maybe other people share my views and have abandonned dump to use something better I'd like to use too! Dominique -- Mr. Dominique Petitpierre |EAN, BITNET, EARN, MHS, X.400: petitp@cui.unige.ch ISSCO, University of Geneva |UUCP: mcvax!cernvax!cui!petitp , petitp@cui.uucp 54 route des Acacias |JANET: petitp%cui.unige.ch@ean-relay.ac.uk CH-1227 GENEVA (Switzerland)|CSNET, ARPA: petitp%cui.unige.ch@csnet-relay.csnet Tel: 0041/22/20 93 33 extension 2117
karish@denali.stanford.edu (Chuck Karish) (07/16/88)
In article <170@cui.UUCP> petitp@cui.UUCP (PETITPIERRE Dominique) writes: > - Why doesn't 'restore -t' give you the name of the file system stored > on the tape? dump stores only the contents of the partition, not any external information like the name by which the operating system knows the disk device. This is in accordance with the minimalist UNIX traditions. I agree that it's frustrating that the paper label on the tape is so important. Besides, what is the true name of a file system? A block special device may have more than one link (name) in the root file system. > - Why isn't it possible to specify many file system to be stored > on the same tape (cartridge). What happens when you want to re-use the first part of the tape, and the file system you want to dump has grown? You're not able to use the tape efficiently unless you dump both file systems again. If you take seriously the purpose of dump, which is to provide security of your users' data, you may appreciate that it's better to put backups on separate tapes, so that failure of a single tape does not destroy two backups. > - Is it true that restored files will have their modification time > always set to the time of the restore command? (no 'p' option like > for tar). Thats what happend to me with a level 0 dump. I just tried a restore -i, logged in to an Ultrix system as root. The correct dates were restored. > - Why isn't it possible to specify the size of the tape in (mega) bytes > rather than this cumbersome combination of density, length and > mysterious 'c' option? dump was written with the assumption that everyone was using reels of 9-track tape. This was fairly accurate at the time. It wouldn't be a bad idea to have dump accept a size parameter in megabytes. The operator will still have to account for changes in tape capacity when the block size is changed (different number of inter-record gaps). > In fact why doesn't dump use all the space available on the tape > without being told how much on the command line? Because there's no portable, reliable way to sense end of tape on UNIX machines. On machines on which this is possible, the vendor is free to add such a capability. > - Why can't dump work on active file systems? At least for incremental > dumps that would be quite useful to run dump in multi-user mode! dump makes four passes through the file system. If the file system is active while this is going on, information gathered on the early passes will not be valid by the time the final pass is complete. dump does work on active file systems; it's just not as reliable. If you run it on an active file system, the file system will be inconsistent when it is restored. fsck will usually fix this, with some unavoidable loss of data. In extreme cases, the restore will fail. > - Why is dump always interactive? Especially because you have to > wait till every user logs out, it would be nice to have dump > run at night, unattended, and properly coping with tape errors, as a > big boy (and mail to 'root' the results). It should be possible to write a script to make dump run unattended. It's a bit tricky to make it smart enough to unmount the file system for you. As for automatically coping with tape errors, I think you're dreaming. My feeling is that it's an important enough task that it merits the attention of a live operator. If you're thorough about doing the dumps, you'll unmount the file system and run fsck first, at least for level 0 dumps. Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
pavlov@hscfvax.harvard.edu (G.Pavlov) (07/16/88)
In article <23063@labrea.Stanford.EDU>, karish@denali.stanford.edu (Chuck Karish) writes: > In article <170@cui.UUCP> petitp@cui.UUCP (PETITPIERRE Dominique) writes: > > - Why isn't it possible to specify many file system to be stored > > on the same tape (cartridge). > What happens when you want to re-use the first part of the tape, and the > file system you want to dump has grown? You're not able to use the tape > efficiently unless you dump both file systems again. If you take seriously > the purpose of dump, which is to provide security of your users' data, > you may appreciate that it's better to put backups on separate tapes, so > that failure of a single tape does not destroy two backups. > - e.g., the "us programmers know what's best for you" argument. If you do, in fact, take backup seriously, you will set up a schedule of fre- quent full dumps and schedule incremental dumps for every day in-between. If you also happen to own one of the newer high-density cartridge drives, you are typically able to fit far more than one file system on one cartridge. For ONE backup. greg pavlov, fstrf, amherst, ny
chris@mimsy.UUCP (Chris Torek) (07/21/88)
>In article <170@cui.UUCP> petitp@cui.UUCP (PETITPIERRE Dominique) asks: >>- Why doesn't 'restore -t' give you the name of the file system stored >>on the tape? In article <23063@labrea.Stanford.EDU> karish@denali.stanford.edu (Chuck Karish) answers: >Besides, what is the true name of a file system? A block special device may >have more than one link (name) in the root file system. Approximately. At any rate, this is indeed a problem. It would be nice for dump to store advisory information in the primary header (along with the level and date). >>- Is it true that restored files will have their modification time >>always set to the time of the restore command? No. (The `ctime'---the inode change time---will be set to now, since the file must be dumped again.) >>In fact why doesn't dump use all the space available on the tape >>without being told how much on the command line? >Because there's no portable, reliable way to sense end of tape on >UNIX machines. Change `UNIX' to `some': some hardware refuses to detect EOT. >>- Why can't dump work on active file systems? ... >dump does work on active file systems; it's just not as reliable. Correct. Even if dump were redesigned not to use a four-pass approach, a dump of an active file system would still be unreliable: `active' means `changing'; `changing' means you cannot get a consistent picture of the whole without looking at the whole simultaneously. (And then Einstein gets in the way. :-) ) The only way you could make dumping an active file system completely reliable would be to freeze the file system somehow. With slightly different objectives, freezing parts of the file system would suffice. >If you run it on an active file system, the file system will be >inconsistent when it is restored. fsck will usually fix this .... Not so: since restore (with an `e': none of this applies to the old `restor' program) uses the file system interface, what it writes will be self-consistent. It simply may not be the same as what you thought you saved. >>- Why is dump always interactive? >My feeling is that it's an important enough task that it merits the >attention of a live operator. I agree: if you want a reliable backup, you need something that can handle unanticipated situations (e.g., tape drive catches fire). Perhaps there should be an option for `unreliable automatic backup' where success/failure is simply logged somewhere (and hope the log remains intact!). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
haugj@pigs.UUCP (Joe Bob Willie) (07/25/88)
In article <12624@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>In article <170@cui.UUCP> petitp@cui.UUCP (PETITPIERRE Dominique) asks: >>My feeling is that it's an important enough task that it merits the >>attention of a live operator. > >I agree: if you want a reliable backup, you need something that can >handle unanticipated situations my ``live operator'' is in georgia for a week so i get to be the ``live operator'' at 7am for an entire week. arggg. the single largest problem we have with dump is there is no simple way to start a delayed dump. at(1) runs jobs in the background and sleep requires one to convert the delay into seconds. rather than having an operator (or me) come in at 7am, the first reel could be started at 7 or so and let run for half an hour while i sleep ;-) any unexpected events, such as write errors, would result in a delay anyway, right? so, any time lost to having to wait for a human being might not be more than what it would have been had an operator been here all along. - john. -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor
mangler@cit-vax.Caltech.Edu (Don Speck) (08/10/88)
In article <170@cui.UUCP>, petitp@cui.UUCP (PETITPIERRE Dominique) asks: > - Why doesn't 'restore -t' give you the name of the file system stored > on the tape? UKC has modified dump/restore to record and display this information, and they gave the changes to Berkeley. Perhaps it is in 4.3T. > - Is it true that restored files will have their modification time > always set to the time of the restore command? If you abort when it asks 'set owner/mode for "."?', the directory modification times won't be preserved. > - Why isn't it possible to specify the size of the tape in (mega) bytes All tape accounting is in tenths of an inch. There's an unused function in dumpoptr.c which hints that it may have once been in units of blocks (which is more sensible). There's four options (five on Suns) that go into determining one number and it's still not accurate (no "gap" option). > In fact why doesn't dump use all the space available on the tape > without being told how much on the command line? The only Unix indication that the tape is full is a write error. One doesn't know whether the last block or two will be readable, and some (cartridge) tape drives can't backspace, so dump would need to replicate the last few blocks onto the next tape, and indicate this in the TS_TAPE header via spcl.c_tapea. Restore would have to be modified to discard appropriately. In a multi-process dump, where the i-list traversing process may be 600K ahead of actual tape writing, being able to "back up" like this requires keeping an inode/blocknumber pair for each tape block, and modifying the indirect-block traversal algorithm so that it can be restarted from an arbitrary blocknumber (i.e. not be recursive). This is a radical change. > - Why can't dump work on active file systems? If directory entries are removed/renamed before Pass IV, or a large file is truncated while traversing its indirect blocks, the dump will be inconsistent. 4.3 BSD dump detects some cases and skips, but it is still susceptible. Tar and cpio have the SAME PROBLEM. I am aghast at how many people think otherwise. Any other activity is allowed. Linking, creating, and appending files should be OK because inodes and directory entries are written atomically. You should even be able to dump to a (new) file in the same filesystem, since it won't exist until after the mapping passes are finished (try that with cpio!). Just don't rename, remove, or truncate anything. In article <23063@labrea.Stanford.EDU> karish@denali.stanford.edu (Chuck Karish) writes: >If you run it on an active file system, the file system will be >inconsistent when it is restored. fsck will usually fix this .... V7 and 4.1bsd restor wrote the i-list directly and would indeed restore unreferenced files. An fsck afterwards would give the same errors as an fsck done during the dump. 4.2bsd restore cannot produce an inconsistent filesystem, but it often dies trying. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck