Date: Sat, 25 Jul 2015 15:31:22 +0200 From: Polytropon <freebsd@edvax.de> To: Matthew Seaman <matthew@freebsd.org> Cc: freebsd-questions@freebsd.org, "CK" <nibbana@gmx.us> Subject: Re: Endless Data Loss Message-ID: <20150725153122.19a57c15.freebsd@edvax.de> In-Reply-To: <55B34B09.3010106@FreeBSD.org> References: <0MRCCJ-1ZUCcr1rAt-00UeQk@mail.gmx.com> <55B34B09.3010106@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Jul 2015 09:38:33 +0100, Matthew Seaman wrote: > On 25/07/2015 08:33, CK wrote: > > In the last 2 years, I have upgraded from 4.11 to 9.2 then 9.3 > > releases, and since upgrading to the 9 series, I have experienced > > endless data loss - every time I reboot my computer, massive numbers > > of files vanish - 20 - 50 - a lot. And it's driving me crazy. > > I don't expect to get any fixes here, but something is wrong > > with the code - it's happening on ATA drives, USB flash drives, > > a few of each kind. So, it's definitely not a hardware problem. > > This is all on the same machine? If it's been in service since 4.11 > days, then it is ancient in computing terms. Don't disregard hardware > problems so quickly. It's not just hard drives that can have problems: > disk controllers, disk cabling, even failing power supplies can result > in these sort of symptoms. Still software problems aren't out of scope as well. In case the problem originates from damaged file systems - maybe when the system continues to run background_fsck and starts to work in an "unclean state" -, so running fsck _at least two times_ on all (!) involved media (unmounted!) should be a step taken, if possible from a live system (CD or DVD). I'm mentioning this because I've had encountered this strange behaviour in the past, too. Additionally, using smartctl to examine SMART-capable disks is important. But as you said: Checking cables, power supply, heat, RAM is important here. The observed loss of files could be a result from either (or many at once). However, the loss of files should be "covered" by some kind of message, usually from fsck "salvaging" inodes. If this is not the case, I assume background_fsck trying (and failing!) to repair a damaged file system could be the reason. This is because background_fsck cannot do all of the things that a regular fsck can do. Idea for solution: Add background_fsck="NO" to /etc/rc.conf and reboot. Let it do its work. Having to wait some minutes vs. losing files... well, the choice is easy. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150725153122.19a57c15.freebsd>