Skip site navigation (1)Skip section navigation (2)
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>