fsck dumps core

[Dmitry Sivachenko]

On 25 февр. 2014 г., at 1:57, Xin Li <delphij at 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.