Re: Setting volume size for dump
My apologies to Claus-Justus and Jens: the attribution was incorrect in the previous reply (because I accidentally hit the send key too early ;-) On 11 Nov 1997, Claus-Justus Heine wrote: > "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes: > > > Claus-Justus Heine wrote: > > > ... > > > So does this mean that "SETMARKS" are kind of "second level" file > > > marks? I'm just curious what these things are. There is no real need > > > for me to know it, I'm just curious. > > > > > > > I'm not sure how they're physically done. I didn't even know of them > > until I started I started writing my backup script. I just saw this > > from the mt man page on our HPUX box: > > > >smk Write count setmarks (DDS drives only). > > > >fss Forward space count setmarks (DDS drives only). > > > >bss Backward space count setmarks (DDS drives only). > > > Mmmh. This suggests that these are just anotehr kind of file marks? > The following is from a SCSI-2 standard draft: " A setmark is another type of special recorded element containing no user data, providing a segmentation scheme hierarchically superior to filemarks. This level of segmentation is useful for some high capacity storage devices to provide concise addressing and fast positioning to specific sets of data within a partition. In some implementations, the detection and reporting of setmarks may be controlled by the initiator using the MODE SELECT command." Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
On 11 Nov 1997, Claus-Justus Heine wrote: > "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes: > > Claus-Justus Heine wrote: ... > > So does this mean that "SETMARKS" are kind of "second level" file > > marks? I'm just curious what these things are. There is no real need > > for me to know it, I'm just curious. > > > > I'm not sure how they're physically done. I didn't even know of them > until I started I started writing my backup script. I just saw this > from the mt man page on our HPUX box: > >smk Write count setmarks (DDS drives only). > >fss Forward space count setmarks (DDS drives only). > >bss Backward space count setmarks (DDS drives only). ... > Mmmh. This suggests that these are just anotehr kind of file marks? > ... The following is from a SCSI-2 standard draft: " A setmark is another type of special recorded element containing no user data, providing a segmentation scheme hierarchically superior to filemarks. This level of segmentation is useful for some high capacity storage devices to provide concise addressing and fast positioning to specific sets of data within a partition. In some implementations, the detection and reporting of setmarks may be controlled by the initiator using the MODE SELECT command." Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
"Jens B. Jorgensen" <[EMAIL PROTECTED]> writes: > Claus-Justus Heine wrote: > > > > > > Aren't these marks simply "file marks"? (just asking, I know that > > > > there are thos MTFSS/BSS/WSM tape operations, are these effectively > > > > different from the MTFSF/BSF/WEOF operations?) > > > > > > Yeah, it's a different beast. Trust, me, I can tell mt to find a mark > > > and it'll > > > skip over all kinds of file marks. > > > > So does this mean that "SETMARKS" are kind of "second level" file > > marks? I'm just curious what these things are. There is no real need > > for me to know it, I'm just curious. > > > > I'm not sure how they're physically done. I didn't even know of them > until I started I started writing my backup script. I just saw this > from the mt man page on our HPUX box: > >smk Write count setmarks (DDS drives only). > >fss Forward space count setmarks (DDS drives only). > >bss Backward space count setmarks (DDS drives only). Mmmh. This suggests that these are just anotehr kind of file marks? weofWrite count file marks fsf Forward space count file marks bsf Backward space count file marks Mmh ??? Again. I'm just curious. Cheers Claus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
Claus-Justus Heine wrote: > > "Jens B. Jorgensen" <[EMAIL PROTECTED]> writes: > > > Claus-Justus Heine wrote: > > > > > > > > Aren't these marks simply "file marks"? (just asking, I know that > > > > > there are thos MTFSS/BSS/WSM tape operations, are these effectively > > > > > different from the MTFSF/BSF/WEOF operations?) > > > > > > > > Yeah, it's a different beast. Trust, me, I can tell mt to find a mark > > > > and it'll > > > > skip over all kinds of file marks. > > > > > > So does this mean that "SETMARKS" are kind of "second level" file > > > marks? I'm just curious what these things are. There is no real need > > > for me to know it, I'm just curious. > > > > > > > I'm not sure how they're physically done. I didn't even know of them > > until I started I started writing my backup script. I just saw this > > from the mt man page on our HPUX box: > > > >smk Write count setmarks (DDS drives only). > > > >fss Forward space count setmarks (DDS drives only). > > > >bss Backward space count setmarks (DDS drives only). > > Mmmh. This suggests that these are just anotehr kind of file marks? > > weofWrite count file marks > > fsf Forward space count file marks > > bsf Backward space count file marks > > Mmh ??? > > Again. I'm just curious. I guess what you're asking is more than I know. How are these "marks" actually represented on the media? I have no idea. They certainly are different than file marks because when you search for a set mark you don't stop on a file mark. I can also tell you that searching for a set mark is *much* faster than searching for a file mark. I can't offer any hard numbers to back this up, I've just found it to be true. This fact suggests to me that set marks are fundamentally different than file marks. Why don't you scour the web for for in-depth information? I'd really like for you to email me the URL for such information if you find it since I, too, am curious. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
Claus-Justus Heine wrote: > > > > Aren't these marks simply "file marks"? (just asking, I know that > > > there are thos MTFSS/BSS/WSM tape operations, are these effectively > > > different from the MTFSF/BSF/WEOF operations?) > > > > Yeah, it's a different beast. Trust, me, I can tell mt to find a mark > > and it'll > > skip over all kinds of file marks. > > So does this mean that "SETMARKS" are kind of "second level" file > marks? I'm just curious what these things are. There is no real need > for me to know it, I'm just curious. > I'm not sure how they're physically done. I didn't even know of them until I started I started writing my backup script. I just saw this from the mt man page on our HPUX box: smk Write count setmarks (DDS drives only). fss Forward space count setmarks (DDS drives only). bss Backward space count setmarks (DDS drives only). and it did just what I wanted it to. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
> > Aren't these marks simply "file marks"? (just asking, I know that > > there are thos MTFSS/BSS/WSM tape operations, are these effectively > > different from the MTFSF/BSF/WEOF operations?) > > Yeah, it's a different beast. Trust, me, I can tell mt to find a mark > and it'll > skip over all kinds of file marks. So does this mean that "SETMARKS" are kind of "second level" file marks? I'm just curious what these things are. There is no real need for me to know it, I'm just curious. Thanks Claus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
Claus-Justus Heine wrote: > > > Now all you need is a good script which will do a full dump and then put > > incrementals after it on the same tape, right? Of course! I'm sending you > > my perl backup script (which backs up *multiple* machines) via direct email > > anyone else who's interested can have it to. My backup script has the > > Well, why not? If you think it worth the effort you could also up-load > it to sunsite. I don't think it's polished enough. > > following features: labels tapes with it's own special header so it won't > > overwrite tapes you accidentally left in the drive, will put multiple > > backups on a single tape, and can recover from "missed" backups (because you > > forgot to take that other tape out of the drive), keeps a "directory" of > > what backups are on the tape. You'll probably have to modify it because I > > take advantage of the "mark" capability of 4mm DAT tapes which aren't > > available > > on QIC. You may find it useful all the same. > > Aren't these marks simply "file marks"? (just asking, I know that > there are thos MTFSS/BSS/WSM tape operations, are these effectively > different from the MTFSF/BSF/WEOF operations?) Yeah, it's a different beast. Trust, me, I can tell mt to find a mark and it'll skip over all kinds of file marks. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
> Now all you need is a good script which will do a full dump and then put > incrementals after it on the same tape, right? Of course! I'm sending you > my perl backup script (which backs up *multiple* machines) via direct email > anyone else who's interested can have it to. My backup script has the Well, why not? If you think it worth the effort you could also up-load it to sunsite. > following features: labels tapes with it's own special header so it won't > overwrite tapes you accidentally left in the drive, will put multiple > backups on a single tape, and can recover from "missed" backups (because you > forgot to take that other tape out of the drive), keeps a "directory" of > what backups are on the tape. You'll probably have to modify it because I > take advantage of the "mark" capability of 4mm DAT tapes which aren't > available > on QIC. You may find it useful all the same. Aren't these marks simply "file marks"? (just asking, I know that there are thos MTFSS/BSS/WSM tape operations, are these effectively different from the MTFSF/BSF/WEOF operations?) Cheers Claus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
> 3. In setting the volume size, how can I correctly bring the compression > factor of using zftape into account? This is difficult. Generally, there is no easy way to predict any compressors efficiency unless one knows which kind of data is going to be compressed. When compressing ordinary files I would say that you'll get about 55% of compression (i.e. the compressed size is 55% of the original size, or around that). When compressing data that already is stored in an efficient way -- sound data, compressed images (gif, jpeg ...), compressed files (*.gz, *.Z) -- then you'll get little compression. I fear the only way to find out about the compression factor is to try it out, and then waste a bit of the tape capacity for safety. If you measure an average compression factor of say 55% then I would suggest to calculate with 60%. Cheers Claus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Setting volume size for dump
Johann Spies wrote: > > Thank you for the reactions to my enquiry about efficient backup programs. > > I have overlooked dump and am trying it out now. What I do not seem to > get right is setting the volume size. While using dump like this: > dump 0uf /dev/nzqft0 / it does a backup, but says it requires 11 > tapes asking every now and then for the next volume. > > I tried dump B 1796 0uf /dev/nzqft0 / and dump -s 108700 0uf /dev/nzqft0 / > but in both cases dump complains and does not accept the parameters. > > A dump on /dev/rmt8 results in a large file with the name /dev/rmt8 taking > all the free space on my hard disk. > > My questions : > 1. How can I tel dump to use all the available capacity on my tape? The 's' parameter is correct. Your problem is dump's antiquated command syntax. Like the old tar syntax, all parameters are one-letter and come all bunched together as the first parameters. Arguments required for each parameter follow, in order. Here's a dump command-line I use which incorporates the "size" parameter: dump 0udsf 28600 10 /dev/rmt/0n / In this case, I use the length/density parameters because I'm building the command in a script which backs up and HP machine as well as a Linux machine and the HPUX version doesn't like 'B' as a parameter. Your command above should be: dump 0uBf 1796 /dev/nzqft0 / > 2. How can I change dump's default device to /dev/nzqft0? You can't. The default '/dev/rmt8' is historical and I'm not sure it even truly exists as a device (although 'ls -l /dev/rmt8' yields a device with major=12 and minor=6 I can't find it in the kernel sources). > 3. In setting the volume size, how can I correctly bring the compression > factor of using zftape into account? You can't because the compression yields varying results. With the hardware compression you can get *up to* 50% compression factor. Fortunately, this may not be a problem. You see, the trouble with old tape drives was that they didn't *know* when they got to the end of the tape. Modern tape drives (QIC included, I believe) will report an error when they get to the end of the tape. NOTE WELL: the dump man page says the the Linux version of dump can't correctly do multiple volume backups. C'est la vie, right? My suggestion is to do what I do: I give dump the maxium tape capacity, and if it gets to the end, it'll say that it got to the end of tape and so the dump failed. At least I get an email about it. Now all you need is a good script which will do a full dump and then put incrementals after it on the same tape, right? Of course! I'm sending you my perl backup script (which backs up *multiple* machines) via direct email anyone else who's interested can have it to. My backup script has the following features: labels tapes with it's own special header so it won't overwrite tapes you accidentally left in the drive, will put multiple backups on a single tape, and can recover from "missed" backups (because you forgot to take that other tape out of the drive), keeps a "directory" of what backups are on the tape. You'll probably have to modify it because I take advantage of the "mark" capability of 4mm DAT tapes which aren't available on QIC. You may find it useful all the same. -- Jens B. Jorgensen [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
