My CD-R discs all corrupted by freebsd.

msplsh said:
Unfortunately the underlying stuff changes (kernel, drivers, APIs) and then it becomes unstable and nobody remembers how to fix it 😅
Click to expand...
I don't want to shout it but I've stated the reason cd writing is unstable on many FOSS OSs. Unless you can guarantee exclusivity while writing a track, then the track stands a chance of being corrupt...well, that and making sure there is enough data buffered to make the write seamless.
 
Losing the thread in a discussion about the difference between "Disc" and "Disk" :-/ And yet so far nobody mentioned the term "Drive", which to me is to distinguish between a Floppy-, Compact-, Digital Video - or Blu-Ray Disc from a HDD, a Hard Disc Drive, or SSD, a Solid State Drive. 🤓
(Beancounter prevention: Well, yeah, discs are part of a drive, resp. discs need drives. But to me that's only a point when I'm going to look at technical details about their function, not when looking at it as a storage medium.)

kent_dorfman766 said:
That's the thing. being "not wrong" is more highly valued among us old farts than being "sensitive".
Click to expand...

Every engineer knows: Problems cause problems.
So better solve those damned things in time before it's too late.
The first thing to solve a problem is, to admit there is one. In the end solving problems is most of the times a team play, or better be (That's why there are such things as forums.)
It doesn't matter who pointed it out, or who delivered the final touch to solve it, as long as the damn thing is solved. That all starts with respecting the one who pointed out the problem, and not killing the messenger.
Denial doesn't solve anything.

For having a mature conversation that tries to find the truth or leads to a solution both sides can agree to, sensitivity is required a must have. Without sensitivity there can be no respect. Without respect nobody can admit to be wrong. And if nobody is allowed to admit being wrong, because he cannot trust into treated with respect then, there cannot be neither truth nor compromises both sides can live with.

Being right needs no greatness.
Admitting to be wrong proves greatness. It requires trust. Trust requires the greatness of the one being right to treat the wrong one with the respect he earned for admitting made a mistake. Beating the one admitted being wrong ain't no sign of greatness. In contrary, it's just very low. It's abusing trust, which produces loss of respect.
But being not wrong needs nothing at all, not even communication skills. The denial of communication suffices.

We old farts learned that being right is what counts. Youngsters learn not to be wrong.
You don't have to be right to be not wrong.
You can be not wrong while actually being wrong as long as there is no accepted proof you're wrong. For example if you just don't admit you're wrong, simply make your opponent to stop on any further discussion e.g. by delivering an unlimited chain of excuses no matter how silly BS they are, or just refuse to accept the proof, no matter how right it is.
That's the heritage of public discussions like TV's talk shows, that it's not about to find out what is right or wrong, but who wins an argument.
Winning the crowd is winning the argument - not finding out what's right.
There are other techniques, too. See Arthur Schopenhauer, "Eristische Dialektik - oder die Kunst, Recht zu behalten" ("The Art of Being Right"; didn't found an english translation, but I'm sure you'll find one.)

And that's all what it's all about: Winning an argument, doesn't matter what's right or wrong.
Most of the times it's just the opponent gives up, because educated, intelligent people do not fancy stupid talks. "The wiser head gives in." That's why the stupid always win.
And because they are stupid they believe they won because they were the smart ones. That's a punch line they don't get, because they are stupid:
After all their BS won through, then they conclude it must be because of their points were the better ones, which can only be, because those were right.
This way BS replaces facts.
IMO that's the reason why so many things go wrong today: A lack of communication skills based on a lack of respect.


But back to topic:
Aminavy,
Since for many years my standard default mobile mass storages are either USB flash drives, microSD cards or SSDs/HDDs attached to eSATA or USB it's been some years I burnt my last CD. And if, I use(d) RW, which shall make no difference in this case, since the burning process is the same. But I actually found a blank CD-R in the rack. Quite dusty *cough*.
Anyway: tested. worx. 💿➡️📀➡️🗑️😕
So, let us summarize, what we have so far:
My cdrtools are the same version, and as I said on my machine under FreeBSD it works perfectly. So, it's not cdrecord. ✅
On Windows and Linux you get the CDs burnt correctly without problem on the exact same hardware, right? ✅
For data CDs creating an ISO image first is part of the CD burning process under FreeBSD, so here also could be a small chance something went wrong. But by your posts it's clear to me you read the handbook. And I suppose the ISO image you're trying to burn is also in all cases the same. So I exclude this point. Image is OK. ✅
So, this brings me to, that at the moment I can only think of two possible causes:

1. "You should run several tests in all supported speeds of your drive with the -dummy option turned on if you are using cdrecord on an unknown system. Writing a CD is a real-time process." [manpage cdrecord]
As cracauer@ and kent_dorfman766 pointed out, for a successful burn of an optical medium there must be enough data flow to get a continuous (real time) writing process, which means both: enough buffer and enough data transfer (fast enough, continuous, not interrupted.) Today's internal SATA drives shall make no prob, but with external USB drives, especially when mixing USB standards (sometimes even just the (extension) wires are crappy (which cannot be the case here, since under Windows and Linux it works)) I've had several issues with some USB drives not working reliably or even not at all at different machines.
You may try to use your USB burner at another USB port. (2.0 ↔️ 3.x)
USB has some tricky pitfalls.

2. If you want to burn less data than fitting on the disc, e.g. when you're using a standard ISO image of 650 MB on an "oversized" disc of 800 or 900 MB, cdrecord warns you, if you really want to waste that space. If this one is not answered/handled correctly cdrecord does not burn at all or maybe even produce garbage when there is some unconsidered "work around". But alas as mer also asked for, the (error) messages you receive by cdrecord would have helped a lot to get closer.

So, bottom line:
  • try another USB port
  • try an internal drive
  • read and deliver cdrecord's messages for to tell you more/better
  • Do you really need CDs? If it's not an unavoidable must (e.g. for some old machine) use some alternative like flashdrives, since apart from music CDs are almost dead anyway. Rather all computers can read and boot from USB flashdrives, and also car's stereo systems and TV sets are capable to play media from those.
 
There is another iso9660 backend that I use because it supports blu-ray:
sysutils/xorriso
Xorriso is entirely written from scratch. Blu-rays are large enough that I can backup 18GB of my life on very durable and portable media. Works great in linux and is functional in OpenBSD. It also supports CD/DVD-DL disks.
Main caveat is that files cannot exceed 4GB.
 
shepper said:
There is another iso9660 backend that I use because it supports blu-ray:
sysutils/xorriso
Xorriso is entirely written from scratch. Blu-rays are large enough that I can backup 18GB of my life on very durable and portable media. Works great in linux and is functional in OpenBSD. It also supports CD/DVD-DL disks.
Main caveat is that files cannot exceed 4GB.
Click to expand...
I'm not sure of blue-ray per se but writable CD technology is NOT a good archival format. Factory burned cds actually etch the code on the media, but writable CD's use an organic dye that changes compostition when hit with a laser. That organic dye has an average shelf life of about 5 to 10 years and is susceptible to environmental contamination. BAck in the early 2000s I invested heavily in 4GB DVDs for backups. most of those media are unreadable now.

I've found the best backups for me now are hot pluggable SATA disks. I will never use cloud storage...just throwing that out there.
 
kent_dorfman766 said:
I've found the best backups for me now are hot pluggable SATA disks. I will never use cloud storage.
Click to expand...
Me neither. Particulary not as the only BU medium, and especially not if not encrypted already before upload.
That's why I would make an exception for Colin Percival's tarsnap

Anyway I also find HDDs are a good BU medium: They are reliable enough, at least more reliable than any flashdrive or CD, slower than SSDs but fast enough for the job, and cheaper in Byte/€ than SSDs. HDDs need more energy than SSDs, so I wouldn't recommend HDDs over SSDs in any case, but anyway real storage drives for all backup purposes.
Additionally you can chose a sophisticated filesystem so no limits on sizes of files. And when you chose ZFS you have no (real) limits at all, and then you better do a raidz pool of several drives, like 4 HDDs/SSDs into a raidz2 pool, for example. This way you get additional benefits, like redundancy if one drives become defective after some years. So you can replace it without losing data. Plus you can grow the pool aka your BU medium anytime when it's needed by adding more drives, or replacing the ones installed with larger ones.
▶️ an old machine, a couple of drives, FreeBSD, ZFS, NFS & voilá: NAS as a reliable and flexible BU "medium"
 
The disadvantage of harddisks as backup, even if you do snapshots on them, is that most people leave them permanently connected. Or at least connect them regularly. That makes the whole construct vulnerable to randomware attacks or random fatfingering on part of the user.
 
kent_dorfman766 said:
I'm not sure of blue-ray per se but writable CD technology is NOT a good archival format. Factory burned cds actually etch the code on the media, but writable CD's use an organic dye that changes compostition when hit with a laser. That organic dye has an average shelf life of about 5 to 10 years and is susceptible to environmental contamination. BAck in the early 2000s I invested heavily in 4GB DVDs for backups. most of those media are unreadable now.

I've found the best backups for me now are hot pluggable SATA disks. I will never use cloud storage...just throwing that out there.
Click to expand...
Optical drives in general suck in large part due to the time it takes to swap discs when verifying the backups. But, for best results, using par2 helps a lot in terms of verifying and repairing the damage for things where using optical discs for backup is an option. I'd personally put optical media above flash media in terms of use for backups, but both suck compared with tapes and HDDs.
 
hedwards said:
Optical drives in general suck in large part due to the time it takes to swap discs when verifying the backups. But, for best results, using par2 helps a lot in terms of verifying and repairing the damage for things where using optical discs for backup is an option. I'd personally put optical media above flash media in terms of use for backups, but both suck compared with tapes and HDDs.
Click to expand...
I looked into par2 and decided I didn't want to spend that much extra parity space. I believe that for "reliable" reconstruction the par files can get quite large.
 
kent_dorfman766 said:
I looked into par2 and decided I didn't want to spend that much extra parity space. I believe that for "reliable" reconstruction the par files can get quite large.
Click to expand...
I generally set it at 5% personally. But if you don't need to ability to repair files, mtree is great for quickly identifying bad files if you burn the list to disc.
 
Don't get me wrong, doing parity checks, mtree and what else all can be done to ensure data conformity are for sure nothing pointless. In contrary.
But you also need to see what medium you do it on, compare the different methods and their effort, and see what you can automate, and what you still need to do yourself.

It is one strategy to only save the changes. Especially when the amount of data is too large to do daily or even more frequent full BUs, there is no other way. But however you do your BUs, you need at least one complete full BU anyway. That better be 100% save and 100% reliably stored, better twice than once. Because if that's gone all the conscientious saved changes and their parities can be on perfect genuine mediums, they are all just riffraff.
So, if you need it anyway you also can do the BU on a reliable storage in the first place.

Doing such complex and large parity checks to ensure the reproduction of data from a not so reliable storage medium, to me is kind of cludge. If such things get out of hands it's like building a house of clay. Then cover it in plastic foil, to protect the clay from the rain. Then build a surface of wood over it, to protect the plastic from the wind. Then give the wood a new paint every two years... - instead of just building a house of stone in the first place.

And why shall I make all the effort to ensure file errors are detected and corrected when with a ZFS pool containing at least one redundant drive, this is all already given, included, and reliably and fully automated?
I let cron run a scrub every two months, look every couple of days, if all drives are still OK, and the rest is done by ZFS and a few scripts.

Apart from endurance, plastic waste, energy consumption and the price of €/Byte (~1€/GB for low-budget CD-R, ~0.14€/GB for BD - R, not RW), and even if all you need to backup fits on one CD, DVD or BD, 'cause if not, this makes even less sense, there are at least two more reasons against them as BU medium:
They are slow to write to, which limits the ratio of the BU period and the amount of data written per BU session significantly.
And you need to change them manually. Replacing storage mediums manually enlarges the risks of fatfingering and getting not up-to-date BUs.
Back in my Windows days I did also partition clones on USB HDDs as BU. And since those always were annoying to do - boot live system, attach the USB drive, then the cloning lasted... - of course I didn't do that regulary. I learned my lesson since once I needed to fall back on one of those. Dude, I tell you: "Back to the Future", greetings from the way-back-time-machine: "Uh, Oh,... that stuff is months old!" Yeah, time passes quickly. And everything else done since then is blown with the wind... 💩💩💩😭🤬!!

And above all, you also need to think of restoring.
Your BU strategy can be all that smart, well thought, eleborated, polished, etc. As long as you only do backups, everything is fine. All data is written regulary. All mediums are genuine. Perfect. Everything all aces.
But as long as you only write data to your backup mediums that's all just theory.
The real test comes when desaster strikes. When you really have to fall back and restore from your backup.
Then the truth will be revealed - unforgiving - what your backup strategy is really worth.
First thing you need to see, and may be not thought of when you never had that case:
It's all cool as long as nothing happens. But when desaster strikes - your machine suddenly is down, not working anymore, and all you figure out so far is your drive is toast - staying cool ain't not a given. Very high danger for fatfingering, messing things up even worse.
Then you better have a restoration plan you can trust on, handle it blindly with both hands bound on your back, instead of need to think first where is which BU medium, and how is done what in which order. Better already done it at least once. Best having a few notes from that test - a How-To restore from backup (best not be on the machine and the BUs only. 😁) Especially when it's not your own personal private machine, but there is sombody else kicking your arse to see for to make the shit run again ASAP, yesterday would be latest. Then it makes a huge difference, if you have just to type a few commands and let the shit restore for a couple of hours automatically, or if you start fumbling "Uh...Ah,...which CD now first?...WHERE THE F#34 IS THE USB DVD DRIVE!?!!...Uh, that's not the right disc...Aarghh, this one is toast. But no prob, I have a second one... Oh, that was the one with the parity checks for the first one..."🥵🥶😵‍💫
You better keep restoration as simple as possible, starting with as least BU media as possible.

Also, don't start saving storage space, when there is no real need for that.
It simply does make no sense to me at all trying to save somehow 2GB within a 300GB BU when you get a 1TB HDD for less than 30 bucks (0.03€/GB)
Better have 4 of those HDDs in a raidz2 pool, and just write to it automatically, daily, hourly, or whatever. That gives you 2T reliable storage for some years until the first drive blows off. And then all you need to do is just simply replace it. With raidz2 two HDDs can flare off at the same time (3 with raidz3), and you still have no data lost.
Then IMO you can think of improving that even more, by e.g. doing redundant BUs, mtrees, parity checks, encrypting and upload those onto additional webspace or whatever.
 
If the unit works fine in Linux but not FreeBSD the first thing to check is whether Linux has applied any USB quirks that FreeBSD did not. Linux has a much larger base of quirks than FreeBSD.

Could you post `dmesg` from when you connect the writer under Linux?
 
You must log in or register to reply here.
Back
Top