Date: 31 Jan 2004 12:45:50 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: "Randy Grafton" <rgrafton@indatacorp.com> Cc: freebsd-questions@freebsd.org Subject: Re: File Corruption Message-ID: <44ad44xb8x.fsf@be-well.ilk.org> In-Reply-To: <20040130024418.52651.qmail@mail.indatacorp.com> References: <20040130024418.52651.qmail@mail.indatacorp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Randy Grafton" <rgrafton@indatacorp.com> writes: > ourselves through ftp/sftp and sure enough the file is no longer > functional and we'll have to replace it with another copy. I googled > and searched the lists but have only found tips regarding speeding up > http downloads, (reverting to the current Apache 1.3.x > version). It sounds like hardware trouble to me. The obvious culprit would be a dodgy disk, but you should probably make sure that it isn't really a RAM problem (maybe the file is being cached by the OS). The next time you see a corrupt file, you could try rebooting and see if the file still seems corrupt. If not, then you probably have a RAM problem. To guard against data corruption (it's a fabulously rare occurrence on properly-functioning equipment, but I have data that I'd like to still have accessible in 50 years), I use mtree(8) to checksum all of the files in some of my subdirectory trees, to see if they've changed lately. This would probably be a useful tool in this case, too (at least until the real problem is fixed, although there's no real reason to stop at that point), so that the corrupt files can be caught before customers notice. It is, of course, also possible that the source of the corruption is a bug. I don't recall any reports of such problems on UFS filesystems, but you might want to consider updating to FreeBSD 4.9 on that server. Good luck.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44ad44xb8x.fsf>