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 февр. 2014 г., at 1:57, Xin Li <delphij@delphij.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/24/14 05:54, Dmitry Sivachenko wrote: >> Hello! >> >> FreeBSD 10.0-STABLE #0 r262016M >> >> # fsck /dev/mfid0p1 ** /dev/mfid0p1 Segmentation fault # >> >> truss shows: lseek(3,0x2b0000,SEEK_SET) = >> 2818048 (0x2b0000) >> read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,32768) = 32768 >> (0x8000) lseek(3,0x2b8000,SEEK_SET) = 2850816 >> (0x2b8000) read(3,"\0\0\0\0lo\0\0\0\^N\0\0\0\0\0\0"...,12288) = >> 12288 (0x3000) >> mmap(0x0,-1119879168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) >> ERR#12 'Cannot allocate memory' SIGNAL 11 (SIGSEGV) process exit, >> rval = 0 >> >> >> #0 flushentry () at /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 258 >> if (cgbp->b_un.b_cg == NULL) (gdb) bt #0 flushentry () at >> /place/WRK/src/sbin/fsck_ffs/fsutil.c:258 #1 0x000000000040e827 in >> setup (dev=<value optimized out>) at fsck.h:392 #2 >> 0x0000000000408cd8 in main (argc=1, argv=0x7fffffffda30) at >> /place/WRK/src/sbin/fsck_ffs/main.c:394 >> >> >> >> # 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% >> tunefs: space to hold for metadata blocks: (-k) 9136 >> tunefs: optimization preference: (-o) time >> tunefs: volume label: (-L) >> >> >> Is there any way to complete fsck to get this drive working? > > Can you try this patch and see if it helps? Yes, this patch solves my problem, thanks! > > 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. 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:xkcr53ll3ovcme5f+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>