On Saturday 15 June 2002 15:42, Niall O Broin wrote: >On Sat, Jun 15, 2002 at 11:35:38AM -0400, Gene Heskett wrote: >> Time to compress, or uncompress isn't normally that big a deal >> unless the tape server is a 66mhz P1 or some such slowpoke. > >Even with a fast machine, compressing 8GB is going to take some > time. Of course that doesn't much matter because it'll be done on > the client at night anyway, but I'm more concerned by possible > slowdown on restores which of course will be dependent on the > speed of unzipping. > >> Doubtfull unless the server is a 1.5+ ghz. OTOH, extraction >> time is normally lless than compression time by a large measure. > >I decided that a little empirical testing was in order. On a > sample client gunzipping a file goes at about 3MB/sec. elapsed > time. Data goes to my tape drive (from the Amanda report) at a > max of about 1.5M / sec so presumably it'll come back off the > tape at about the same rate so gunzip should be comfortably able > to keep up with it. In fact a little further consideration makes > me think that compression may actually speed up restores because > I'll have to stream less data off the tape which is of course the > bottleneck in a restore operation. > Don't forget that the drive accepts, and delivers data at the lower of the two speed specs when the compression is turned off.
>> Using a mag tape eraser just wrecks the tape as it destroys the >> hidden from you factory tape header. The tape cannot be mounted >> or recognized by the drive, ever. > >Cancel eraser purchase so :-) Yup. >> To clarify, the tapes OWN header that contains much of this >> compressed or not data will remain in the compressed state, but >> the flags that determine the status of the data on the tape will >> be reset and the rest of the tape will not be written in the >> compressed mode. I rescued about 20 dds2 tapes by doing this in >> a Seagate 4586np drive, aka a CTL-96. >> >> The compression led will come on while the label is being read, >> but will then go back off. > >I'm dubious about the logic here. The lore, as I understood it, > was that there was a magic header written to the tape which said > that it was written compressed and ever after this header's word > was law, and even when the tape was rewritten completely it > stayed in compressed mode once so written, regardless of the > commands sent to the tape. > >However, what you have done here is simply set the tape to > uncompressed and then write AFTER the amanda label. When it gets > down to it, there's no difference between that and simply using > the tape for a backup. I think you missed the sequence there, I used the rewinding device descriptor "st0" when I read the label out to a file, so when the rather copious amounts of /dev/zero output is written, it overwrites the label block as the tape is fully rewound at that point by the closing of the path dd had open to it and to the label file. I also used /dev/zero rather than /dev/urandom because it appeared /dev/urandom was outputting data that made it not very dependable at shutting off the compression, only succeeding about 1/8th the time in my tests here. Note also that if the drive has more buffer than my dds2 drive has, the "count=" in that dd statement may have to be expanded to truely gargauntian numbers in order to actually force a non-compressed write to the tape BEFORE dd is finished, and its this non-compressed write that determines the status of the internal compression flags for the rest of the tape. Once thats uncompressed write has been done by forcing the drive to flush the buffer to the media, the tape can be rewound and the label re-written in the un-compressed state. Leave the extra compression off stuff thats right in front of the label re-write alone else it may turn it back on when its seeking BOT. It doesn't take that long to execute in comparison to the mechanical dance the drive is doing for the rest of it. Forcing the buffer flush seems to reset the compression flag to the instant value when the buffer is flushed provided the tape is at BOT when the flush is forced. I haven't experimented with any middle of the tape switches, so I leave that exersize to someone with lots of time and curiosity. That label is the first block of the tape thats available to you and me and apparently doesn't contain anything but the actual label itself. The internal ident header is in front of that, and forever hidden from us. But the bulk eraser can muck it up and render the tape unusable. >> And I'm not going to claim it works with any drive, these @^%# >> dats seem to write their own laws... > >Well indeed - YMMV and all that. Yep. Methods of issueing caveats vary, sometimes mine are a bit profane if its been a long day of dealing with Murphy and friends, you know, the one that wrote all those Murphy's laws... There are so may he had to have had some help. :-) -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.0% setiathome rank, not too shabby for a WV hillbilly
