On 7/2/06, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote:
> Mark Knecht wrote:
> > My current problem, which is a big one for me, is that a long used
> > 1394 drive with mostly files that are only ever read - my CD
> > collection ripped to ogg - has, after upgrading to 2.6.17, started to
> > have MANY files which my system says are no longer viable. I did some
> > fsck stuff and it started giving me lots of reports about bad things.
> > I let fsck fix them but it didn't fix any of my files.
> >
> > In line with this problem there are files that work on some days
> > and on other days do not. Weird. Unfortunately it only started with
> > 2.6.17 but I tried going back to 2.6.16 and the files acted the same
> > way so if it's a 1394 problem caused by 2.6.17 it's potentially on the
> > drive with damage done now. Bummer...
>
> Did you (re)write these files under 2.6.17? Of course if there was a
> kernel problem, it could have damaged already existing files too when
> you wrote new files.
None of the ogg files that failed on this drive were rewritten under
2.6.17. There may be a few other files on the drive being rewritten
from time to time but the files that I know have failed are all in ogg
format.
When I first ripped my CD collection I chose ogg as a format. Later I
decided that flac sounds more like the original CD so I am slowly
reripping the collection using flac on a different 1394 drive.
>
> > There have been no messages in dmesg that make any sense to me or
> > seem like they should be posted here. I continue to watch for that.
> [...]
>
> I am still using Linux 2.6.16.11 but with latest FireWire drivers; their
> difference to stock drivers isn't remarkable though. The delta in
> drivers/ieee1394 from 2.6.16 to .17 is quite harmless. What may be more
> relevant to FireWire behaviour could be changes in the block layer,
> memory management, or whatever. I might try 2.6.17 myself RSN...
>
> What type of disk is this bad one? I have two OXFW912 based disks from
> different manufacturers, and one of them has always been unreliable WRT
> read operations. I noticed only because I use one as the backup of the
> other, and when I run a "diff --recursive a/ b/" after having refreshed
> the backup, there are occasional differences in a few files. When I diff
> these files again, they are suddenly reported to be identical. But I
> suppose it is a different problem from yours since I don't get any
> access errors besides these silent read errors, and read succeeds on
> subsequent attempts. (What slightly worries me is the questionable
> service of the backup in a potential restore scenario...)
All my cases are Oxford chips. I believe one that is failing is an
Oxford 911. My flac collection is on a 1394b drive being using in
1394a mode so I don't think that could be a 911.
When the files have failed multiple program will tell me they are bad
files so I don't think it's exactly the same as your problem.
I wish I had both more info and more results. Try 2.6.17 carefully, if you can.
Cheers,
Mark
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
