From owner-freebsd-stable@FreeBSD.ORG Tue Feb 25 11:13:31 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F256ADE for ; Tue, 25 Feb 2014 11:13:31 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C79811C02 for ; Tue, 25 Feb 2014 11:13:30 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so3173369lbv.10 for ; Tue, 25 Feb 2014 03:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CYE5pWP5tJ79drVTvvkRzGibEofwVg3SfV3so/30uHQ=; b=A2h5aEGGDw7VVrSfXNkX1UVs/b+DZz1cvNlBqfrck3+inXSGx6RSaKhfc75qzSCQjT C7lQlQiRl0b4khcZDZ57eyU5mVJfBccYI1/SjkaeS/XFl84Lm9uRKaoD4sTEJkvjwrst TFuHzmxkAXxtSdda4pxhWRCKIBsAEgizgpB1Ct4gIVJjRXf5wGSpZkKYTKVX0oOJ73Rc kotR8XONKwLyYo3ATTOKs9d5iLqazBdlfig7clwN5mEA91d/IdjzEjLTQzSB/3QjPcKI Zr9x4wOoil9gWzPF6Kf7eIIqN3jwv5psjDe4W6fygEIMGNlBOmcWEIGVBjBh/9v+a5bq Fqjg== X-Received: by 10.112.114.228 with SMTP id jj4mr14870587lbb.13.1393326808736; Tue, 25 Feb 2014 03:13:28 -0800 (PST) Received: from 95.108.174.208-red.dhcp.yndx.net (95.108.174.208-red.dhcp.yndx.net. [95.108.174.208]) by mx.google.com with ESMTPSA id jf8sm21935908lbc.8.2014.02.25.03.13.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 03:13:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: fsck dumps core From: Dmitry Sivachenko In-Reply-To: <530BC062.8070800@delphij.net> Date: Tue, 25 Feb 2014 15:13:25 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <206E2401-F263-4D50-9E99-F7603828E206@gmail.com> References: <417919B7-C4D7-4003-9A71-64C4C9E73678@gmail.com> <530BC062.8070800@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1827) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:13:31 -0000 On 25 =D1=84=D0=B5=D0=B2=D1=80. 2014 =D0=B3., at 1:57, Xin Li = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 02/24/14 05:54, Dmitry Sivachenko wrote: >> Hello! >>=20 >> FreeBSD 10.0-STABLE #0 r262016M >>=20 >> # fsck /dev/mfid0p1 ** /dev/mfid0p1 Segmentation fault # >>=20 >> truss shows: lseek(3,0x2b0000,SEEK_SET) =3D >> 2818048 (0x2b0000)=20 >> read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,32768) =3D 32768 >> (0x8000) lseek(3,0x2b8000,SEEK_SET) =3D 2850816 >> (0x2b8000) read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,12288) =3D >> 12288 (0x3000)=20 >> = mmap(0x0,-1119879168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) >> ERR#12 'Cannot allocate memory' SIGNAL 11 (SIGSEGV) process exit, >> rval =3D 0 >>=20 >>=20 >> #0 flushentry () at /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 258 >> if (cgbp->b_un.b_cg =3D=3D NULL) (gdb) bt #0 flushentry () at >> /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 #1 0x000000000040e827 in >> setup (dev=3D) at fsck.h:392 #2 >> 0x0000000000408cd8 in main (argc=3D1, argv=3D0x7fffffffda30) at >> /place/WRK/src/sbin/fsck_ffs/main.c:394 >>=20 >>=20 >>=20 >> # tunefs -p /dev/mfid0p1 tunefs: POSIX.1e ACLs: (-a) >> disabled tunefs: NFSv4 ACLs: (-N) >> disabled tunefs: MAC multilabel: (-l) >> disabled tunefs: soft updates: (-n) >> enabled tunefs: soft update journaling: (-j) >> disabled tunefs: gjournal: (-J) >> disabled tunefs: trim: (-t) >> disabled tunefs: maximum blocks per file in a cylinder group: (-e) >> 4096 tunefs: average file size: (-f) >> 16384 tunefs: average number of files in a directory: (-s) >> 64 tunefs: minimum percentage of free space: (-m) 8%=20 >> tunefs: space to hold for metadata blocks: (-k) 9136=20 >> tunefs: optimization preference: (-o) time=20 >> tunefs: volume label: (-L) >>=20 >>=20 >> Is there any way to complete fsck to get this drive working? >=20 > Can you try this patch and see if it helps? Yes, this patch solves my problem, thanks! >=20 > Note that fsck'ing such a big UFS volume is painful regardless, I know, thanks to FreeBSD stability fsck is rarely needed (that is = probably why nobody noticed this bug for almost 1 year). > any reason not to use e.g. ZFS? Well, you asked: because of it's unacceptable performance (I stopped = using Solaris just before introduction of ZFS, so I can't compare). I tried ZFS several times from it's initial import to FreeBSD almost 7 = years ago. Last attempt was about a year ago with FreeBSD-9. It is always the same story: I was looking for software replacement of = DELL PERC raid controller, so I test different variants of raidz. With low load, it is OK. =20 Under heavy write load, after it eats all free RAM for ARC, writing = process stucks in zio->i state, write performance drops to few MB/sec (with 15-20 disks in raidz), and it takes dozens of seconds even to = spawn login shell. These ZFS problems are heavily documented in mailing lists, time goes = and nothing changes. avg@ states "Empirical/anecdotal safe limit on pool utilization is said = to be about 70-80%." -- isn't it too much price for fsck-less FS? :) = http://markmail.org/message/mtws224umcy5afsa#query:+page:1+mid:xkcr53ll3ov= cme5f+state:results (my problems arise regardless of pool usage, even on almost empty = partition). So either I can't cook it (yes, I spent a lot of time reading FreeBSD's = ZFS wiki and trying different settings), or ZFS is suitable only for = low-load scenarios like root/var/home on zfs.