10 Jun
2004
10 Jun
'04
5:32 p.m.
Juhana Sadeharju wrote:
I would be interested in a filesystem that computed checksums in the
background every time a file was copied and reperformed bad copies, but
this sounds like it could be a substantial hit on performance. I wonder
if we'll ever see something like this, or if something already exists even.
Chris
From: Malcolm
Baldridge <linux-audio(a)paypc.com>
Subject: Re: [linux-audio-user] Ardour, Jack, and 2.6 kernels + XRuns
with the Audiophile 24/96 M-Audio
1) You can't use more than one drive per IDE channel.
[ ... ]
It's VERY bad on performance to mix very slow
devices (such as CD-ROMs)
with fast ones: they hold a lock on the bus during all operations,
I recently removed CD-ROM device completely. I ended up doing that
because I got disk errors. The disks are perfectly ok, however.
Some example symptoms were:
-When the CD-ROM device slided in the disk, Alsa audio play was
interrupted for 7 seconds
-File copy sometimes made errors -- such as the highest bit of one
byte of 300 MB file turned from 0 to 1
-File was temporarily corrupted -- error stayed at the same place,
no matter how many times the file was verified; after the boot,
the file was again ok; I made sure the caches were emptied, and so,
it looks like a certain bit pattern or certain address caused the
change in data
I'm still testing and waiting for errors to happen.
This problem has driven me to verify that files are copied ok,
that the created tar.bz2 packages are ok (both the tar.bz2 file
and its content). I also have set Emacs to make the numbered backup
copies and make them by moving (not by copying). Backups, flac, mp3
and ogg codings need to be verified too.
The point is this: how you would know about the rare bit changes
if you never verify the files?
In audio work such a bit changes can go unnoticed. How many of you
verify, e.g., that a simple edit to a file did not made a bit error?
I'm sure that no one verifies. Use of a dither makes the detection
quite hard.