Date: Tue, 25 Feb 2014 15:13:25 +0400 From: Dmitry Sivachenko <trtrmitya@gmail.com> To: d@delphij.net Cc: stable@freebsd.org Subject: Re: fsck dumps core Message-ID: <206E2401-F263-4D50-9E99-F7603828E206@gmail.com> In-Reply-To: <530BC062.8070800@delphij.net> References: <417919B7-C4D7-4003-9A71-64C4C9E73678@gmail.com> <530BC062.8070800@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 =D1=84=D0=B5=D0=B2=D1=80. 2014 =D0=B3., at 1:57, Xin Li = <delphij@delphij.net> 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<value optimized out>) 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?206E2401-F263-4D50-9E99-F7603828E206>