From owner-freebsd-questions@FreeBSD.ORG Wed Mar 18 11:05:04 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 1803FAF5 for ; Wed, 18 Mar 2015 11:05:04 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E84D46A0 for ; Wed, 18 Mar 2015 11:05:03 +0000 (UTC) Received: from mail.gmx.com ([72.251.118.231]) by mail.gmx.com (mrgmxus002) with ESMTPA (Nemesis) id 0Maquy-1Yo3fd0mMs-00KPA8 for ; Wed, 18 Mar 2015 12:05:01 +0100 Date: Wed, 18 Mar 2015 03:05:28 -0800 From: "CK" To: Cc: Subject: Re: thrashing + lost files Reply-To: "CK" X-Mailer: UMail v1.0 Message-ID: <0M8Nme-1ZTz3v3hkQ-00vvpg@mail.gmx.com> X-Provags-ID: V03:K0:2sgKWV7YedcqH5vzcW/sqoFP0ob9Os1nUvY/+/r6RFQEDLKrsvq o14m4SULQGoI2deMSuz+1HU5Pji8w1qbtd7kK2dSFFsgmoar7WK8HglxEP3chnO68TAyuBE LeT/xwJ6LGDglu4MPgHzc6bnWAUvtY+9MCMiJGjsX9VkBGLE2GYAe7Lo0r5knb7k74yH3f5 pKDEAndeUnoMJpvLQ/0WQ== X-UI-Out-Filterresults: notjunk:1; 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 11:05:04 -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?" ;-) 10s of millions in the USA. High-speed internet is way too expensive, over $100/mo where I live. Over $1200/yr. Easily 5-10% of take-home salary for many minimal wage workers. > > 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... Interestingly, the core dump was deleted out of the home directory. I caught a quick glimpse of it doing "ls" before it was deleted. As I said, it was exactly like "rm *". Dot files were left intact. At first, I thought it was a bug with journaling/soft-updates, so I disabled those things with tunefs (to the best of my memory). But now it has happened again. The drive was being written to for about 1 minute by the Opera crashlog/coredump. About 45 seconds after Xwindow was already down. > > 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 Thanks, I didn't think of using the -f option. After reading a paper by Marshall McKusick on fsck, it was my understanding that "preen mode" only fixed errors that could be fixed with 100% accuracy. > 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 I lost about 8 files, a lot of legal research/work, in case that is what the (8 should be 0) is citing. > Unmount the partition, let fsck do its job. :-) fsck -t ufs -f /dev/ada0p6.eli only reported that everything was clean. > Copy files to a different disk (or maybe even external storage, > such as USB sticks) temporarily, just to be sure. Yes, I do this of course, with a USB SDRAM device. But I still lose days of work, because I can't back up every minute. This should not happen at all. I have used FreeBSD for 20 years, since 1995, and I never had problems like this before - and I have the same hardware since 2003, which I ran FreeBSD 4.11 on until recently. But only now does this problem occur. Certainly, there is a bug somewhere. My gut feeling is that something is allowing Opera to do things it should not do, or something in the filesystem layers is breaking under the stress of Opera's crash dumps. > > 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