Re: How to use dmsetuup?
Hi,
Gene Heskett wrote:
> > I have 3 100 disk spindles of dvd's bought years ago, that are
> > no longer recognized in any of the 4 or 5 dvd writers I have, but one box
> > of rewritables about the same age, stored n a light tight cardboard box,
> > will likely outlast me.
Unwritten write-once media can indeed get unusable when exposed to light
over a long time. But i have not heard of written DVD getting bad from
indirect light. (Direct sun light is deadly for many things.)
> > Lesson learnt, do not use optical media for long term storage unless
> > stored in tin boxes like AOL gave away billions of 20 years or more ago.
I have a little locker for my media stock. But a substantial number of
my written media are not completely protected from stray light.
David Christensen wrote:
> I have been burning archive DVD-R discs for ~14 years and storing them in a
> drawer (e.g. darkness). I checked the oldest just now and it reads okay.
That's my experience too. I check by MD5 which are stored on the medium
together with the data. If a medium turns out unreadable then in nearly
all cases directly after burning.
Lesson learnt: Never overwrite the two youngest backups.
> I have heard of CD discs disintegrating if the lacquer is scratched:
> https://en.wikipedia.org/wiki/Disc_rot
This never hit me. But i keep my media away from high moisture, corroding
chemicals, and abrasive substances.
> I have heard that RW media has a shorter lifespan than R media.
Not to my experience. I have 4x CD-RW from 2002 (*), DVD+RW from 2004, and
BD-RE from 2008 which still work for backups. From time to time a medium
dies during writing. This seems not to be closely related to age, though.
(*) I have older 2x CD-RW, but no burner any more which would accept them.
They can be still read.
> Does anyone have experience with M-Disc media?
Only by reports of libburn users which say that M-Disc works like the
other media. Their durability can hardly be evaluated, given that normal
media seem to last for more than 2 decades without much problem.
I think the better alternative for archived data would be to make several
identical copies and to checkread them in intervals of a few years. As
soon as one of the copies shows problems, make new copies of the healthy
ones. Payload checksums on the medium give extra trust, although i only
once in my life watched a DVD giving bad data without an SCSI error.
That was reproducible with only a single drive. All others either read
the affected 32 KiB chunk correctly or threw error. Having more than one
drive helps a lot when the read quality is on the edge.
A sincere rescue effort would look like:
xorriso -outdev /dev/sr0 \
-check_media use=outdev \
what=disc \
time_limit=7200 \
data_to="$HOME"/sr0.image \
sector_map="$HOME"/sr0.sector_map \
--
After 7200 seconds the attempt will end even if not finished.
If you want to abort earlier, do not press Ctrl+C but rather do
touch /var/opt/xorriso/do_abort_check_media
The disc image will emerge as file "$HOME"/sr0.image .
The file "$HOME"/sr0.sector_map will record which blocks could be read
without SCSI error. If the run is repeated, then only the missing blocks
will be attempted to be read.
One may repeat with the same drive or better with different ones.
The file "$HOME"/sr0.image and "$HOME"/sr0.sector_map may be carried to
other computers to continue the rescue attempt with their drives.
If there are other partly damaged identical copies of the archive medium,
then one may use them too with the same sr0.image and sr0.sector_map
files.
If the image is an ISO 9660 filesystem made by xorriso with option
-for_backup and thus contains MD5s, then one may check the resulting
image by:
xorriso -for_backup -indev "$HOME"/sr0.image -check_media --
Any protest would indicate that the rescue attempt was not successful.
If the direcory tree is undamaged, one may check the data files by
xorriso -for_backup -indev "$HOME"/sr0.image -check_md5_r sorry / --
to get the paths of files with damaged content.
Other than with most rescue tools, the read operations of xorriso on an
optical drive will be done by direct SCSI commands, not by the Linux block
layer. This has the advantage that error messages are more specific than
just "i/o error" and that no inappropriate reading ahead will happen. Such
reading ahead causes the old TAO CD bug of Linux which gave birth to
interesting urban legends about a "fuzzy end" of data CDs.
Have a nice day :)
Thomas
Reply to: