From owner-freebsd-questions@FreeBSD.ORG Wed Mar 18 09:22:20 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21E4114B for ; Wed, 18 Mar 2015 09:22:20 +0000 (UTC) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB5738B2 for ; Wed, 18 Mar 2015 09:22:19 +0000 (UTC) Received: from r56.edvax.de (port-92-195-131-196.dynamic.qsc.de [92.195.131.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 717E127847; Wed, 18 Mar 2015 10:22:15 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id t2I9MEeK002029; Wed, 18 Mar 2015 10:22:14 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Wed, 18 Mar 2015 10:22:14 +0100 From: Polytropon To: CK Subject: Re: thrashing + lost files Message-Id: <20150318102214.7d8ae471.freebsd@edvax.de> In-Reply-To: <0MegOs-1Ys1A80zUW-00OIFG@mail.gmx.com> References: <0MegOs-1Ys1A80zUW-00OIFG@mail.gmx.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 09:22:20 -0000 On Tue, 17 Mar 2015 23:56:25 -0800, CK wrote: > I would like any thoughts or ideas on how to prevent the following problem, > because it is making my computer completely unusable, wasting many efforts. > I am using this mail-list because freebsd.forums.org has become completely > unusable to those with dial-up connections, requiring 10 seconds for each > character typed ... no exaggeration. A common reply would be: "Who still uses dial-up anyway?" ;-) > The result is the loss of many critical files from a hard drive, as if a "rm > *" was done in the home directory. This occurs after the thrashing when > Xwindow is accidently shutdown with Opera open with many javascript page tabs, > eg, being a memory pig - consuming 1/2 of RAM (256M), which after dumping > core, writes a large amount of data (crashlog) even after Xwindow is down: > > pid 1118 (opera), uid 1001: exited on signal 11 (core dumped) I thought Opera would simply write a core dump, well, still several 100s of MB though... > FSCK RESULTS: > ------------ > Of interest, is that each time fsck was run, more files were lost! > > # fsck -t ufs -p /dev/ada0p6.eli > /dev/ada0p6.eli: NO WRITE ACCESS > /dev/ada0p6.eli: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. This message should alert you. Don't just preen the disk. In this mode, only a subset of errors will be detected, and not all of them can be corrected. You should actually perform # fsck -t ufs -f /dev/ada0p6.eli with the disk (here: the "decrypted device") unmounted. Performing checks on live file system usually is something that's not encouraged. There are several errors shown: > INCORRECT BLOCK COUNT I=2327435 (8 should be 0) > [...] > UNREF FILE I=2327428 OWNER=abc MODE=100600 > [...] > UNREF FILE I=2327439 OWNER=abc MODE=100600 > [...] > FREE BLK COUNT(S) WRONG IN SUPERBLK > [...] > SUMMARY INFORMATION BAD > [...] > BLK(S) MISSING IN BIT MAPS Unmount the partition, let fsck do its job. :-) Keep in mind: You _can_ use -y as an additional parameter, but you should know what you're doing. Sometimes, -y does not result in what you think it does... > A lost+found directory is never created, which ignorantly, I think should be > created and filled with the "unreferenced inodes" (if that is the correct > term). This directory is created only in case it is needed, by fsck. It won't be there by default. > Regardless, I have lost weeks of work in the last few months from this > problem, and I'm losing faith. Copy files to a different disk (or maybe even external storage, such as USB sticks) temporarily, just to be sure. By the way, I actually _know_ how this feels. Due to a faulty GPU, I lost data from time to time, and sometimes, fsck makes it worse (files disappearing, or zero'd out). A defective file system can be the cause of data loss. I had to learn this, and a major accident (on my old system) has brought me to this list, so there was "something good" in it. ;-) > HARDWARE: > -------- > [...] > ada0: ATA-5 device > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > ada1 at ata1 bus 0 scbus1 target 1 lun 0 > ada1: ATA-4 device > ada1: 33.300MB/s transfers (UDMA2, PIO 8192bytes) > ada1: 4112MB (8421840 512 byte sectors: 15H 63S/T 8912C) > ada1: Previously was known as ad1 > [...] > GEOM_ELI: Device ada0p3.eli created. > GEOM_ELI: Encryption: 3DES-CBC 192 > GEOM_ELI: Crypto: software > GEOM_ELI: Device ada0p6.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software Make sure the file systems are clean. No, really: Test it as recommended (from unmounted devices, with -f). If you got _that_ possible cause off the table, take the next steps, but check this "obvious" cause first. Sometimes, it is that easy. File systems with defects can lead to the "funniest" observations... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...