Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I have a script that runs automatically every night on my desktop computer which contains lines of the form: tar cvjf /tmp/backup/bostonre/backup.tbz --files-from=/tmp/backup/bostonre/list.txt Over the last week or two, on large directories, this line has been giving me error messages like: log> bzip2: Caught a SIGSEGV or SIGBUS whilst compressing. log> Possible causes are (most likely first): log> (1) This computer has unreliable memory or cache hardware log> (a surprisingly common problem; try a different machine.) log> (2) A bug in the compiler used to create this executable log> (unlikely, if you didn't compile bzip2 yourself.) log> (3) A real bug in bzip2 -- I hope this should never be the case. log> The user's manual, Section 4.3, has more info on (1) and (2). log> If you suspect this is a bug in bzip2, or are unsure about (1) log> or (2), feel free to report it to me at: jseward at bzip.org. log> Section 4.3 of the user's manual describes the info a useful log> bug report should have. If the manual is available on your log> system, please try and read it before mailing me. If you don't log> have the manual or can't be bothered to read it, mail me anyway. log> Input file = (stdin), output file = (stdout) The manual has more details about how to recompile bzip2 to see if it's something like a compiler optomizer bug. I didn't do that, but I did try running the same command with an Ubuntu Breezy Live disk, and had the same problem, which suggests it isn't Debian Unstable screwing me up. I also did some experiments to see if it was only one of the two disks in the system that had the error, and this doesn't seem to be the case -- in the original script it happens mostly on the older and smaller /home drive, but that's because that's most of what I'm backing up. When I copied the largest directory from the smaller, older, drive to the larger, newer one and backed it up from there, it got the same problem. I was about to go buy a new desktop system (the prices have come down a lot since the last time I looked at them and decided I couldn't afford it), but then last night for the first time in at least a week, the backup script ran without errors. Does anyone have a useful theory about what's going on? Would you dump the computer this week, or wait for some more hardware price dropping? This system is about 5 years old, and I don't think spending much money on improving its hardware really makes sense. But if it's only the backup program that has a problem, and there's a workaround for that (rsync doesn't seem to have any problem copying the affected directories between the two disks), then maybe I don't have to spend the money for a new system this month. Is bzip2 really that much more sensitive to flaky hardware than other programs? And how fast is the hardware likely to get even flakier? -- Laura (mailto:lconrad at laymusic.org , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |