The Penis Patch is amazing
Finally a Patch that works! http://www.menaro.info/ss/ Penis Growth Extreme -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
> On many servers now I use DVD+RW media for backup purposes just like the > old tape drives, sequential in format using the tar command and written > using sdd with 32k blocks. It is probable that the read-ehad error doesn't show on DVD+RW if the area just following the last block which you want to read has been written to some time previous. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
On Friday 13 May 2005 20:07, James Finnall wrote: > On Friday 13 May 2005 14:34, [EMAIL PROTECTED] wrote: > > Hi, > > > > > I would have expected that what was true of CDs would be true with > > > DVDs. > > > > So let us assume for now that DVDs are still safe > > in that aspect. At least no real problems have > > been reported. (Nevertheless i pad 300 kB) > > If you are interested in another two cents. I see the problem > frequently and in the beginning I thought it was defective hardware. > Until I found out about this kernel read-ahead issue. > > On many servers now I use DVD+RW media for backup purposes just like the > old tape drives, sequential in format using the tar command and written > using sdd with 32k blocks. If this part fails it is almost always media > related, like the customer inserted new media and I didn't know it and > it wasn't formatted. This operation requires Andy's kernel patch. > > After the backup process is complete a verification process is started. > If this error happens it will be near the end of the verification on the > media. It also has a side effect of taking the drive out of DMA mode > and after the failure the backups are a lot slower until the server is > rebooted. But the errors are reported like below. > > Starting Backup . . . > /usr/bin/sdd: Read 3496920 records + 0 bytes (total of 1790423040 bytes > = 1748460.00k). > /usr/bin/sdd: Wrote 54639 records + 12288 bytes (total of 1790423040 > bytes = 1748460.00k). > Starting Verification . . . > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: /dev/scd0: Cannot read: Input/output error > /bin/tar: Too many errors, quitting > /bin/tar: Error is not recoverable: exiting now > Backup operation completed. > > The problem is more frequent on a new server where the customer is > adding data to the drives daily and rarely will be deleting anything. > The backup grows each night and more and more media is required to hold > it. Once the customer starts to delete information, the error becomes > less frequent because the media has stuff written past the new backup. > > This problem might be worked around by writing zeroes to the entire > media before using it. At least it would provide something for it to > read all the way to the end of the media. Since this is not an ISO > image it is just raw data written to the media. > > So far I have not had to use one these failures to reload the data back > on the server. But if I had to, I think that sdd with arguments > instructing how much data to read could be used again to just read the > tar data back to hard disk and then restore it normally. So I have not > used this error problem as a reason to stop using DVD+RW for backup > purposes. The backup itself is complete, it is only the verification > process that will produce this error. > > The best resolution I can think of would be to turn off read-ahead > operations on optical media. Or at least a config option on certain > devices that could be set from rc.local to disable read-ahead caching. > Even just an echo command into the /proc system like the command to turn > on packet forwarding would be sufficient. > > James I just thought of another possible solution I need to test. The write operation using sdd with 32k byte aligned structures requires the use of a raw device to bypass the VM system and file buffering issues. I usually bind the drive to /dev/raw/raw1 for this. If I attempted to verify using the same raw device to read the backup back for verification it might not use the read-ahead that other devices use. I will need to test this but it might be possible for the raw device to bypass the kernel problem. James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
On Friday 13 May 2005 14:34, [EMAIL PROTECTED] wrote: > Hi, > > > I would have expected that what was true of CDs would be true with > > DVDs. > > So let us assume for now that DVDs are still safe > in that aspect. At least no real problems have > been reported. (Nevertheless i pad 300 kB) > If you are interested in another two cents. I see the problem frequently and in the beginning I thought it was defective hardware. Until I found out about this kernel read-ahead issue. On many servers now I use DVD+RW media for backup purposes just like the old tape drives, sequential in format using the tar command and written using sdd with 32k blocks. If this part fails it is almost always media related, like the customer inserted new media and I didn't know it and it wasn't formatted. This operation requires Andy's kernel patch. After the backup process is complete a verification process is started. If this error happens it will be near the end of the verification on the media. It also has a side effect of taking the drive out of DMA mode and after the failure the backups are a lot slower until the server is rebooted. But the errors are reported like below. Starting Backup . . . /usr/bin/sdd: Read 3496920 records + 0 bytes (total of 1790423040 bytes = 1748460.00k). /usr/bin/sdd: Wrote 54639 records + 12288 bytes (total of 1790423040 bytes = 1748460.00k). Starting Verification . . . /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: /dev/scd0: Cannot read: Input/output error /bin/tar: Too many errors, quitting /bin/tar: Error is not recoverable: exiting now Backup operation completed. The problem is more frequent on a new server where the customer is adding data to the drives daily and rarely will be deleting anything. The backup grows each night and more and more media is required to hold it. Once the customer starts to delete information, the error becomes less frequent because the media has stuff written past the new backup. This problem might be worked around by writing zeroes to the entire media before using it. At least it would provide something for it to read all the way to the end of the media. Since this is not an ISO image it is just raw data written to the media. So far I have not had to use one these failures to reload the data back on the server. But if I had to, I think that sdd with arguments instructing how much data to read could be used again to just read the tar data back to hard disk and then restore it normally. So I have not used this error problem as a reason to stop using DVD+RW for backup purposes. The backup itself is complete, it is only the verification process that will produce this error. The best resolution I can think of would be to turn off read-ahead operations on optical media. Or at least a config option on certain devices that could be set from rc.local to disable read-ahead caching. Even just an echo command into the /proc system like the command to turn on packet forwarding would be sufficient. James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
> > I would have expected that what was true of CDs would be true with > > DVDs. > > So let us assume for now that DVDs are still safe > in that aspect. Oh n way! I have had the end-of-recording read errors on DVDs as well, though can't quite remember exactly when it was and therefore which kernel was involved. Prob 2.4, it annoyed me sufficiently that I unconditionally dump 1MB of zeros after everything since then. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unable to read some of a DVD contents
Hi, >> - or to compare the data image on DVD with a checksum > > which was made when that image was written to DVD. > > First time heard about this method. How to actually obtain the DVD checksum? If you got the image stored on disk you may use program md5sum. If you generate and burn the image on-the-fly compute the checksum by a pipe filter. With bash there is a trick called "Process Substitution" which would allow to do that by md5sum, too. On Aug 25 2004, Robert Schiele wrote regarding a related topic : : On bash you can do simply: : $ mkisofs ... | tee >(md5sum) | cdrecord Ok, it's not that simple but it shows a path. You will have to record the output of md5sum as well as the exact size of the image. The size is important since you will hardly get an exact EOF from DVD or CD. At least with CD you need to pad about 300 kB after the the checksumed image to ensure that the image can be completely read. (DVD unsure) So you would need a script which invokes md5sum, counts the bytes and records them in some kind of database. Best is if the checksum gets appended to the image on DVD, too. In my own project i use a C language program for that. So i do not have to rely on exotic >(...) gestures. This also allows additional stunts. For details see http://scdbackup.webframe.org/README search for "Verifying CDs and DVDs" and "Appendix VERIFY". See also http://scdbackup.webframe.org/cd_backup_planer_help for details about some options mentioned in README. > Will this method run faster than the first one? > (We normally have around 1 files to compare). It should not be slower. It avoids directory lookups and random access movements. On my system reading begins with about 4.8 MB/s and accelerates up to 10 MB/s while computing uses up 30% of an AMD 2600+. A full DVD verify of 4.7e bytes lasts about 10 minutes if the media is ok. Damaged media are often quite slow. > Brief explanation on this method will be appreciated (keen to try this out). To make it brief would be serious work ;-) > How did you know there was 300MB data missing at the end of media? > In our case, the file sizes exactly match the file sizes on the harddrive. Those sizes are read from the ISO filesystem directory which is located at the beginning of the disk. That part of your DVD seems to be ok. But it refers to data areas which seem to be damaged. The missing size was detectable because my checksum records contain the size measurement from writing. In my role as developer of backup software i am looking for trouble. Therefore i not only compute a single checksum for the whole backup but one for each 64 kB of data. So i can recognize wether the damage forms single spots or wether it hits wide areas. (For details see README, Appendix REDUNDANCY) > >:-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error > Got this problem before upgrading growisofs. Well, i'm on 5.21. No newer version known. Also, the problem is restricted to a single disk. I'll try cdrecord-ProDVD on it next. It's just for illustration how important a trustworthy checkread is. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unable to read some of a DVD contents
Thanks for the comprehensive explanation, > Hi, > > > what is the indicator that the burn process was only 95% completed? > > The only reliable indicator seems to be checkreading > by all drives which shall be able to read the DVD. > > This would mean either > > - to compare each file on the DVD with its original > on hard disk (if the files on disk did not change > meanwhile) This is the method we used (comparing each file on the DVD with its orginal on hard drive by using 'cmp' command) > > - or to compare the data image on DVD with the data > image on disk (if the image was stored on disk) > > - or to compare the data image on DVD with a checksum > which was made when that image was written to DVD. > (I prefer this method.) First time heard about this method. How to actually obtain the DVD checksum? Will this method run faster than the first one? (We normally have around 1 files to compare). Brief explanation on this method will be appreciated (keen to try this out). > > > I just had to trash a previously used DVD-RW which > failed to pass the checksum test with errors at the > very start of the image. After a test re-write it > failed to deliver the last 2 MB (but the start of the > test image was ok). A third re-write yielded missing > 300 MB at the end of the media. How did you know there was 300MB data missing at the end of media? In our case, the file sizes exactly match the file sizes on the harddrive. > The fourth try failed with >:-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error > According to keys.txt : >3 73 03 POWER CALIBRATION AREA ERROR > (Not much idea what that means but it looks ugly and fatal) > Got this problem before upgrading growisofs. > I successfully tested another DVD-RW from the same > spindle as the ill one. So the burner is not to blame. > > It is not about the manufacturer of the media, not even > about the particular lot. It is not about the number of > re-uses. The sucessfull DVD-RW is in heavy test use, has > a nice collection of scratches ... and it works fine. > The ill one had its third or fourth re-use, looks shiny > and smooth ... > > > Have a nice day :) > > Thomas > Thanks, Kadir -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord-prodvd also fails to write Moviestyle dvd
Volker Kuhlmann <[EMAIL PROTECTED]> writes: > This sounds like an incompatability between your burner and your media. > No software will fix that, other than a firmware fix in the burner. You're probably right. I've upgraded the firmware to no avail. The only way to be sure is to try my burner with nero... If it's a growisofs bug, it would be good to know. > Switch to different media which your burner can handle. Yes. I'll stick with Prodye in the future. But what should I do now with the 90 freesbee I'm left with ... :-/ > If you're talking about reading the disks in consumer DVD players, some > of them aren't terribly good at dealing with some DVD formats. Try a > different type of DVD format. No, I was mentionned simply mounting and reading the dvd *after* an eject (mounting and reading the dvd *before* eject works perfectly well). Cheers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
Hi, > I would have expected that what was true of CDs would be true with > DVDs. So let us assume for now that DVDs are still safe in that aspect. At least no real problems have been reported. (Nevertheless i pad 300 kB) > My (likely outdated) experience passing a CD-sized chunk of bytes over > a pipe was quite unpleasant. It mad the system's performance quite > unpleasant. Hm. There was another report about pipes and growisofs mentioned by Peter Osterlund recently. http://lists.debian.org/cdwrite/2003/12/msg00226.html I never experienced such unpleasant effects with vanilla SuSE 9.1. >From your answer to Volker: > ... where the dd does the truncating ... busted > the disk cache ... You did not use dd bs=1 , did you ? (Throughput on AMD 2600+: 1.6 MB/s = 1.2x DVD) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: existed a legend
You're Invited Thanks to a private nomination, there are potentially three deals that will be offered to you. Notice - past credit history is NOT a factor for this promotion as long as we recieve word from you within 36 hours. In accordance with our terms please verify your information on our secure, private site to ensure our records are accurate. http://www.lendinxsz.net/index.php?refid=windsor Have a Great Day --Jane Arroyo Senior Business Consultant - Low-Rate Advisors Inc. Did this reach you in error? please let us know...thx http://www.lendinxsz.net/r.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
| From: [EMAIL PROTECTED] | Are there really such errors with DVD now ? | With CD there is an embarrassing tradition for that. I'm not sure that it happens with a DVD. I know it happens with CDs. I would have expected that what was true of CDs would be true with DVDs. My one experiment (burning a DVD of Fedora Core 4 test 3 for x86_64) with growisofs worked fine without padding. | Did you already try something like this ? | | ( cat imagefile ; dd if=/dev/zero bs=2K count=150 ) | \ | growisofs -use-the-force-luke -dvd-compat -Z /dev/sr0=/proc/self/fd/0 My (likely outdated) experience passing a CD-sized chunk of bytes over a pipe was quite unpleasant. It mad the system's performance quite unpleasant. | growisofs forwards options of mkisofs but not | those of cdrecord. | mkisofs option -pad should be active by default | but this padding is added to the image file. Yeah, -pad is for mastering, but something like it could be added to the Burning phase, I think. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: growisofs should have a method for padding
| From: Volker Kuhlmann <[EMAIL PROTECTED]> | Completely forget all your this-year's redhat references. This problem | existed at least with kernels 2.2 and 2.4, and is probably as old as | Linux (see references to it for kernels 1.3 in older mkisofs/cdrecord | source around the -pad option). In 2.2 it didn't usually show, in 2.4 it | was difficult to prevent. I've not experienced it until 2.6. I often read raw CDs to compare what is on the CD with a .iso file. My recollection is that before 2.6, there was code to better guess the size of a volume. I was told this, so I don't know what form the code took. | Adding zeros to your image files doesn't change your checksums if you | compute them properly, ie on the ISO image only. I've got scripts for | all the above in my scriptutils package. It does damage any signatures | though, there you ought to use padding with mkisofs. I think that K3B does an md5sum of the disk, taking its idea of file length from the drive. This just does not work. The md5sum command does not take a length argument, so you need to use dd piped to md5sum, where the dd does the truncating. My (long ago) experience with this pipeline was quite unpleasant: I think that it busted the disk cache (as in: the cache was ineffective, not buggy). | The default 20k padding was nowehre near enough on some DVD ISOs on 2.4. Default for what? -pad? DVD mastering? | I agree that it would be useful in growisofs. However a suitable wrapper | script should fix it too. | | > /usr/bin/growisofs: no mkisofs options are permitted with =, aborting... | | Well, if that "=" is with -Z, then growisofs is told to burn an image, | where you're already past mkisofs and therefore barfing on mkisofs | options is a good thing as it may save you a coaster (and makes no sense | either). mkisofs, a mastering program, implements -pad/-padsize. But I'm proposing a second meaning: post-mastering padding. Perhaps the option name should be changed, but I think that the idea is useful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: expired cdrecord-ProDVD builds for HP-UX
> The alpha releases have built-in expiration dates Oops. Then it's about time i get the newer 2.01 binary. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: expired cdrecord-ProDVD builds for HP-UX
On Fri, May 13, 2005 at 04:17:35PM +0200, [EMAIL PROTECTED] wrote: > i resolved my "alarm clock" by downloading only > the current wrapper script > ftp://ftp.berlios.de/pub/cdrecord/ProDVD/cdrecord-wrapper.sh > which obviously contains the new license key. > (Saying: "Key Expires ---> 2005 Oct 22 18:53:20") It's not a license key issue. I checked that first, and we've got the key from February 2005. The alpha releases have built-in expiration dates, and they will simply stop working after a time regardless of how recent the key is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: expired cdrecord-ProDVD builds for HP-UX
Hi, i resolved my "alarm clock" by downloading only the current wrapper script ftp://ftp.berlios.de/pub/cdrecord/ProDVD/cdrecord-wrapper.sh which obviously contains the new license key. (Saying: "Key Expires ---> 2005 Oct 22 18:53:20") I did not have to get a new cdrecord-ProDVD binary. (still "Cdrecord-ProDVD-Clone 2.01b31 (i686-pc-linux-gnu)") Of course this will not bring you further than 2.01a27 with HP-UX. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
expired cdrecord-ProDVD builds for HP-UX
One of my coworkers recently noticed the infamous "Alarm clock" error from cdrecord-ProDVD on our HP-UX workstations. She's been using cdrecord-ProDVD 2.01a27 which is the newest version available on the berlios FTP site for HP-UX. Apparently, this alpha release is expired, and there is no 2.01 release to take its place for HP-UX yet. I advised her to change the symbolic link to point to the 2.0 version instead. Is Joerg planning to release newer versions of cdrecord-ProDVD for HP-UX 10.20, or are we stuck with 2.0 forever? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: unable to read some of a DVD contents
Hi, > what is the indicator that the burn process was only 95% completed? The only reliable indicator seems to be checkreading by all drives which shall be able to read the DVD. This would mean either - to compare each file on the DVD with its original on hard disk (if the files on disk did not change meanwhile) - or to compare the data image on DVD with the data image on disk (if the image was stored on disk) - or to compare the data image on DVD with a checksum which was made when that image was written to DVD. (I prefer this method.) I just had to trash a previously used DVD-RW which failed to pass the checksum test with errors at the very start of the image. After a test re-write it failed to deliver the last 2 MB (but the start of the test image was ok). A third re-write yielded missing 300 MB at the end of the media. The fourth try failed with :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error According to keys.txt : 3 73 03 POWER CALIBRATION AREA ERROR (Not much idea what that means but it looks ugly and fatal) I successfully tested another DVD-RW from the same spindle as the ill one. So the burner is not to blame. It is not about the manufacturer of the media, not even about the particular lot. It is not about the number of re-uses. The sucessfull DVD-RW is in heavy test use, has a nice collection of scratches ... and it works fine. The ill one had its third or fourth re-use, looks shiny and smooth ... A theory which emphasizes the influence of moon phases or geomantic radiation would probably be as successful as the usual methods of DVD compatibilty prediction. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: unable to read some of a DVD contents
> I used verbose option and clearly see that the burn process was completed and > the session was closed. > what is the indicator that the burn process was only 95% completed? The burn was 100% completed at 95% quality. ;) That's putting it colloquially of course. The burner is maladjusted to the media, when all remaining tolerance for successful reading is exceeded, you get a read error. What this really indicates however that the whole process is very marginal with no space for future errors left. Dump those disks, or at least don't expect them to still hold your precious data in a few months. And even if they still work in a few months, don't trust it. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: unable to read some of a DVD contents
>>I've successfully burnt data (4 GB, around 1 files) to a DVD. >>I saw that all the files have been burnt to DVD with exact size.>>However, I couldn't read some of the files (corrupted ?) and this happened randomly (i.e. I burnt another ten DVDs with the same contents and the corruptions >>happened on different files).>A clear indication that you did *not* burn succesfully (only 95%>succesfully - as you see that's not good enough), or that the reader is>unable to read the burnt disk. Media incompatability in both cases, the>drive(s) can't adjust to the inserted media correctly. Try a different>media brand.>Volker I used verbose option and clearly see that the burn process was completed and the session was closed. what is the indicator that the burn process was only 95% completed? I'll definitely try your suggestion with a different media brand. thanks, Kadir
