From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 09:49:15 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB13F106566B for ; Sun, 20 Nov 2011 09:49:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6D68FC0A for ; Sun, 20 Nov 2011 09:49:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA02244; Sun, 20 Nov 2011 11:49:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RS41P-000MGY-8L; Sun, 20 Nov 2011 11:49:11 +0200 Message-ID: <4EC8CD14.4040600@FreeBSD.org> Date: Sun, 20 Nov 2011 11:49:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> In-Reply-To: <20111119211921.7ffa9953@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 09:49:15 -0000 on 19/11/2011 22:19 Florian Wagner said the following: >> on 19/10/2011 19:21 Florian Wagner said the following: Andriy Gapon has not said anything in the quoted material? :-) Please set up your mail client correctly or get used to adding quote attributions manually. They do matter. >>>> [...] >>>> >>>>> The only thing I was a bit confused by is that on the boot prompt >>>>> only the pool and filename to be booted are printed. >>>> >>>> Do you mean the (gpt)zfsboot prompt? >>> >>> Yes. For a boot.config with "rpool:root/something:" it prints: >>> >>> Booting from Hard Disk... /boot.config: rpool FreeBSD/x86 boot Default: >>> rpool:/boot/zfsloader boot: >> >> >> Thank you very much for your testing and reports! Please see these >> additional changes: http://people.freebsd.org/~avg/zfsboot.fixes.diff > > Thanks for the additional patch. It seems to be exactly what I'm looking > for. > > Sadly your patches (tested with and without the latest one) seem to break > booting on RAID-Z2 arrays. The prior test, for which I've reported success > were using a VM with only a single disk. Today I tried the patched > bootloader on my fileserver with a 6 disk RAID-Z2 array. That didn't go so > well: > > Installing the modified gptzfsboot results in a blinking screen with > turquoise-striped ASCII background and assorted characters in the > foreground. Not good. Probably a memory corruption. > Installing the modified zfsloader (but unmodified gptzfsboot) makes it > unable to find its root dataset: Patched zfsloader requires certain information to be passed from (gpt)zfsboot, which only the patched version provides. [snip] > A zfsloader built without your patches boots the system. > > Any more information I can provide? Please try to use zfsboottest (formerly zfstest) and a debugger to see where the problem is. I also would appreciate your testing the latest sys/boot code in head or stable/9. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 11:12:51 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99534106564A; Sun, 20 Nov 2011 11:12:51 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id 583A18FC0C; Sun, 20 Nov 2011 11:12:51 +0000 (UTC) Received: from naclador.mos32.de (ppp-88-217-37-245.dynamic.mnet-online.de [88.217.37.245]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id 4C12B3C065AE; Sun, 20 Nov 2011 12:12:50 +0100 (CET) Date: Sun, 20 Nov 2011 12:12:48 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111120121248.5e9773c8@naclador.mos32.de> In-Reply-To: <4EC8CD14.4040600@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6vhN.udN6tGdm8vl3qtc9Sw"; protocol="application/pgp-signature" Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 11:12:51 -0000 --Sig_/6vhN.udN6tGdm8vl3qtc9Sw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 20 Nov 2011 11:49:08 +0200 Andriy Gapon wrote: > Please try to use zfsboottest (formerly zfstest) and a debugger to > see where the problem is. I also would appreciate your testing the > latest sys/boot code in head or stable/9. A bit of help on how to get and use zfs(boot)test on stable-8 or some pointer to a description would be much appreciated. Regards Florian Wagner --Sig_/6vhN.udN6tGdm8vl3qtc9Sw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7I4LAACgkQLvW/2gp2pPyy4wCdGvH10igE0+tJM7NR71mbpVh9 fAAAnjO8KGuM7ZvuBeg82UIChc2asnqJ =Bcix -----END PGP SIGNATURE----- --Sig_/6vhN.udN6tGdm8vl3qtc9Sw-- From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 14:17:02 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79DD0106566C for ; Sun, 20 Nov 2011 14:17:02 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 065258FC0C for ; Sun, 20 Nov 2011 14:17:01 +0000 (UTC) Received: by eyd10 with SMTP id 10so6597947eyd.13 for ; Sun, 20 Nov 2011 06:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+aKZIX4O8iaSPGMfZy+E6Ppsti2c9Wl735Og1tRS+Mw=; b=ls6HpKqJGHAstp4D6qH4RgJV0qLqonnDxdzXJgoZCCcwLl5Thg/TxCq0dkAmMV706A IPM/R9Hd0D+o3+jCQBgd2Et157P+UULgKI3sUGE4Q25ijcFLjMMf+oVbVj7QM5qMCxIM pzD5i8vN/jFDC7T1W2zUV4wmENBrzIcp6k2Ik= Received: by 10.213.28.12 with SMTP id k12mr1123926ebc.114.1321797193517; Sun, 20 Nov 2011 05:53:13 -0800 (PST) Received: from [192.168.1.20] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id 54sm21687520eex.8.2011.11.20.05.53.12 (version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 05:53:12 -0800 (PST) Message-ID: <4EC90648.1030102@gmail.com> Date: Sun, 20 Nov 2011 14:53:12 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4EC64B7E.20406@o2.pl> <4EC65454.7040403@FreeBSD.org> In-Reply-To: <4EC65454.7040403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ZFS version 30 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 14:17:02 -0000 Op 18-11-2011 13:49, Martin Matuska schreef: > On 18.11.2011 13:11, Radio młodych bandytów wrote: >> There was a rumour that Oracle was to open source the latest ZFS code >> after Solaris 11 release. Any news about it? >> > The source code released with Orace Solaris 11 does not contain any CDDL > code. > More information here: http://oss.oracle.com/systems-opensourcecode/ > > I personally do not believe that there will be any new release of ZFS > source code in the near future. This depends purely on Oracle. > > We are currently cooperating with Illumos (http://www.illumos.org): > - Illumos has more ZFS developers than we do > - we have been importing bugfixes and new features from Illumos > - we have been reporting bugs and features from our development that > might be of value for Illumos > > This way the code can be reviewed by more eyes and tested in by a > broader userbase. > So it looks like ZFS gets two streams, an oracle one and an opensource one, where zfs version 28 a prior can be used by both solaris and the opensource versions, after that, they become incompatible. what does this mean if oracle releases version 30 or 31 in to the wild. If FreeBSD and illumos go along, it will be much more difficult to implement these version. New patches can conflict and so on. Or is it time to say goodby to the oracle stream of ZFS and go our own way and never look back, even if oracle releases new versions. To bad oracle chooses this path. regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 15:22:37 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5087C106566C for ; Sun, 20 Nov 2011 15:22:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 966A08FC0C for ; Sun, 20 Nov 2011 15:22:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA04743; Sun, 20 Nov 2011 17:22:33 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RS9E1-000MPb-Cm; Sun, 20 Nov 2011 17:22:33 +0200 Message-ID: <4EC91B36.7060107@FreeBSD.org> Date: Sun, 20 Nov 2011 17:22:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> In-Reply-To: <20111120121248.5e9773c8@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 15:22:37 -0000 on 20/11/2011 13:12 Florian Wagner said the following: > On Sun, 20 Nov 2011 11:49:08 +0200 Andriy Gapon wrote: > >> Please try to use zfsboottest (formerly zfstest) and a debugger to see >> where the problem is. I also would appreciate your testing the latest >> sys/boot code in head or stable/9. > > A bit of help on how to get and use zfs(boot)test on stable-8 or some > pointer to a description would be much appreciated. I think that the most straightforward way would be to checkout tools/tools/zfsboottest from head, copy it into a same named directory under stable/8, make it and run it. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 16:20:31 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84DD4106564A for ; Sun, 20 Nov 2011 16:20:31 +0000 (UTC) (envelope-from rob.vanhooren@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 414C38FC12 for ; Sun, 20 Nov 2011 16:20:30 +0000 (UTC) Received: by yenl11 with SMTP id l11so5710162yen.13 for ; Sun, 20 Nov 2011 08:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:disposition-notification-to:subject:date :message-id:to:mime-version:x-mailer; bh=YvNXZKhkuaYHkUjAqv8PHl/l3jd3rJPpDEuxwifHxls=; b=eBlOEgY4Lh9PAH9X8c1xs97E1VVTyi9d2BelaekboZMqEVKAPB1OOsEpiaMuc/D4oY FEKMD0AyLnw/C1pJ+AZ3cCwh1w3pw+Cb9n8btR20Ihh7SQEh1Sksrq2dr2S+jemb9Zcm XzLR7Z6QsAmzScWqqQTHSyKOfgT38xPEf01A4= Received: by 10.236.129.244 with SMTP id h80mr14904377yhi.130.1321804529924; Sun, 20 Nov 2011 07:55:29 -0800 (PST) Received: from [192.168.200.137] (24-246-91-174.cable.teksavvy.com. [24.246.91.174]) by mx.google.com with ESMTPS id m29sm9851183yhi.20.2011.11.20.07.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Nov 2011 07:55:29 -0800 (PST) From: Rob VanHooren Date: Sun, 20 Nov 2011 10:55:27 -0500 Message-Id: <274A19E2-6A04-4E74-A301-5DDFECA1EDEE@gmail.com> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [zfs][panic] zio_free_issue at zfs mount of child dataset (ddt_phys_decref?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 16:20:31 -0000 Hello. Looking for some input on solving a repeating panic at zfs-v28 mount of = one of a raidz3 pool's child dataset. This is amd64 8.2-STABLE running a freshly csup'd kernel build. System details (obfuscated *.confs can be shared if required): Xeon E5620, 24GB ECC. 2x hpt rr2720 sas2 controller 2x lsi 9211-8i sas2 controller (using lsi's driver, not mps) 1x hpt rr640 sata3 controller HDD are HDS 5K3000 (raidz3) SSD are OCZ Velocity3 (mirrored ZIL,L2ARC) This pool is built on top of individual GELIs (so any *solaris pool = hackery won't be of use) Appears to import fine, zpool status -v is clean, zdb (and zdb -cv) = don't spout complaints ... Mounting the parent works OK: bsd# zfs mount thePOOL Mounting some children works OK: bsd# zfs mount thePOOL/dataset-foo bsd# zfs mount thePOOL/dataset-bar bsd# zfs mount thePOOL/dataset-baz However while attempting to mount one in particular ... kaboom! bsd# zfs mount thePOOL/dataset-xyzzy (order doesn't seem to matter, xyzzy is always the problem child...) System immediately (and repeatably) panics. Transcribed from camera shot: Fatal trap 12: page fault while in kernel mode cpuid =3D 2; apic id =3D 02 fault virtual address =3D 0x30 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff80dc48b1 stack pointer =3D 0x28:0xffffff89190d8b00 frame pointer =3D 0x28:0xffffff89190d8b30 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (zio_free_issue_1) Stopped at ddt_phys_decref+0x1: subq $0x1,0x30(%rdi) db> where Tracing pid 0 tid 100356 td 0xffffff001b8a3000 ddt_phys_decref() at zio_execute+0xc3 taskqueue_run_locked() at taskqueue_run_locked+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f for_exit() at fork_exit+0x135 fork_trampoline() at for_trampoline+0xc an alltrace snippet from db: Tracing command zfs pid 117 tid 100296 td 0xffffff001b28a460 sched_switch() at ... {truncated} mi_switch() at ... sleepq_switch() at ... sleepq_wait() at ... _cv_unit() ... zio_wait() ... arc_read_nolock() ... zil_read_log_data() ... zil_replay_log_record() ... zil_parse() ... zil_replay() ... zfsvfs_setup() ... zfs_mount() ... vfs_domount() ... nmount() ... amd_64_syscall() ... Xfast_syscall() ... --- syscall (378, FreeBSD ELF64, nmount) ... Haven't found any logged PRs that might match, and some hours of = google-fu haven't led to enlightenment :-( Would appreciate your thoughts on this a) prior to opening a new PR, and b) how to approach recovery (~4TB of data on this dataset, about = 10% of the pool) TIA for your effort, R. From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 18:10:22 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A37A1065674; Sun, 20 Nov 2011 18:10:22 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id 140D28FC13; Sun, 20 Nov 2011 18:10:22 +0000 (UTC) Received: from naclador.mos32.de (ppp-88-217-37-245.dynamic.mnet-online.de [88.217.37.245]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id F05333C065AE; Sun, 20 Nov 2011 19:10:20 +0100 (CET) Date: Sun, 20 Nov 2011 19:10:18 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111120191018.1aa4e882@naclador.mos32.de> In-Reply-To: <4EC91B36.7060107@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/lQHAnqhkx7QehUPPqv6_9XE"; protocol="application/pgp-signature" Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 18:10:22 -0000 --Sig_/lQHAnqhkx7QehUPPqv6_9XE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 20 Nov 2011 17:22:30 +0200 Andriy Gapon wrote: > I think that the most straightforward way would be to checkout > tools/tools/zfsboottest from head, copy it into a same named > directory under stable/8, make it and run it. I did just that: # make MACHINE_CPUARCH=3Damd64 Warning: Object directory not changed from original /usr/src/stable-8/tools= /tools/zfsboottest cc -O1 -I/usr/src/stable-8/tools/tools/zfsboottest/../../../sys/boot/zfs -= I/usr/src/stable-8/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs -I. = -fdiagnostics-show-option -W -Wextra -Wno-sign-compare -Wno-unused-parame= ter -Werror -std=3Dgnu99 -fstack-protector -c zfsboottest.c In file inclu= ded from /usr/include/sys/param.h:70, from zfsboottest.c:30: /usr/include/sys/types.h:146: error: expected '=3D', ',', ';', 'asm' or '__= attribute__' before 'cpumask_t' In file included from ./machine/param.h:36, from /usr/include/sys/param.h:116, from zfsboottest.c:30: ./machine/_align.h:6:24: error: x86/_align.h: No such file or directory cc1: warnings being treated as errors zfsboottest.c: In function 'main': zfsboottest.c:141: warning: implicit declaration of function 'zfs_mount_poo= l' zfsboottest.c:148: warning: passing argument 1 of 'zfs_lookup' from incompa= tible pointer type zfsboottest.c:154: warning: passing argument 1 of 'zfs_dnode_stat' from inc= ompatible pointer type After look around a bit I found _types.h and param.h in the machine subdirectory of zfsboottest. They get included from headers in /usr/include because of the "-I.". After renaming them only the errors about zfs_mount_pool and the incompatible pointer types are left. Which make sense to me as this is stuff changed in your patches. Regards Florian Wagner --Sig_/lQHAnqhkx7QehUPPqv6_9XE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7JQooACgkQLvW/2gp2pPwROACdHiQ+WTvBb4JOTeQUZ8drfnO8 XQIAnAk/77v4ggAhkwT9FGVZUfmJgxKK =pCQn -----END PGP SIGNATURE----- --Sig_/lQHAnqhkx7QehUPPqv6_9XE-- From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 20:18:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E64106566C for ; Sun, 20 Nov 2011 20:18:25 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh2-ve3.go2.pl (moh2-ve3.go2.pl [193.17.41.208]) by mx1.freebsd.org (Postfix) with ESMTP id 485B38FC13 for ; Sun, 20 Nov 2011 20:18:25 +0000 (UTC) Received: from moh2-ve3.go2.pl (unknown [10.0.0.208]) by moh2-ve3.go2.pl (Postfix) with ESMTP id D552A372E23 for ; Sun, 20 Nov 2011 21:18:08 +0100 (CET) Received: from unknown (unknown [10.0.0.42]) by moh2-ve3.go2.pl (Postfix) with SMTP for ; Sun, 20 Nov 2011 21:18:08 +0100 (CET) Received: from host892524678.com-promis.3s.pl [89.25.246.78] by poczta.o2.pl with ESMTP id vSCQnh; Sun, 20 Nov 2011 21:18:08 +0100 Message-ID: <4EC9607A.9060101@o2.pl> Date: Sun, 20 Nov 2011 21:18:02 +0100 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Matuska References: <4EC64B7E.20406@o2.pl> <4EC65454.7040403@FreeBSD.org> In-Reply-To: <4EC65454.7040403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-O2-Trust: 2, 63 X-O2-SPF: neutral Cc: freebsd-fs@freebsd.org Subject: Re: ZFS version 30 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 20:18:25 -0000 On 2011-11-18 13:49, Martin Matuska wrote: > On 18.11.2011 13:11, Radio młodych bandytów wrote: >> There was a rumour that Oracle was to open source the latest ZFS code >> after Solaris 11 release. Any news about it? >> > The source code released with Orace Solaris 11 does not contain any CDDL > code. > More information here: http://oss.oracle.com/systems-opensourcecode/ > > I personally do not believe that there will be any new release of ZFS > source code in the near future. This depends purely on Oracle. > > We are currently cooperating with Illumos (http://www.illumos.org): > - Illumos has more ZFS developers than we do > - we have been importing bugfixes and new features from Illumos > - we have been reporting bugs and features from our development that > might be of value for Illumos > > This way the code can be reviewed by more eyes and tested in by a > broader userbase. > Thanks for the info. -- Twoje radio From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 20:22:48 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4679106566B; Sun, 20 Nov 2011 20:22:48 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep34.mx.upcmail.net (fep34.mx.upcmail.net [62.179.121.52]) by mx1.freebsd.org (Postfix) with ESMTP id D40838FC17; Sun, 20 Nov 2011 20:22:47 +0000 (UTC) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20111120200715.YXCQ1724.viefep12-int.chello.at@edge02.upcmail.net>; Sun, 20 Nov 2011 21:07:15 +0100 Received: from pinky ([213.93.232.119]) by edge02.upcmail.net with edge id zY7C1h02W2bDWHx02Y7Eni; Sun, 20 Nov 2011 21:07:15 +0100 X-SourceIP: 213.93.232.119 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: fs@freebsd.org, "Julian Elischer" References: <4EC0BB84.5080803@freebsd.org> Date: Sun, 20 Nov 2011 21:07:14 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4EC0BB84.5080803@freebsd.org> User-Agent: Opera Mail/11.52 (Win32) X-Cloudmark-Analysis: v=1.1 cv=7AjrSHUygkxmgKj9+ZdWPzZoKYzIcpgZMIt1Yxqn8hE= c=1 sm=0 a=Rj6e-IpH9S4A:10 a=la0JkhT7KS8A:10 a=bgpUlknNv7MA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=MkmWaHALQxrO44UWDAMA:9 a=CjuIK1q_8ugA:10 a=5rFzzr0zyXcA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: Subject: Re: ZFS for dummys.... suggestions? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 20:22:48 -0000 On Mon, 14 Nov 2011 07:56:04 +0100, Julian Elischer wrote: > The time has come for me to look at ZFS.. > Is there a reference that is recommended for a quick overview, that > doesn't get bogged down in > the minute details, but gives a good overview? > > Preferably using short words, lots of pictures, and written in large > crayon.. :-) > I don't know if you mean the usage of ZFS or the structure of the code, but the announcement of ZFS in FreeBSD is a nice overview about the usage of ZFS. ZFS - quick start.: http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070616.html Ronald. From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 23:22:01 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 668581065672; Sun, 20 Nov 2011 23:22:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 39D1B8FC14; Sun, 20 Nov 2011 23:22:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAKNM1Ej066862; Sun, 20 Nov 2011 23:22:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAKNM1iH066858; Sun, 20 Nov 2011 23:22:01 GMT (envelope-from linimon) Date: Sun, 20 Nov 2011 23:22:01 GMT Message-Id: <201111202322.pAKNM1iH066858@freefall.freebsd.org> To: yanegomi@gmail.com, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162701: Re: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 23:22:01 -0000 Old Synopsis: Fwd: kern/154447: [zfs] [panic] Occasional panics - solaris assert New Synopsis: Re: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Nov 20 23:20:34 UTC 2011 State-Changed-Why: Misfiled followup to kern/154447; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 20 23:20:34 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=162701 From owner-freebsd-fs@FreeBSD.ORG Sun Nov 20 23:22:56 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD68D1065672; Sun, 20 Nov 2011 23:22:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8798FC1F; Sun, 20 Nov 2011 23:22:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAKNMu5q066951; Sun, 20 Nov 2011 23:22:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAKNMuTs066947; Sun, 20 Nov 2011 23:22:56 GMT (envelope-from linimon) Date: Sun, 20 Nov 2011 23:22:56 GMT Message-Id: <201111202322.pAKNMuTs066947@freefall.freebsd.org> To: andriys@gmail.com, linimon@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 23:22:56 -0000 Synopsis: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Nov 20 23:22:31 UTC 2011 State-Changed-Why: >From misfiled PR kern/162701: Date: Sun, 20 Nov 2011 13:16:38 -0800 From: Garrett Cooper To: bug-followup Subject: Fwd: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code FYI. ---------- Forwarded message ---------- From: Andriy Syrovenko Date: Sun, Nov 20, 2011 at 11:26 AM Subject: Re: kern/154447: [zfs] [panic] Occasional panics - solaris assert somewhere in ZFS code To: Garrett Cooper Hi, I've upgraded the pool to v28 and all underlying filesystems to v5 two weeks ago. No problems so far. I think you can close the PR as resolved in v28. Thanks and best regards, Andriy. http://www.freebsd.org/cgi/query-pr.cgi?pr=154447 From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 00:01:28 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06CCC1065670; Mon, 21 Nov 2011 00:01:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D2E098FC13; Mon, 21 Nov 2011 00:01:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAL01RjB097979; Mon, 21 Nov 2011 00:01:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAL01RIK097959; Mon, 21 Nov 2011 00:01:27 GMT (envelope-from linimon) Date: Mon, 21 Nov 2011 00:01:27 GMT Message-Id: <201111210001.pAL01RIK097959@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162591: [nullfs] cross-filesystem nullfs does not work as expected X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 00:01:28 -0000 Old Synopsis: cross-filesystem nullfs does not work as expected New Synopsis: [nullfs] cross-filesystem nullfs does not work as expected Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 21 00:01:18 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162591 From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 00:57:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3334F1065672 for ; Mon, 21 Nov 2011 00:57:05 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 971998FC1C for ; Mon, 21 Nov 2011 00:57:04 +0000 (UTC) Received: from [IPv6:2001:470:28:140:8931:8b4c:c2c6:e9d3] ([IPv6:2001:470:28:140:8931:8b4c:c2c6:e9d3]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id pAL0v0RO023259 for ; Mon, 21 Nov 2011 02:57:00 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4EC9A1D6.3080506@ukr.net> Date: Mon, 21 Nov 2011 02:56:54 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4EC64B7E.20406@o2.pl> <4EC65454.7040403@FreeBSD.org> In-Reply-To: <4EC65454.7040403@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Mon, 21 Nov 2011 02:57:00 +0200 (EET) X-Spam-Status: No, score=-97.7 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Subject: Re: ZFS version 30 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 00:57:05 -0000 18.11.2011 14:49, Martin Matuska wrote: > We are currently cooperating with Illumos (http://www.illumos.org): Where can I see TODO for the development of ZFS? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 01:34:05 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305BF1065673 for ; Mon, 21 Nov 2011 01:34:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 056F88FC0A for ; Mon, 21 Nov 2011 01:34:04 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAL1Y08F008017 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 17:34:03 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC9AA88.90504@freebsd.org> Date: Sun, 20 Nov 2011 17:34:00 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Ronald Klop References: <4EC0BB84.5080803@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fs@freebsd.org Subject: Re: ZFS for dummys.... suggestions? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 01:34:05 -0000 On 11/20/11 12:07 PM, Ronald Klop wrote: > On Mon, 14 Nov 2011 07:56:04 +0100, Julian Elischer > wrote: > >> The time has come for me to look at ZFS.. >> Is there a reference that is recommended for a quick overview, that >> doesn't get bogged down in >> the minute details, but gives a good overview? >> >> Preferably using short words, lots of pictures, and written in >> large crayon.. :-) >> > > I don't know if you mean the usage of ZFS or the structure of the > code, but the announcement of ZFS in FreeBSD is a nice overview > about the usage of ZFS. > > ZFS - quick start.: > http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070616.html > > Ronald. > > I'm more looking for a description of the way it works.. In UFS we'd have "This is an inode".. etc. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 02:15:52 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97C4106566C; Mon, 21 Nov 2011 02:15:52 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19A618FC1A; Mon, 21 Nov 2011 02:15:51 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so7978627bkb.13 for ; Sun, 20 Nov 2011 18:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eP5bmHeHRZ/O9Pph+zAjksMtr4wrQXtUSgQn0wa2oik=; b=x+kIpC6A8nBNkj3ViOOqC984jSNykMp9nhCi5suRlmDUaQHzE3P1g3vDz9wdOnPIlN 42kuf6Giuq2gSjs/2mYtKJe3aoJyi6YxW1zi1CQ+82KeCD9t/HeeeMZkMLWIlp2luhIh 4QPasN9i0qF3AZhBIRuuALUqQy4TM3RQ1CQHY= MIME-Version: 1.0 Received: by 10.205.131.3 with SMTP id ho3mr12337192bkc.11.1321839902414; Sun, 20 Nov 2011 17:45:02 -0800 (PST) Received: by 10.223.88.72 with HTTP; Sun, 20 Nov 2011 17:45:02 -0800 (PST) In-Reply-To: <4EC0BB84.5080803@freebsd.org> References: <4EC0BB84.5080803@freebsd.org> Date: Sun, 20 Nov 2011 19:45:02 -0600 Message-ID: From: Adam Vande More To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fs@freebsd.org Subject: Re: ZFS for dummys.... suggestions? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 02:15:52 -0000 On Mon, Nov 14, 2011 at 12:56 AM, Julian Elischer wrote: > The time has come for me to look at ZFS.. > Is there a reference that is recommended for a quick overview, that > doesn't get bogged down in > the minute details, but gives a good overview? > > Preferably using short words, lots of pictures, and written in large > crayon.. :-) > This is kind of old, has lots of details, but also has lots of pictures...err diagrams. ;) http://www.oreillynet.com/mac/blog/2007/01/zfs_overview_from_sun.html -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 05:00:45 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A69C8106566B; Mon, 21 Nov 2011 05:00:45 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE0D8FC13; Mon, 21 Nov 2011 05:00:44 +0000 (UTC) Received: by wwg14 with SMTP id 14so9081900wwg.31 for ; Sun, 20 Nov 2011 21:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=OMk+2CNyvznnLz3WvgIdA/5O46EVgD4IBSbAFCC9Rxw=; b=MJEryyAFDg2Mw6Fe+Und3mJlE7j4BWsBEGTcBKijLS+RN276WJJNYWnePdLoyqF4T+ yW71oOU5DRZvCCAp90uivf8+j+oQsypppXNKIgn1+Il6ToA45qwhcqgrqsWbJrTwszc8 99r4inZeniEqkaKYFxX2DBpu6xHqv057BZaBo= Received: by 10.216.132.14 with SMTP id n14mr2155817wei.28.1321850126787; Sun, 20 Nov 2011 20:35:26 -0800 (PST) Received: from DataIX.net (ppp-21.215.dialinfree.com. [209.172.21.215]) by mx.google.com with ESMTPS id hq5sm4559107wib.7.2011.11.20.20.35.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Nov 2011 20:35:25 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pAL4Z8Uu010794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2011 23:35:08 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pAL4E1uA009789; Sun, 20 Nov 2011 23:14:01 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Sun, 20 Nov 2011 23:14:01 -0500 From: Jason Hellenthal To: Julian Elischer Message-ID: <20111121041401.GA7480@DataIX.net> References: <4EC0BB84.5080803@freebsd.org> <4EC9AA88.90504@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC9AA88.90504@freebsd.org> Cc: fs@freebsd.org, Ronald Klop Subject: Re: ZFS for dummys.... suggestions? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 05:00:45 -0000 On Sun, Nov 20, 2011 at 05:34:00PM -0800, Julian Elischer wrote: > On 11/20/11 12:07 PM, Ronald Klop wrote: > > On Mon, 14 Nov 2011 07:56:04 +0100, Julian Elischer > > wrote: > > > >> The time has come for me to look at ZFS.. > >> Is there a reference that is recommended for a quick overview, that > >> doesn't get bogged down in > >> the minute details, but gives a good overview? > >> > >> Preferably using short words, lots of pictures, and written in > >> large crayon.. :-) > >> > > > > I don't know if you mean the usage of ZFS or the structure of the > > code, but the announcement of ZFS in FreeBSD is a nice overview > > about the usage of ZFS. > > > > ZFS - quick start.: > > http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070616.html > > > > Ronald. > > > > > I'm more looking for a description of the way it works.. In UFS we'd > have "This is an inode".. etc. > Sounds like your looking for the On disk format possibly. I saved a copy of this in the downloads section of http://dataix.net which redirects to my googlecode site. You will find the ondiskformat file there in PDF form. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 10:53:55 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC7CC106564A for ; Mon, 21 Nov 2011 10:53:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 04BB88FC08 for ; Mon, 21 Nov 2011 10:53:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19267; Mon, 21 Nov 2011 12:53:51 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RSRVX-000PSX-Ch; Mon, 21 Nov 2011 12:53:51 +0200 Message-ID: <4ECA2DBD.5040701@FreeBSD.org> Date: Mon, 21 Nov 2011 12:53:49 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> In-Reply-To: <20111120191018.1aa4e882@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 10:53:55 -0000 on 20/11/2011 20:10 Florian Wagner said the following: > On Sun, 20 Nov 2011 17:22:30 +0200 > Andriy Gapon wrote: > >> I think that the most straightforward way would be to checkout >> tools/tools/zfsboottest from head, copy it into a same named >> directory under stable/8, make it and run it. > > I did just that: > > # make MACHINE_CPUARCH=amd64 Why did you have to specify MACHINE_CPUARCH? Is your OS amd64 or i386? > Warning: Object directory not changed from original /usr/src/stable-8/tools/tools/zfsboottest BTW, proper build procedure is make obj depend all, so that the source tree is not polluted. > cc -O1 -I/usr/src/stable-8/tools/tools/zfsboottest/../../../sys/boot/zfs -I/usr/src/stable-8/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs -I. -fdiagnostics-show-option -W -Wextra -Wno-sign-compare -Wno-unused-parameter -Werror -std=gnu99 -fstack-protector -c zfsboottest.c In file included from /usr/include/sys/param.h:70, > from zfsboottest.c:30: > /usr/include/sys/types.h:146: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cpumask_t' > In file included from ./machine/param.h:36, > from /usr/include/sys/param.h:116, > from zfsboottest.c:30: > ./machine/_align.h:6:24: error: x86/_align.h: No such file or directory > cc1: warnings being treated as errors > zfsboottest.c: In function 'main': > zfsboottest.c:141: warning: implicit declaration of function 'zfs_mount_pool' > zfsboottest.c:148: warning: passing argument 1 of 'zfs_lookup' from incompatible pointer type > zfsboottest.c:154: warning: passing argument 1 of 'zfs_dnode_stat' from incompatible pointer type > > > After look around a bit I found _types.h and param.h in the machine > subdirectory of zfsboottest. They get included from headers > in /usr/include because of the "-I.". This is intentional and used to work perfectly for me on head. > After renaming them only the errors about zfs_mount_pool and the > incompatible pointer types are left. Which make sense to me as this is > stuff changed in your patches. Here is the latest version from my tree: https://gitorious.org/~avg/freebsd/avgbsd/trees/devel-20110921/tools/tools/zfsboottest Unfortunately I haven't rebased to head for a long time, so it's a quite out of sync with the latest changes there, but it should give you an idea on how to adapt zfsboottest.c to the patches. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 11:07:03 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C721065689 for ; Mon, 21 Nov 2011 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5103B8FC25 for ; Mon, 21 Nov 2011 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pALB73gg053552 for ; Mon, 21 Nov 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pALB72KW053550 for freebsd-fs@FreeBSD.org; Mon, 21 Nov 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Nov 2011 11:07:02 GMT Message-Id: <201111211107.pALB72KW053550@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162564 fs [ext2fs][patch] fs/ext2fs: Add include guard o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161674 fs [ufs] snapshot on journaled ufs doesn't work o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161493 fs [nfs] NFS v3 directory structure update slow o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs Random UFS root filesystem corruption with SU+J [regre o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159971 fs [ffs] [panic] panic with soft updates journaling durin o kern/159930 fs [ufs] [panic] kernel core o kern/159418 fs [tmpfs] [panic] [patch] tmpfs kernel panic: recursing o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159233 fs [ext2fs] [patch] fs/ext2fs: finish reallocblk implemen o kern/159232 fs [ext2fs] [patch] fs/ext2fs: merge ext2_readwrite into o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs [amd] amd(8) ICMP storm and unkillable process. o kern/158711 fs [ffs] [panic] panic in ffs_blkfree and ffs_valloc o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157722 fs [geli] unable to newfs a geli encrypted partition o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148204 fs [nfs] UDP NFS causes overload o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs f kern/127375 fs [zfs] If vm.kmem_size_max>"1073741823" then write spee o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files f sparc/123566 fs [zfs] zpool import issue: EOVERFLOW o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 263 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 14:50:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 777FC106566B for ; Mon, 21 Nov 2011 14:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4CF8FC16 for ; Mon, 21 Nov 2011 14:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pALEoATE061729 for ; Mon, 21 Nov 2011 14:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pALEo9Kd061728; Mon, 21 Nov 2011 14:50:09 GMT (envelope-from gnats) Date: Mon, 21 Nov 2011 14:50:09 GMT Message-Id: <201111211450.pALEo9Kd061728@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Johannes Totz" Cc: Subject: Re: kern/155587: [zfs] [panic] kernel panic with zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johannes Totz List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:50:10 -0000 The following reply was made to PR kern/155587; it has been noted by GNATS. From: "Johannes Totz" To: , Cc: Subject: Re: kern/155587: [zfs] [panic] kernel panic with zfs Date: Mon, 21 Nov 2011 14:46:25 -0000 Looks like http://svnweb.freebsd.org/base?view=revision&revision=226617 fixes the issue. Using a 9-stable r227727 (which includes 226617) I was able to import the pool, detach the file-vdev and reboot the machine normally. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 14:50:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 709BD1065670 for ; Mon, 21 Nov 2011 14:50:12 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id EF11D8FC18 for ; Mon, 21 Nov 2011 14:50:11 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RSVCE-0005pr-Mz for freebsd-fs@freebsd.org; Mon, 21 Nov 2011 15:50:10 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Nov 2011 15:50:10 +0100 Received: from johannes by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Nov 2011 15:50:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Mon, 21 Nov 2011 14:44:48 +0000 Lines: 49 Message-ID: References: <4EC45380.7080006@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4EC45380.7080006@FreeBSD.org> Subject: Re: zfs: panic on import X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:50:12 -0000 On 17/11/2011 00:21, Andriy Gapon wrote: > on 17/11/2011 01:53 Johannes Totz said the following: >> On 16/11/2011 18:40, Johannes Totz wrote: >>> On 16/11/2011 17:50, Freddie Cash wrote: >>>> On Wed, Nov 16, 2011 at 9:47 AM, Johannes Totz >>>> wrote: >>>> >>>>> Does anybody have a very recent FreeBSD live cd/dvd image that I >>>>> could try? >>>>> >>>> >>>> The FreeBSD 9.0 install CD is a LiveCD. The first screen gives you the >>>> option of starting the installer or dropping to a shell. >>>> >>>> 9.0-RC2 CDs are available on ftp://ftp.freebsd.org and should be >>>> available >>>> on most mirrors by now. >>>> >>> >>> Ah thanks for the pointer, I always get lost navigating the ftp sever... >>> >>> But, same panic unfortunately (transcribbled): >>> >>> current process: txg_thread_enter >>> panic: page fault >>> ... >>> #5 ... calltrap >>> #6 ... zio_vdev_io_start >>> #7 ... zio_execute >>> #8 ... zio_ioctl >>> #9 ... zio_flush >>> #10 ... vdev_config_sync >>> #11 ... spa_sync >>> #12 ... txg_sync_thread >>> #13 ... fork_exit >>> #14 ... fork_trampoline >> >> This PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155587 seems related. I >> also offlined the file-vdev before the machine crashed. Now it panics on import. >> And I don't get any dump either... > > > Perhaps the following commit might help you > http://svnweb.freebsd.org/base?view=revision&revision=226617 Looks like that patch fixed it! Using a 9-stable r227727 I was able to import the pool, detach the file-vdev and reboot the machine normally. I will update the PR. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 15:00:31 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFD31065673 for ; Mon, 21 Nov 2011 15:00:31 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F2F948FC15 for ; Mon, 21 Nov 2011 15:00:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pALF0UEH070182 for ; Mon, 21 Nov 2011 15:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pALF0UKv070180; Mon, 21 Nov 2011 15:00:30 GMT (envelope-from gnats) Date: Mon, 21 Nov 2011 15:00:30 GMT Message-Id: <201111211500.pALF0UKv070180@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Gleb Kurtsou Cc: Subject: Re: kern/162591: [nullfs] cross-filesystem nullfs does not work as expected X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Kurtsou List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:00:31 -0000 The following reply was made to PR kern/162591; it has been noted by GNATS. From: Gleb Kurtsou To: bug-followup@FreeBSD.org, mw@wzff.de Cc: Subject: Re: kern/162591: [nullfs] cross-filesystem nullfs does not work as expected Date: Mon, 21 Nov 2011 16:23:47 +0200 That is expected behaviour, according to mount_nullfs(8): The mount_nullfs utility creates a null layer, duplicating a sub-tree of the file system name space under another part of the global file system namespace. It mentions sub-tree of a single file system only. nullfs is technically very different from loop mounts in Linux or nullfs in DragonFly, it doesn't map part of file name space elsewhere, but duplicates file system sub-tree. Messing with v_mountedhere in nullfs would bring much more trouble than it can potentially solve: VFS_VGET(), full path lookups, etc. We could add mount option to automatically nullfs-mount nested mounts, but it also feels overcomplicated: unmounting may be difficult, should we track new mounts, etc. Mounting nullfs over nullfs is a very bad idea imo (it it's not forbidden, I'd also suggest not to NFS export nullfs). I think writing a small script to do nested mounts/unmounts that suites your needs would be the best option here. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 16:11:02 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D4C1065676 for ; Mon, 21 Nov 2011 16:11:02 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer.dco.penx.com [174.46.214.165]) by mx1.freebsd.org (Postfix) with ESMTP id AC55F8FC0A for ; Mon, 21 Nov 2011 16:10:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by Elmer.dco.penx.com (8.14.5/8.14.4) with ESMTP id pALGAs0S058413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Nov 2011 09:10:56 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 21 Nov 2011 09:10:54 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: freebsd-fs@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Errors (ZFS) with Supmermicro AOC-USAS2-L8e X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:11:02 -0000 I have two of those boards flashed with IT and on both I see reset notices. I also have an LSI 9211-8i in both systems flashed to IT and do not see resets. Both handle ZFS volumes. Clearly I've missed something. Any idea what to look at? mps1: port 0xee00-0xeeff mem 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 mps1: Firmware: 11.00.00.00 mps1: IOCCapabilities: 1285c mps1: [ITHREAD] da5 at mps1 bus 0 scbus10 target 0 lun 0 da6 at mps1 bus 0 scbus10 target 1 lun 0 da7 at mps1 bus 0 scbus10 target 2 lun 0 da8 at mps1 bus 0 scbus10 target 3 lun 0 da9 at mps1 bus 0 scbus10 target 6 lun 0 da10 at mps1 bus 0 scbus10 target 7 lun 0 (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da7:mps1:0:2:0): CAM status: SCSI Status Error (da7:mps1:0:2:0): SCSI status: Check Condition (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da5:mps1:0:0:0): CAM status: SCSI Status Error (da5:mps1:0:0:0): SCSI status: Check Condition (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da9:mps1:0:6:0): CAM status: SCSI Status Error (da9:mps1:0:6:0): SCSI status: Check Condition (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 (da8:mps1:0:3:0): CAM status: SCSI Status Error (da8:mps1:0:3:0): SCSI status: Check Condition (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 16:15:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA7E106566C for ; Mon, 21 Nov 2011 16:15:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAB68FC15 for ; Mon, 21 Nov 2011 16:15:05 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id zs5s1h0041GXsucAFsExvt; Mon, 21 Nov 2011 16:14:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id zs1s1h01Y1t3BNj8Us1sjc; Mon, 21 Nov 2011 16:01:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CE021102C19; Mon, 21 Nov 2011 08:15:03 -0800 (PST) Date: Mon, 21 Nov 2011 08:15:03 -0800 From: Jeremy Chadwick To: Dennis Glatting Message-ID: <20111121161503.GA53628@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Errors (ZFS) with Supmermicro AOC-USAS2-L8e X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:15:05 -0000 On Mon, Nov 21, 2011 at 09:10:54AM -0700, Dennis Glatting wrote: > I have two of those boards flashed with IT and on both I see reset > notices. I also have an LSI 9211-8i in both systems flashed to IT and do > not see resets. Both handle ZFS volumes. > > Clearly I've missed something. Any idea what to look at? > > > mps1: port 0xee00-0xeeff mem > 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 > mps1: Firmware: 11.00.00.00 > mps1: IOCCapabilities: > 1285c > mps1: [ITHREAD] > da5 at mps1 bus 0 scbus10 target 0 lun 0 > da6 at mps1 bus 0 scbus10 target 1 lun 0 > da7 at mps1 bus 0 scbus10 target 2 lun 0 > da8 at mps1 bus 0 scbus10 target 3 lun 0 > da9 at mps1 bus 0 scbus10 target 6 lun 0 > da10 at mps1 bus 0 scbus10 target 7 lun 0 > (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da7:mps1:0:2:0): CAM status: SCSI Status Error > (da7:mps1:0:2:0): SCSI status: Check Condition > (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > or bus device reset occurred) > (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da5:mps1:0:0:0): CAM status: SCSI Status Error > (da5:mps1:0:0:0): SCSI status: Check Condition > (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > or bus device reset occurred) > (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da9:mps1:0:6:0): CAM status: SCSI Status Error > (da9:mps1:0:6:0): SCSI status: Check Condition > (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > or bus device reset occurred) > (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 > (da8:mps1:0:3:0): CAM status: SCSI Status Error > (da8:mps1:0:3:0): SCSI status: Check Condition > (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > or bus device reset occurred) uname -a please, as we need to know what kernel version and build date of the system you're using. Thanks. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 16:41:25 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F869106566C for ; Mon, 21 Nov 2011 16:41:25 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [66.114.146.51]) by mx1.freebsd.org (Postfix) with ESMTP id 11C118FC16 for ; Mon, 21 Nov 2011 16:41:24 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.4) with ESMTP id pALG3niI094485 for ; Mon, 21 Nov 2011 08:03:49 -0800 (PST) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: freebsd-fs@freebsd.org Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 21 Nov 2011 08:03:49 -0800 Message-ID: <1321891429.66381.22.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: pALG3niI094485 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com X-yoursite-MailScanner-Watermark: 1322496229.89344@VTfgxVIpasvVee8F3b5/qw Subject: Errors (ZFS) with Supmermicro AOC-USAS2-L8e X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:41:25 -0000 I have two of those boards flashed with IT and on both I see reset notices. I also have an LSI 9211-8i in both systems flashed to IT and do not see resets. Both handle ZFS volumes. Clearly I've missed something. Any idea what to look at? mps1: port 0xee00-0xeeff mem 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 mps1: Firmware: 11.00.00.00 mps1: IOCCapabilities: 1285c mps1: [ITHREAD] da5 at mps1 bus 0 scbus10 target 0 lun 0 da6 at mps1 bus 0 scbus10 target 1 lun 0 da7 at mps1 bus 0 scbus10 target 2 lun 0 da8 at mps1 bus 0 scbus10 target 3 lun 0 da9 at mps1 bus 0 scbus10 target 6 lun 0 da10 at mps1 bus 0 scbus10 target 7 lun 0 (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da7:mps1:0:2:0): CAM status: SCSI Status Error (da7:mps1:0:2:0): SCSI status: Check Condition (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da5:mps1:0:0:0): CAM status: SCSI Status Error (da5:mps1:0:0:0): SCSI status: Check Condition (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da9:mps1:0:6:0): CAM status: SCSI Status Error (da9:mps1:0:6:0): SCSI status: Check Condition (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 (da8:mps1:0:3:0): CAM status: SCSI Status Error (da8:mps1:0:3:0): SCSI status: Check Condition (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 16:48:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7034F106566B for ; Mon, 21 Nov 2011 16:48:19 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer.dco.penx.com [174.46.214.165]) by mx1.freebsd.org (Postfix) with ESMTP id 444648FC17 for ; Mon, 21 Nov 2011 16:48:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by Elmer.dco.penx.com (8.14.5/8.14.4) with ESMTP id pALGmG25064363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Nov 2011 09:48:18 -0700 (MST) (envelope-from freebsd@penx.com) Date: Mon, 21 Nov 2011 09:48:16 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: Jeremy Chadwick In-Reply-To: <20111121161503.GA53628@icarus.home.lan> Message-ID: References: <20111121161503.GA53628@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Errors (ZFS) with Supmermicro AOC-USAS2-L8e X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:48:19 -0000 Below On Mon, 21 Nov 2011, Jeremy Chadwick wrote: > On Mon, Nov 21, 2011 at 09:10:54AM -0700, Dennis Glatting wrote: >> I have two of those boards flashed with IT and on both I see reset >> notices. I also have an LSI 9211-8i in both systems flashed to IT and do >> not see resets. Both handle ZFS volumes. >> >> Clearly I've missed something. Any idea what to look at? >> >> >> mps1: port 0xee00-0xeeff mem >> 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 >> mps1: Firmware: 11.00.00.00 >> mps1: IOCCapabilities: >> 1285c >> mps1: [ITHREAD] >> da5 at mps1 bus 0 scbus10 target 0 lun 0 >> da6 at mps1 bus 0 scbus10 target 1 lun 0 >> da7 at mps1 bus 0 scbus10 target 2 lun 0 >> da8 at mps1 bus 0 scbus10 target 3 lun 0 >> da9 at mps1 bus 0 scbus10 target 6 lun 0 >> da10 at mps1 bus 0 scbus10 target 7 lun 0 >> (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 >> (da7:mps1:0:2:0): CAM status: SCSI Status Error >> (da7:mps1:0:2:0): SCSI status: Check Condition >> (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >> or bus device reset occurred) >> (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 >> (da5:mps1:0:0:0): CAM status: SCSI Status Error >> (da5:mps1:0:0:0): SCSI status: Check Condition >> (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >> or bus device reset occurred) >> (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 >> (da9:mps1:0:6:0): CAM status: SCSI Status Error >> (da9:mps1:0:6:0): SCSI status: Check Condition >> (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >> or bus device reset occurred) >> (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 >> (da8:mps1:0:3:0): CAM status: SCSI Status Error >> (da8:mps1:0:3:0): SCSI status: Check Condition >> (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, >> or bus device reset occurred) > > uname -a please, as we need to know what kernel version and build date > of the system you're using. Thanks. > iirc> uname -a FreeBSD iirc 8.2-STABLE FreeBSD 8.2-STABLE #36: Fri Nov 18 04:26:35 PST 2011 root@iirc:/disk-1/src/sys/amd64/compile/IIRC amd64 iirc> zpool status pool: disk-1 state: ONLINE scan: scrub repaired 0 in 0h41m with 0 errors on Thu Nov 17 23:37:20 2011 config: NAME STATE READ WRITE CKSUM disk-1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da6 ONLINE 0 0 0 da2 ONLINE 0 0 0 da4 ONLINE 0 0 0 da9 ONLINE 0 0 0 da7 ONLINE 0 0 0 da10 ONLINE 0 0 0 da5 ONLINE 0 0 0 da8 ONLINE 0 0 0 da3 ONLINE 0 0 0 cache ada0 ONLINE 0 0 0 errors: No known data errors pool: disk-2 state: ONLINE scan: scrub repaired 0 in 0h3m with 0 errors on Thu Oct 27 23:41:37 2011 config: NAME STATE READ WRITE CKSUM disk-2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada2 ONLINE 0 0 0 cache ada1 ONLINE 0 0 0 errors: No known data errors iirc> dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #36: Fri Nov 18 04:26:35 PST 2011 root@iirc:/disk-1/src/sys/amd64/compile/IIRC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 940 @ 2.93GHz (2981.09-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Family = 6 Model = 1a Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 25769803776 (24576 MB) avail memory = 24825692160 (23675 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfdd0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 ahci0: port 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f mem 0xfbdff000-0xfbdff7ff irq 16 at device 0.0 on pci1 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 8 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ahcich6: at channel 6 on ahci0 ahcich6: [ITHREAD] ahcich7: at channel 7 on ahci0 ahcich7: [ITHREAD] pcib2: irq 16 at device 2.0 on pci0 pci2: on pcib2 xhci0: mem 0xfbcfe000-0xfbcfffff irq 16 at device 0.0 on pci2 xhci0: [ITHREAD] xhci0: 32 byte context size. usbus0 on xhci0 pcib3: irq 16 at device 3.0 on pci0 pci3: on pcib3 vgapci0: port 0xce00-0xceff mem 0xe0000000-0xefffffff,0xfb8c0000-0xfb8dffff irq 16 at device 0.0 on pci3 pci3: at device 0.1 (no driver attached) pcib4: irq 16 at device 5.0 on pci0 pci4: on pcib4 arcmsr0: port 0xbe00-0xbeff mem 0xfb7f0000-0xfb7fffff,0xfb780000-0xfb7bffff irq 16 at device 0.0 on pci4 ARECA RAID ADAPTER0: Driver Version 1.20.00.22 2011-07-04 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.49 2011-08-02 arcmsr0: [ITHREAD] pcib5: irq 16 at device 7.0 on pci0 pci5: on pcib5 mps0: port 0x7e00-0x7eff mem 0xfb6fc000-0xfb6fffff,0xfb680000-0xfb6bffff irq 16 at device 0.0 on pci5 mps0: Firmware: 07.00.00.00 mps0: IOCCapabilities: 185c mps0: [ITHREAD] pcib6: irq 16 at device 9.0 on pci0 pci6: on pcib6 mps1: port 0xee00-0xeeff mem 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 mps1: Firmware: 11.00.00.00 mps1: IOCCapabilities: 1285c mps1: [ITHREAD] pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) uhci0: port 0xff00-0xff1f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus1: on uhci0 uhci1: port 0xfe00-0xfe1f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus2: on uhci1 uhci2: port 0xfd00-0xfd1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus3: on uhci2 ehci0: mem 0xfbffe000-0xfbffe3ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib7: irq 16 at device 28.0 on pci0 pci7: on pcib7 em0: port 0xaf00-0xaf1f mem 0xfbbc0000-0xfbbdffff,0xfbb00000-0xfbb7ffff,0xfbbfc000-0xfbbfffff irq 16 at device 0.0 on pci7 em0: Using MSIX interrupts with 3 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:c1:aa:97 pcib8: irq 16 at device 28.4 on pci0 pci8: on pcib8 re0: port 0x9e00-0x9eff mem 0xfbaff000-0xfbafffff,0xfbaf8000-0xfbafbfff irq 16 at device 0.0 on pci8 re0: Using 1 MSI-X message re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 1c:6f:65:3e:ee:50 re0: [ITHREAD] pcib9: irq 17 at device 28.5 on pci0 pci9: on pcib9 re1: port 0x8e00-0x8eff mem 0xfb9ff000-0xfb9fffff,0xfb9f8000-0xfb9fbfff irq 17 at device 0.0 on pci9 re1: Using 1 MSI-X message re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 1c:6f:65:3e:ee:60 re1: [ITHREAD] uhci3: port 0xfc00-0xfc1f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] usbus5: on uhci3 uhci4: port 0xfb00-0xfb1f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] usbus6: on uhci4 uhci5: port 0xfa00-0xfa1f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] usbus7: on uhci5 ehci1: mem 0xfbffd000-0xfbffd3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus8: EHCI version 1.0 usbus8: on ehci1 pcib10: at device 30.0 on pci0 pci10: on pcib10 isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0xf900-0xf907,0xf800-0xf803,0xf700-0xf707,0xf600-0xf603,0xf500-0xf51f mem 0xfbffc000-0xfbffc7ff irq 19 at device 31.2 on pci0 ahci1: [ITHREAD] ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich8: at channel 0 on ahci1 ahcich8: [ITHREAD] ahcich9: at channel 1 on ahci1 ahcich9: [ITHREAD] ahcich10: at channel 2 on ahci1 ahcich10: [ITHREAD] ahcich11: at channel 3 on ahci1 ahcich11: [ITHREAD] ahcich12: at channel 4 on ahci1 ahcich12: [ITHREAD] ahcich13: at channel 5 on ahci1 ahcich13: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x73 on acpi0 qpi0: on motherboard orm0: at iomem 0xc0000-0xcffff,0xdb000-0xdbfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 coretemp4: on cpu4 est4: on cpu4 p4tcc4: on cpu4 coretemp5: on cpu5 est5: on cpu5 p4tcc5: on cpu5 coretemp6: on cpu6 est6: on cpu6 p4tcc6: on cpu6 coretemp7: on cpu7 est7: on cpu7 p4tcc7: on cpu7 Timecounters tick every 1.000 msec usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 12Mbps Full Speed USB v1.0 usbus8: 480Mbps High Speed USB v2.0 ugen0.1: <0x1033> at usbus0 uhub0: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ugen8.1: at usbus8 uhub8: on usbus8 uhub0: 4 ports with 4 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub7: 2 ports with 2 removable, self powered uhub4: 6 ports with 6 removable, self powered uhub8: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen2.2: at usbus2 ukbd0: on usbus2 ugen3.2: at usbus3 kbd2 at ukbd0 uhid0: on usbus2 ahcich7: Poll timeout on slot 0 port 0 ahcich7: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 50 serr 00000000 cmd 10004016 ada0 at ahcich8 bus 0 scbus11 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich9 bus 0 scbus12 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) ada2 at ahcich10 bus 0 scbus13 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3 at ahcich11 bus 0 scbus14 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) da0 at arcmsr0 bus 0 scbus8 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: Command Queueing enabled da0: 953869MB (1953523712 512 byte sectors: 255H 63S/T 121601C) da1 at mps0 bus 0 scbus9 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da2 at mps0 bus 0 scbus9 target 1 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da3 at mps0 bus 0 scbus9 target 2 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da4 at mps0 bus 0 scbus9 target 3 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da5 at mps1 bus 0 scbus10 target 0 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 300.000MB/s transfers da5: Command Queueing enabled da5: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da6 at mps1 bus 0 scbus10 target 1 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da7 at mps1 bus 0 scbus10 target 2 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 300.000MB/s transfers da7: Command Queueing enabled da7: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da8 at mps1 bus 0 scbus10 target 3 lun 0 da8: Fixed Direct Access SCSI-6 device da8: 300.000MB/s transfers da8: Command Queueing enabled da8: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da9 at mps1 bus 0 scbus10 target 6 lun 0 da9: Fixed Direct Access SCSI-6 device da9: 600.000MB/s transfers da9: Command Queueing enabled da9: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da10 at mps1 bus 0 scbus10 target 7 lun 0 da10: Fixed Direct Access SCSI-6 device da10: 300.000MB/s transfers da10: Command Queueing enabled da10: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) pass1 at arcmsr0 bus 0 scbus8 target 16 lun 0 pass1: Fixed Processor SCSI-0 device SMP: AP CPU #1 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #6 Launched! Trying to mount root from ufs:/dev/da0p3 ZFS filesystem version 5 ZFS storage pool version 28 ugen2.2: at usbus2 (disconnected) ukbd0: at uhub2, port 1, addr 2 (disconnected) uhid0: at uhub2, port 1, addr 2 (disconnected) ugen2.2: at usbus2 ukbd0: on usbus2 kbd2 at ukbd0 uhid0: on usbus2 (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da7:mps1:0:2:0): CAM status: SCSI Status Error (da7:mps1:0:2:0): SCSI status: Check Condition (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da5:mps1:0:0:0): CAM status: SCSI Status Error (da5:mps1:0:0:0): SCSI status: Check Condition (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 (da9:mps1:0:6:0): CAM status: SCSI Status Error (da9:mps1:0:6:0): SCSI status: Check Condition (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 (da8:mps1:0:3:0): CAM status: SCSI Status Error (da8:mps1:0:3:0): SCSI status: Check Condition (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) pid 2395 (akonadiserver), uid 128: exited on signal 11 (core dumped) pid 2492 (akonadiserver), uid 128: exited on signal 11 (core dumped) pid 2494 (akonadiserver), uid 128: exited on signal 11 (core dumped) From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 19:13:36 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F621106564A; Mon, 21 Nov 2011 19:13:36 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id CC5138FC18; Mon, 21 Nov 2011 19:13:35 +0000 (UTC) Received: from naclador.mos32.de (ppp-93-104-19-127.dynamic.mnet-online.de [93.104.19.127]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id 624123C06C32; Mon, 21 Nov 2011 20:13:34 +0100 (CET) Date: Mon, 21 Nov 2011 20:13:32 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111121201332.03ecadf1@naclador.mos32.de> In-Reply-To: <4ECA2DBD.5040701@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/X6aSwgeoAgChpVCe8x9kQrH"; protocol="application/pgp-signature" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:13:36 -0000 --Sig_/X6aSwgeoAgChpVCe8x9kQrH Content-Type: multipart/mixed; boundary="MP_//MBHRQfNoPRXJOHOsWppEk4" --MP_//MBHRQfNoPRXJOHOsWppEk4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 21 Nov 2011 12:53:49 +0200 Andriy Gapon wrote: > Why did you have to specify MACHINE_CPUARCH? > Is your OS amd64 or i386?MACHINE_CPUARCH? Otherwise I get: # make "Makefile", line 22: Malformed conditional (${MACHINE_CPUARCH} =3D=3D "amd6= 4") "Makefile", line 27: if-less endif make: fatal errors encountered -- cannot continue Looking at share/mk/sys.mk in both stable-8 and head I see that MACHINE_CPUARCH is only defined in head. > > Warning: Object directory not changed from > > original /usr/src/stable-8/tools/tools/zfsboottest >=20 >=20 > BTW, proper build procedure is make obj depend all, so that the > source tree is not polluted. Ah ok, thanks for that info. I don't know anything about the build process except for the "enduser interface" (make buildworld, etc.). > Here is the latest version from my tree: > https://gitorious.org/~avg/freebsd/avgbsd/trees/devel-20110921/tools/tool= s/zfsboottest This one compiles and combined with zfsboottest.sh from head... 1. # ./zfsboottest.sh root The "mountpoint" property of dataset "root/stable-8-r226381" should be s= et to "legacy". The bootloader from stable-8 didn't seem to care that the mountpoint was set to none, but to get further with zfsboottest I set it to legacy. 2. # ./zfsboottest.sh root zfsboottest.sh is reading all the files in //boot using boot code and using file system code. It calculates MD5 checksums for all the files and will compare them. If all files can be properly read using boot code, it is very likely you will be able to boot from "root" pool>:> Good luck! ZFS: i/o error - all block copies unavailable ZFS: can't read MOS pool: root config: =20 NAME STATE root ONLINE raidz2 ONLINE gptid/fe19a168-12e0-11e1-9070-deadbeef1028 ONLINE gptid/fe62ed10-12e0-11e1-9070-deadbeef1028 ONLINE gptid/fc93472b-12e0-11e1-9070-deadbeef1028 ONLINE gptid/fd8b167c-12e0-11e1-9070-deadbeef1028 ONLINE Then it just hangs there. I've let it run for a few minutes, but even in a VM with emulated IDE controller the 11MB of files in /boot shouldn't take very long. On repeated runs the "ZFS: i/o error" and "can't read MOS" sometimes are there and sometimes they are not. 3. Rebuilt zfsboottest with -g -O0 and ran it in gdb with my vdev devices and one single file. I've attached a gdb session but haven't gotten very far. My C debugging-fu is rather weak ;). The SIGFPE from zfsboottest.gdb.log.2 is not easily reproduced... Regards Florian --MP_//MBHRQfNoPRXJOHOsWppEk4-- --Sig_/X6aSwgeoAgChpVCe8x9kQrH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7KotwACgkQLvW/2gp2pPwEZwCePXiipIyuYU0R2mu0+9/VsoH2 /ZsAnjtesNy8eBZcaB7dryXHJ9YvVPUu =oXs8 -----END PGP SIGNATURE----- --Sig_/X6aSwgeoAgChpVCe8x9kQrH-- From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 19:49:44 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F80106566C; Mon, 21 Nov 2011 19:49:44 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id CE5448FC13; Mon, 21 Nov 2011 19:49:43 +0000 (UTC) Received: from [212.182.167.131] (helo=sjakie.klop.ws) by smtp-out2.tiscali.nl with esmtp (Exim) (envelope-from ) id 1RSZiB-0006Wj-Od; Mon, 21 Nov 2011 20:39:27 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 4B622653C; Mon, 21 Nov 2011 20:39:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Julian Elischer" References: <4EC0BB84.5080803@freebsd.org> <4EC9AA88.90504@freebsd.org> Date: Mon, 21 Nov 2011 20:39:21 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <4EC9AA88.90504@freebsd.org> User-Agent: Opera Mail/11.52 (FreeBSD) Content-Transfer-Encoding: quoted-printable Cc: fs@freebsd.org Subject: Re: ZFS for dummys.... suggestions? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:49:44 -0000 On Mon, 21 Nov 2011 02:34:00 +0100, Julian Elischer = =20 wrote: > On 11/20/11 12:07 PM, Ronald Klop wrote: >> On Mon, 14 Nov 2011 07:56:04 +0100, Julian Elischer =20 >> wrote: >> >>> The time has come for me to look at ZFS.. >>> Is there a reference that is recommended for a quick overview, that =20 >>> doesn't get bogged down in >>> the minute details, but gives a good overview? >>> >>> Preferably using short words, lots of pictures, and written in large = =20 >>> crayon.. :-) >>> >> >> I don't know if you mean the usage of ZFS or the structure of the code= , =20 >> but the announcement of ZFS in FreeBSD is a nice overview about the =20 >> usage of ZFS. >> >> ZFS - quick start.: =20 >> http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070616.h= tml >> >> Ronald. >> >> > I'm more looking for a description of the way it works.. In UFS we'd =20 > have "This is an inode".. etc. This has some info which is nice to read about the background and =20 differences of ZFS en BTRFS. But not the chart you are looking for I thin= k. http://lwn.net/Articles/342892/ From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 20:48:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574AA1065677 for ; Mon, 21 Nov 2011 20:48:19 +0000 (UTC) (envelope-from freebsd@pki2.com) Received: from btw.pki2.com (btw.pki2.com [66.114.146.51]) by mx1.freebsd.org (Postfix) with ESMTP id DA5008FC1D for ; Mon, 21 Nov 2011 20:48:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.5/8.14.4) with ESMTP id pALKigpm014297; Mon, 21 Nov 2011 12:44:42 -0800 (PST) (envelope-from freebsd@pki2.com) From: Dennis Glatting To: Dennis Glatting In-Reply-To: References: <20111121161503.GA53628@icarus.home.lan> Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 21 Nov 2011 12:44:42 -0800 Message-ID: <1321908282.66381.27.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Dennis Glatting X-yoursite-MailScanner-ID: pALKigpm014297 X-yoursite-MailScanner: Found to be clean X-MailScanner-From: freebsd@pki2.com X-yoursite-MailScanner-Watermark: 1322513085.31945@UH+uCILFdW7uOMQ8ps2kDg Cc: freebsd-fs@freebsd.org Subject: Re: Errors (ZFS) with Supmermicro AOC-USAS2-L8e X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 20:48:19 -0000 On Mon, 2011-11-21 at 09:48 -0700, Dennis Glatting wrote: > Below > I forgot to mention that these are two separate AOC-USAS2-L8e boards in two different systems, both flashed with the same firmware. Both systems have an AOC-USAS2-L8e and a LSI 9211-8i but motherboard, processor, memory, etc are different. > On Mon, 21 Nov 2011, Jeremy Chadwick wrote: > > > On Mon, Nov 21, 2011 at 09:10:54AM -0700, Dennis Glatting wrote: > >> I have two of those boards flashed with IT and on both I see reset > >> notices. I also have an LSI 9211-8i in both systems flashed to IT and do > >> not see resets. Both handle ZFS volumes. > >> > >> Clearly I've missed something. Any idea what to look at? > >> > >> > >> mps1: port 0xee00-0xeeff mem > >> 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 > >> mps1: Firmware: 11.00.00.00 > >> mps1: IOCCapabilities: > >> 1285c > >> mps1: [ITHREAD] > >> da5 at mps1 bus 0 scbus10 target 0 lun 0 > >> da6 at mps1 bus 0 scbus10 target 1 lun 0 > >> da7 at mps1 bus 0 scbus10 target 2 lun 0 > >> da8 at mps1 bus 0 scbus10 target 3 lun 0 > >> da9 at mps1 bus 0 scbus10 target 6 lun 0 > >> da10 at mps1 bus 0 scbus10 target 7 lun 0 > >> (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > >> (da7:mps1:0:2:0): CAM status: SCSI Status Error > >> (da7:mps1:0:2:0): SCSI status: Check Condition > >> (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > >> or bus device reset occurred) > >> (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > >> (da5:mps1:0:0:0): CAM status: SCSI Status Error > >> (da5:mps1:0:0:0): SCSI status: Check Condition > >> (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > >> or bus device reset occurred) > >> (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > >> (da9:mps1:0:6:0): CAM status: SCSI Status Error > >> (da9:mps1:0:6:0): SCSI status: Check Condition > >> (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > >> or bus device reset occurred) > >> (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 > >> (da8:mps1:0:3:0): CAM status: SCSI Status Error > >> (da8:mps1:0:3:0): SCSI status: Check Condition > >> (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, > >> or bus device reset occurred) > > > > uname -a please, as we need to know what kernel version and build date > > of the system you're using. Thanks. > > > > iirc> uname -a > FreeBSD iirc 8.2-STABLE FreeBSD 8.2-STABLE #36: Fri Nov 18 04:26:35 PST > 2011 root@iirc:/disk-1/src/sys/amd64/compile/IIRC amd64 > > > iirc> zpool status > pool: disk-1 > state: ONLINE > scan: scrub repaired 0 in 0h41m with 0 errors on Thu Nov 17 23:37:20 2011 > config: > > NAME STATE READ WRITE CKSUM > disk-1 ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > cache > ada0 ONLINE 0 0 0 > > errors: No known data errors > > pool: disk-2 > state: ONLINE > scan: scrub repaired 0 in 0h3m with 0 errors on Thu Oct 27 23:41:37 2011 > config: > > NAME STATE READ WRITE CKSUM > disk-2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > cache > ada1 ONLINE 0 0 0 > > errors: No known data errors > > > iirc> dmesg > Copyright (c) 1992-2011 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.2-STABLE #36: Fri Nov 18 04:26:35 PST 2011 > root@iirc:/disk-1/src/sys/amd64/compile/IIRC amd64 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 940 @ 2.93GHz (2981.09-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x106a4 Family = 6 Model = 1a Stepping > = 4 > > Features=0xbfebfbff > > Features2=0x98e3bd > AMD Features=0x28100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 25769803776 (24576 MB) > avail memory = 24825692160 (23675 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, dfdd0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > ahci0: port > 0xdf00-0xdf07,0xde00-0xde03,0xdd00-0xdd07,0xdc00-0xdc03,0xdb00-0xdb0f mem > 0xfbdff000-0xfbdff7ff irq 16 at device 0.0 on pci1 > ahci0: [ITHREAD] > ahci0: AHCI v1.20 with 8 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > ahcich2: at channel 2 on ahci0 > ahcich2: [ITHREAD] > ahcich3: at channel 3 on ahci0 > ahcich3: [ITHREAD] > ahcich4: at channel 4 on ahci0 > ahcich4: [ITHREAD] > ahcich5: at channel 5 on ahci0 > ahcich5: [ITHREAD] > ahcich6: at channel 6 on ahci0 > ahcich6: [ITHREAD] > ahcich7: at channel 7 on ahci0 > ahcich7: [ITHREAD] > pcib2: irq 16 at device 2.0 on pci0 > pci2: on pcib2 > xhci0: mem 0xfbcfe000-0xfbcfffff irq > 16 at device 0.0 on pci2 > xhci0: [ITHREAD] > xhci0: 32 byte context size. > usbus0 on xhci0 > pcib3: irq 16 at device 3.0 on pci0 > pci3: on pcib3 > vgapci0: port 0xce00-0xceff mem > 0xe0000000-0xefffffff,0xfb8c0000-0xfb8dffff irq 16 at device 0.0 on pci3 > pci3: at device 0.1 (no driver attached) > pcib4: irq 16 at device 5.0 on pci0 > pci4: on pcib4 > arcmsr0: > port 0xbe00-0xbeff mem 0xfb7f0000-0xfb7fffff,0xfb780000-0xfb7bffff irq > 16 at device 0.0 on pci4 > ARECA RAID ADAPTER0: Driver Version 1.20.00.22 2011-07-04 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.49 2011-08-02 > arcmsr0: [ITHREAD] > pcib5: irq 16 at device 7.0 on pci0 > pci5: on pcib5 > mps0: port 0x7e00-0x7eff mem > 0xfb6fc000-0xfb6fffff,0xfb680000-0xfb6bffff irq 16 at device 0.0 on pci5 > mps0: Firmware: 07.00.00.00 > mps0: IOCCapabilities: > 185c > mps0: [ITHREAD] > pcib6: irq 16 at device 9.0 on pci0 > pci6: on pcib6 > mps1: port 0xee00-0xeeff mem > 0xfbefc000-0xfbefffff,0xfbe80000-0xfbebffff irq 16 at device 0.0 on pci6 > mps1: Firmware: 11.00.00.00 > mps1: IOCCapabilities: > 1285c > mps1: [ITHREAD] > pci0: at device 16.0 (no driver > attached) > pci0: at device 16.1 (no driver > attached) > pci0: at device 17.0 (no driver > attached) > pci0: at device 17.1 (no driver > attached) > pci0: at device 20.0 (no driver > attached) > pci0: at device 20.1 (no driver > attached) > pci0: at device 20.2 (no driver > attached) > uhci0: port 0xff00-0xff1f irq > 16 at device 26.0 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x2f00 > usbus1: on uhci0 > uhci1: port 0xfe00-0xfe1f irq > 21 at device 26.1 on pci0 > uhci1: [ITHREAD] > uhci1: LegSup = 0x2f00 > usbus2: on uhci1 > uhci2: port 0xfd00-0xfd1f irq > 18 at device 26.2 on pci0 > uhci2: [ITHREAD] > uhci2: LegSup = 0x2f00 > usbus3: on uhci2 > ehci0: mem > 0xfbffe000-0xfbffe3ff irq 18 at device 26.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib7: irq 16 at device 28.0 on pci0 > pci7: on pcib7 > em0: port 0xaf00-0xaf1f mem > 0xfbbc0000-0xfbbdffff,0xfbb00000-0xfbb7ffff,0xfbbfc000-0xfbbfffff irq 16 > at device 0.0 on pci7 > em0: Using MSIX interrupts with 3 vectors > em0: [ITHREAD] > em0: [ITHREAD] > em0: [ITHREAD] > em0: Ethernet address: 00:1b:21:c1:aa:97 > pcib8: irq 16 at device 28.4 on pci0 > pci8: on pcib8 > re0: port > 0x9e00-0x9eff mem 0xfbaff000-0xfbafffff,0xfbaf8000-0xfbafbfff irq 16 at > device 0.0 on pci8 > re0: Using 1 MSI-X message > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 1c:6f:65:3e:ee:50 > re0: [ITHREAD] > pcib9: irq 17 at device 28.5 on pci0 > pci9: on pcib9 > re1: port > 0x8e00-0x8eff mem 0xfb9ff000-0xfb9fffff,0xfb9f8000-0xfb9fbfff irq 17 at > device 0.0 on pci9 > re1: Using 1 MSI-X message > re1: Chip rev. 0x2c000000 > re1: MAC rev. 0x00000000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re1: Ethernet address: 1c:6f:65:3e:ee:60 > re1: [ITHREAD] > uhci3: port 0xfc00-0xfc1f irq > 23 at device 29.0 on pci0 > uhci3: [ITHREAD] > usbus5: on uhci3 > uhci4: port 0xfb00-0xfb1f irq > 19 at device 29.1 on pci0 > uhci4: [ITHREAD] > usbus6: on uhci4 > uhci5: port 0xfa00-0xfa1f irq > 18 at device 29.2 on pci0 > uhci5: [ITHREAD] > usbus7: on uhci5 > ehci1: mem > 0xfbffd000-0xfbffd3ff irq 23 at device 29.7 on pci0 > ehci1: [ITHREAD] > usbus8: EHCI version 1.0 > usbus8: on ehci1 > pcib10: at device 30.0 on pci0 > pci10: on pcib10 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci1: port > 0xf900-0xf907,0xf800-0xf803,0xf700-0xf707,0xf600-0xf603,0xf500-0xf51f mem > 0xfbffc000-0xfbffc7ff irq 19 at device 31.2 on pci0 > ahci1: [ITHREAD] > ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported > ahcich8: at channel 0 on ahci1 > ahcich8: [ITHREAD] > ahcich9: at channel 1 on ahci1 > ahcich9: [ITHREAD] > ahcich10: at channel 2 on ahci1 > ahcich10: [ITHREAD] > ahcich11: at channel 3 on ahci1 > ahcich11: [ITHREAD] > ahcich12: at channel 4 on ahci1 > ahcich12: [ITHREAD] > ahcich13: at channel 5 on ahci1 > ahcich13: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_hpet0: iomem 0xfed00000-0xfed003ff irq > 0,8 on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > atrtc0: port 0x70-0x73 on acpi0 > qpi0: on motherboard > orm0: at iomem 0xc0000-0xcffff,0xdb000-0xdbfff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > coretemp0: on cpu0 > est0: on cpu0 > p4tcc0: on cpu0 > coretemp1: on cpu1 > est1: on cpu1 > p4tcc1: on cpu1 > coretemp2: on cpu2 > est2: on cpu2 > p4tcc2: on cpu2 > coretemp3: on cpu3 > est3: on cpu3 > p4tcc3: on cpu3 > coretemp4: on cpu4 > est4: on cpu4 > p4tcc4: on cpu4 > coretemp5: on cpu5 > est5: on cpu5 > p4tcc5: on cpu5 > coretemp6: on cpu6 > est6: on cpu6 > p4tcc6: on cpu6 > coretemp7: on cpu7 > est7: on cpu7 > p4tcc7: on cpu7 > Timecounters tick every 1.000 msec > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 12Mbps Full Speed USB v1.0 > usbus8: 480Mbps High Speed USB v2.0 > ugen0.1: <0x1033> at usbus0 > uhub0: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ugen8.1: at usbus8 > uhub8: on usbus8 > uhub0: 4 ports with 4 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > uhub7: 2 ports with 2 removable, self powered > uhub4: 6 ports with 6 removable, self powered > uhub8: 6 ports with 6 removable, self powered > ugen1.2: at usbus1 > ums0: rev 1.10/3.00, addr 2> on usbus1 > ums0: 3 buttons and [XYZ] coordinates ID=0 > ugen2.2: at usbus2 > ukbd0: on usbus2 > ugen3.2: at usbus3 > kbd2 at ukbd0 > uhid0: on usbus2 > ahcich7: Poll timeout on slot 0 port 0 > ahcich7: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd 50 serr > 00000000 cmd 10004016 > ada0 at ahcich8 bus 0 scbus11 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) > ada1 at ahcich9 bus 0 scbus12 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C) > ada2 at ahcich10 bus 0 scbus13 target 0 lun 0 > ada2: ATA-8 SATA 3.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada3 at ahcich11 bus 0 scbus14 target 0 lun 0 > ada3: ATA-8 SATA 3.x device > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada3: Command Queueing enabled > ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > da0 at arcmsr0 bus 0 scbus8 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: Command Queueing enabled > da0: 953869MB (1953523712 512 byte sectors: 255H 63S/T 121601C) > da1 at mps0 bus 0 scbus9 target 0 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da2 at mps0 bus 0 scbus9 target 1 lun 0 > da2: Fixed Direct Access SCSI-5 device > da2: 300.000MB/s transfers > da2: Command Queueing enabled > da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da3 at mps0 bus 0 scbus9 target 2 lun 0 > da3: Fixed Direct Access SCSI-5 device > da3: 300.000MB/s transfers > da3: Command Queueing enabled > da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da4 at mps0 bus 0 scbus9 target 3 lun 0 > da4: Fixed Direct Access SCSI-5 device > da4: 300.000MB/s transfers > da4: Command Queueing enabled > da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da5 at mps1 bus 0 scbus10 target 0 lun 0 > da5: Fixed Direct Access SCSI-6 device > da5: 300.000MB/s transfers > da5: Command Queueing enabled > da5: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da6 at mps1 bus 0 scbus10 target 1 lun 0 > da6: Fixed Direct Access SCSI-6 device > da6: 300.000MB/s transfers > da6: Command Queueing enabled > da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da7 at mps1 bus 0 scbus10 target 2 lun 0 > da7: Fixed Direct Access SCSI-6 device > da7: 300.000MB/s transfers > da7: Command Queueing enabled > da7: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da8 at mps1 bus 0 scbus10 target 3 lun 0 > da8: Fixed Direct Access SCSI-6 device > da8: 300.000MB/s transfers > da8: Command Queueing enabled > da8: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da9 at mps1 bus 0 scbus10 target 6 lun 0 > da9: Fixed Direct Access SCSI-6 device > da9: 600.000MB/s transfers > da9: Command Queueing enabled > da9: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da10 at mps1 bus 0 scbus10 target 7 lun 0 > da10: Fixed Direct Access SCSI-6 device > da10: 300.000MB/s transfers > da10: Command Queueing enabled > da10: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > pass1 at arcmsr0 bus 0 scbus8 target 16 lun 0 > pass1: Fixed Processor SCSI-0 device > SMP: AP CPU #1 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #6 Launched! > Trying to mount root from ufs:/dev/da0p3 > ZFS filesystem version 5 > ZFS storage pool version 28 > ugen2.2: at usbus2 (disconnected) > ukbd0: at uhub2, port 1, addr 2 (disconnected) > uhid0: at uhub2, port 1, addr 2 (disconnected) > ugen2.2: at usbus2 > ukbd0: on usbus2 > kbd2 at ukbd0 > uhid0: on usbus2 > (da7:mps1:0:2:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da7:mps1:0:2:0): CAM status: SCSI Status Error > (da7:mps1:0:2:0): SCSI status: Check Condition > (da7:mps1:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or > bus device reset occurred) > (da5:mps1:0:0:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da5:mps1:0:0:0): CAM status: SCSI Status Error > (da5:mps1:0:0:0): SCSI status: Check Condition > (da5:mps1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or > bus device reset occurred) > (da9:mps1:0:6:0): READ(10). CDB: 28 0 3 33 c6 f5 0 0 1 0 > (da9:mps1:0:6:0): CAM status: SCSI Status Error > (da9:mps1:0:6:0): SCSI status: Check Condition > (da9:mps1:0:6:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or > bus device reset occurred) > (da8:mps1:0:3:0): READ(10). CDB: 28 0 4 97 a a3 0 0 1 0 > (da8:mps1:0:3:0): CAM status: SCSI Status Error > (da8:mps1:0:3:0): SCSI status: Check Condition > (da8:mps1:0:3:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or > bus device reset occurred) > pid 2395 (akonadiserver), uid 128: exited on signal 11 (core dumped) > pid 2492 (akonadiserver), uid 128: exited on signal 11 (core dumped) > pid 2494 (akonadiserver), uid 128: exited on signal 11 (core dumped) > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 21:16:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1931106571B for ; Mon, 21 Nov 2011 21:16:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF298FC1A for ; Mon, 21 Nov 2011 21:16:40 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so4574855vbb.13 for ; Mon, 21 Nov 2011 13:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3ivs5+t7sDYmmCuwlLkY2MPzPue4P1/zG/unnLwUbRk=; b=Ub0LUYhgCBEpwwecveJ3H2j//n/V3LwjDwXpyAWmLZyX3vm8ysAeXFsq+WTDAhTQ6e Jn1qYXpY1IDbUvS2cCQ0ndqgswCgpCrb4+wvey4i9qME9sSaPWd7Fj/ko2Hi1MnUgQAk aTPsUPHIuk3I8qjvTs2TCeJR55wN6EtNSiX2A= MIME-Version: 1.0 Received: by 10.52.95.34 with SMTP id dh2mr17376420vdb.12.1321910198557; Mon, 21 Nov 2011 13:16:38 -0800 (PST) Received: by 10.220.190.71 with HTTP; Mon, 21 Nov 2011 13:16:38 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Nov 2011 13:16:38 -0800 Message-ID: From: Freddie Cash To: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: [zfs-discuss] early save the date: What's New and What's Coming in ZFS for illumos, Jan 10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:16:41 -0000 For those who've been wondering about future plans for the open-source version of ZFS. ---------- Forwarded message ---------- From: Deirdre Straughan Date: Mon, Nov 21, 2011 at 12:03 PM Subject: [zfs-discuss] early save the date: What's New and What's Coming in ZFS for illumos, Jan 10 To: zfs-discuss@opensolaris.org Sign up at: http://www.meetup.com/illumos-User-Group/events/41665962/ January's meeting of the Bay Area illumos user group (formerly SFOSUG and SVOSUG) will feature a report from Matt Ahrens of the ZFS Working Group about what's new and what's coming in ZFS, with time for discussion about other topics of interest to the community. Pizza and beer (and soft drinks) will be provided. Note: The following meetup will be at Joyent's San Francisco office; we'll switch locations between the city and the Valley to spread the commute burden. Frequency of meetings TBD. Yes, we'll try to stream it and definitely record it. -- best regards, Deirdr=C3=A9 Straughan SmartOS Community Manager Joyent cell 720 371 4107 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Mon Nov 21 23:16:14 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37909106564A; Mon, 21 Nov 2011 23:16:14 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5638FC0A; Mon, 21 Nov 2011 23:16:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pALNGDg5029380; Mon, 21 Nov 2011 23:16:13 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pALNGDpK029376; Mon, 21 Nov 2011 23:16:13 GMT (envelope-from arundel) Date: Mon, 21 Nov 2011 23:16:13 GMT Message-Id: <201111212316.pALNGDpK029376@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-fs@FreeBSD.org, alc@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/152488: [tmpfs] [patch] mtime of file updated when only inode changed (file data not changed) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 23:16:14 -0000 Synopsis: [tmpfs] [patch] mtime of file updated when only inode changed (file data not changed) Responsible-Changed-From-To: freebsd-fs->alc Responsible-Changed-By: arundel Responsible-Changed-When: Mon Nov 21 23:15:53 UTC 2011 Responsible-Changed-Why: Over to Alan as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=152488 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 00:07:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDE5106566B for ; Tue, 22 Nov 2011 00:07:41 +0000 (UTC) (envelope-from ian@ndwns.net) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by mx1.freebsd.org (Postfix) with ESMTP id 88D9B8FC08 for ; Tue, 22 Nov 2011 00:07:41 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 3CF04594012 for ; Mon, 21 Nov 2011 16:07:23 -0800 (PST) Received: from localhost (c-76-126-116-195.hsd1.ca.comcast.net [76.126.116.195]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtpauth.rollernet.us (Postfix) with ESMTPSA for ; Mon, 21 Nov 2011 16:07:22 -0800 (PST) Date: Mon, 21 Nov 2011 16:07:26 -0800 From: Ian Downes To: freebsd-fs@freebsd.org Message-ID: <20111122000726.GA46653@weta.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://www.rollernet.us/policy X-Rollernet-Submit: Submit ID 7eef.4ecae7ba.e6797.0 Subject: tune ZFS for fast clone and creation? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 00:07:41 -0000 Hello, I know ZFS is already 'fast' with COW clones etc., but can ZFS be tuned for faster clone and creation? The fast random access of a SSD helps but what other options are there? Tuning caches? Different zpool layouts? ...? I haven't been able to find any info so any suggestions would be welcome! some basic experiments: zpool with a single 500 GB 7200 rpm consumer HDD zpool with a single 64 GB consumer SSD zfs create: 250 ms on HDD 110 ms on SSD zfs clone: (about 1 GB of mixed size) 250 ms on HDD 85 ms on SSD From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 00:40:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BE51065672 for ; Tue, 22 Nov 2011 00:40:19 +0000 (UTC) (envelope-from lars@w9zeb.org) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5735E8FC13 for ; Tue, 22 Nov 2011 00:40:19 +0000 (UTC) Received: by ywe9 with SMTP id 9so7606936ywe.13 for ; Mon, 21 Nov 2011 16:40:18 -0800 (PST) Received: by 10.236.78.229 with SMTP id g65mr24162491yhe.4.1321920711713; Mon, 21 Nov 2011 16:11:51 -0800 (PST) Received: from [192.168.11.53] (c-98-220-172-7.hsd1.in.comcast.net. [98.220.172.7]) by mx.google.com with ESMTPS id 4sm33870380ano.9.2011.11.21.16.11.49 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 16:11:50 -0800 (PST) Message-ID: <4ECAE8C0.7080306@w9zeb.org> Date: Mon, 21 Nov 2011 19:11:44 -0500 From: "Lars R. Noldan" User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20111003 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20111122000726.GA46653@weta.local> In-Reply-To: <20111122000726.GA46653@weta.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: tune ZFS for fast clone and creation? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 00:40:19 -0000 On 11/21/11 07:07 PM, Ian Downes wrote: > Hello, > > I know ZFS is already 'fast' with COW clones etc., but can ZFS be tuned > for faster clone and creation? The fast random access of a SSD helps but > what other options are there? Tuning caches? Different zpool layouts? > ...? > > I haven't been able to find any info so any suggestions would be > welcome! > > some basic experiments: > > zpool with a single 500 GB 7200 rpm consumer HDD > zpool with a single 64 GB consumer SSD > > zfs create: > 250 ms on HDD > 110 ms on SSD > > zfs clone: (about 1 GB of mixed size) > 250 ms on HDD > 85 ms on SSD > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Hello Ian, Our storage configuration has 7 spindles in a RaidZ2, 2 SSDs as a ZFS mirrored ZIL, and 2 SSDs as a zfs L2ARC cache. Adding a fast ZIL and L2ARC certainly won't hurt your performance. If that L2ARC was something like a Fusion-IO it'd be faster still I imagine. Lars From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 11:09:42 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDCD106564A; Tue, 22 Nov 2011 11:09:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 172C38FC0C; Tue, 22 Nov 2011 11:09:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMB9f7s023934; Tue, 22 Nov 2011 11:09:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAMB9fWZ023930; Tue, 22 Nov 2011 11:09:41 GMT (envelope-from linimon) Date: Tue, 22 Nov 2011 11:09:41 GMT Message-Id: <201111221109.pAMB9fWZ023930@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162751: [zfs] [panic] kernel panics during file operations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 11:09:42 -0000 Synopsis: [zfs] [panic] kernel panics during file operations Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 22 11:09:33 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=162751 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 13:30:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621A51065674 for ; Tue, 22 Nov 2011 13:30:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 34B298FC1F for ; Tue, 22 Nov 2011 13:30:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id E0EB846B42; Tue, 22 Nov 2011 08:30:05 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 66495B921; Tue, 22 Nov 2011 08:30:05 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 22 Nov 2011 08:19:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <1321858172.48792.12.camel@shadenet.roycs.nl> In-Reply-To: <1321858172.48792.12.camel@shadenet.roycs.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111220819.49067.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 22 Nov 2011 08:30:05 -0500 (EST) Cc: Roy Stuivenberg Subject: Re: kernel: deget(): pcbmap returned 6 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 13:30:06 -0000 On Monday, November 21, 2011 1:49:32 am Roy Stuivenberg wrote: > Hello, > > I'm running FreeBSD 8.2 stable amd64 > > uname -a : > FreeBSD shadenet.roycs.nl 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Nov 17 > 16:54:43 CET 2011 > dhondub@shadenet.roycs.nl:/usr/obj/usr/src/sys/GENERIC-ROYCS amd64 > > I found this error msg in tail -f /var/log/messages > > kernel: deget(): pcbmap returned 6 [ Moving to freebsd-fs@] This is from a printf in msdosfs. I'm not sure what it means, but I've moved the e-mail to fs@ in case someone there knows. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 16:20:03 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A60A01065678 for ; Tue, 22 Nov 2011 16:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 925E58FC12 for ; Tue, 22 Nov 2011 16:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMGK3Tu013796 for ; Tue, 22 Nov 2011 16:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAMGK3jG013795; Tue, 22 Nov 2011 16:20:03 GMT (envelope-from gnats) Date: Tue, 22 Nov 2011 16:20:03 GMT Message-Id: <201111221620.pAMGK3jG013795@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159418: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 16:20:03 -0000 The following reply was made to PR kern/159418; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159418: commit references a PR Date: Tue, 22 Nov 2011 16:18:26 +0000 (UTC) Author: ivoras Date: Tue Nov 22 16:18:12 2011 New Revision: 227822 URL: http://svn.freebsd.org/changeset/base/227822 Log: Avoid panics from recursive rename operations. Not a perfect patch but good enough for now. PR: kern/159418 Submitted by: Gleb Kurtsou Reviewed by: kib MFC after: 1 month Modified: head/sys/fs/tmpfs/tmpfs_vnops.c Modified: head/sys/fs/tmpfs/tmpfs_vnops.c ============================================================================== --- head/sys/fs/tmpfs/tmpfs_vnops.c Tue Nov 22 16:08:12 2011 (r227821) +++ head/sys/fs/tmpfs/tmpfs_vnops.c Tue Nov 22 16:18:12 2011 (r227822) @@ -965,11 +965,8 @@ tmpfs_rename(struct vop_rename_args *v) /* If we need to move the directory between entries, lock the * source so that we can safely operate on it. */ - if (tdvp != fdvp) { - error = vn_lock(fdvp, LK_EXCLUSIVE | LK_RETRY); - if (error != 0) - goto out; - } + if (fdvp != tdvp && fdvp != tvp) + vn_lock(fdvp, LK_EXCLUSIVE | LK_RETRY); fdnode = VP_TO_TMPFS_DIR(fdvp); fnode = VP_TO_TMPFS_NODE(fvp); de = tmpfs_dir_lookup(fdnode, fnode, fcnp); @@ -1143,7 +1140,7 @@ tmpfs_rename(struct vop_rename_args *v) error = 0; out_locked: - if (fdnode != tdnode) + if (fdvp != tdvp && fdvp != tvp) VOP_UNLOCK(fdvp, 0); out: _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 16:35:47 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77663106566C; Tue, 22 Nov 2011 16:35:47 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBA38FC0C; Tue, 22 Nov 2011 16:35:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMGZlAE032346; Tue, 22 Nov 2011 16:35:47 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAMGZkpr032342; Tue, 22 Nov 2011 16:35:46 GMT (envelope-from rmacklem) Date: Tue, 22 Nov 2011 16:35:46 GMT Message-Id: <201111221635.pAMGZkpr032342@freefall.freebsd.org> To: george@polarismail.com, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/161493: [nfs] NFS v3 directory structure update slow X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 16:35:47 -0000 Synopsis: [nfs] NFS v3 directory structure update slow State-Changed-From-To: open->closed State-Changed-By: rmacklem State-Changed-When: Tue Nov 22 16:34:34 UTC 2011 State-Changed-Why: I believe this problem was fixed by r225536. The person that reported it will know after they have upgraded to 9.0-release. http://www.freebsd.org/cgi/query-pr.cgi?pr=161493 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 16:37:22 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A331065675; Tue, 22 Nov 2011 16:37:22 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 19F1C8FC18; Tue, 22 Nov 2011 16:37:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMGbL0E032473; Tue, 22 Nov 2011 16:37:21 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAMGbLnM032469; Tue, 22 Nov 2011 16:37:21 GMT (envelope-from rmacklem) Date: Tue, 22 Nov 2011 16:37:21 GMT Message-Id: <201111221637.pAMGbLnM032469@freefall.freebsd.org> To: walter@pelissero.de, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/148204: [nfs] UDP NFS causes overload X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 16:37:22 -0000 Synopsis: [nfs] UDP NFS causes overload State-Changed-From-To: open->feedback State-Changed-By: rmacklem State-Changed-When: Tue Nov 22 16:36:09 UTC 2011 State-Changed-Why: I believe this problem might have been fixed by r225234. I have asked the person that reported it to try and test a post-r225234 system in order to find out. http://www.freebsd.org/cgi/query-pr.cgi?pr=148204 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 17:06:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90889106566B; Tue, 22 Nov 2011 17:06:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 168938FC0C; Tue, 22 Nov 2011 17:06:17 +0000 (UTC) Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAMH6CUK019227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Nov 2011 04:06:15 +1100 Date: Wed, 23 Nov 2011 04:06:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <201111220819.49067.jhb@freebsd.org> Message-ID: <20111123035718.I10311@besplex.bde.org> References: <1321858172.48792.12.camel@shadenet.roycs.nl> <201111220819.49067.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Roy Stuivenberg Subject: Re: kernel: deget(): pcbmap returned 6 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 17:06:18 -0000 On Tue, 22 Nov 2011, John Baldwin wrote: > On Monday, November 21, 2011 1:49:32 am Roy Stuivenberg wrote: >> Hello, >> >> I'm running FreeBSD 8.2 stable amd64 >> >> uname -a : >> FreeBSD shadenet.roycs.nl 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Nov 17 >> 16:54:43 CET 2011 >> dhondub@shadenet.roycs.nl:/usr/obj/usr/src/sys/GENERIC-ROYCS amd64 >> >> I found this error msg in tail -f /var/log/messages >> >> kernel: deget(): pcbmap returned 6 > > [ Moving to freebsd-fs@] > > This is from a printf in msdosfs. I'm not sure what it means, but I've moved > the e-mail to fs@ in case someone there knows. kib@ just ifdefed it out, so we will never know :-). 6 is ENXIO, which is bogus unless the device went away. It can only be returned from pcbmap() for a bread() failure. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 18:06:08 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09595106564A; Tue, 22 Nov 2011 18:06:08 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5F278FC20; Tue, 22 Nov 2011 18:06:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAMI67ET013007; Tue, 22 Nov 2011 18:06:07 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAMI67hi013003; Tue, 22 Nov 2011 18:06:07 GMT (envelope-from jh) Date: Tue, 22 Nov 2011 18:06:07 GMT Message-Id: <201111221806.pAMI67hi013003@freefall.freebsd.org> To: pgollucci@FreeBSD.org, jh@FreeBSD.org, freebsd-fs@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: kern/155411: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 18:06:08 -0000 Synopsis: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device State-Changed-From-To: open->feedback State-Changed-By: jh State-Changed-When: Tue Nov 22 18:04:58 UTC 2011 State-Changed-Why: Do you still see the problem after r227802? http://www.freebsd.org/cgi/query-pr.cgi?pr=155411 From owner-freebsd-fs@FreeBSD.ORG Tue Nov 22 22:25:38 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E15B0106566C for ; Tue, 22 Nov 2011 22:25:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBE58FC1A for ; Tue, 22 Nov 2011 22:25:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA25296; Wed, 23 Nov 2011 00:25:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RSymU-0003cw-7R; Wed, 23 Nov 2011 00:25:34 +0200 Message-ID: <4ECC215D.8000905@FreeBSD.org> Date: Wed, 23 Nov 2011 00:25:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> <20111121201332.03ecadf1@naclador.mos32.de> In-Reply-To: <20111121201332.03ecadf1@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 22:25:38 -0000 on 21/11/2011 21:13 Florian Wagner said the following: > On Mon, 21 Nov 2011 12:53:49 +0200 > Andriy Gapon wrote: > >> Why did you have to specify MACHINE_CPUARCH? >> Is your OS amd64 or i386?MACHINE_CPUARCH? > > Otherwise I get: > > # make > "Makefile", line 22: Malformed conditional (${MACHINE_CPUARCH} == "amd64") > "Makefile", line 27: if-less endif > make: fatal errors encountered -- cannot continue > > Looking at share/mk/sys.mk in both stable-8 and head I see that > MACHINE_CPUARCH is only defined in head. I see. You still haven't said if your system is really amd64. But that's not terribly important. [snip] >> Here is the latest version from my tree: >> https://gitorious.org/~avg/freebsd/avgbsd/trees/devel-20110921/tools/tools/zfsboottest > > This one compiles and combined with zfsboottest.sh from head... > > 1. # ./zfsboottest.sh root > The "mountpoint" property of dataset "root/stable-8-r226381" should be set to "legacy". > > The bootloader from stable-8 didn't seem to care that the mountpoint > was set to none, but to get further with zfsboottest I set it to > legacy. The boot loader still doesn't care, neither does zfsboottest program, which you can execute directly. The zfsboottest.sh test script does some extra checks to ensure trouble-free booting and mounting of the root fs. > 2. # ./zfsboottest.sh root > zfsboottest.sh is reading all the files in //boot using > boot code and using file system code. > It calculates MD5 checksums for all the files and will compare them. > If all files can be properly read using boot code, it is very likely you > will be able to boot from "root" pool>:> Good luck! > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS > pool: root > config: > > NAME STATE > root ONLINE > raidz2 ONLINE > gptid/fe19a168-12e0-11e1-9070-deadbeef1028 ONLINE > gptid/fe62ed10-12e0-11e1-9070-deadbeef1028 ONLINE > gptid/fc93472b-12e0-11e1-9070-deadbeef1028 ONLINE > gptid/fd8b167c-12e0-11e1-9070-deadbeef1028 ONLINE > > Then it just hangs there. I've let it run for a few minutes, but > even in a VM with emulated IDE controller the 11MB of files in /boot > shouldn't take very long. > > On repeated runs the "ZFS: i/o error" and "can't read MOS" sometimes > are there and sometimes they are not. > > 3. Rebuilt zfsboottest with -g -O0 and ran it in gdb with my vdev > devices and one single file. I've attached a gdb session but haven't > gotten very far. My C debugging-fu is rather weak ;). > > The SIGFPE from zfsboottest.gdb.log.2 is not easily reproduced... Unfortunately the logs that you captured do not reveal a source of the problem. I think that it would make sense to set a breakpoint at the zfs_mount function ('b zfs_mount'). When the program stops at a break point, you can then 'step' through the code. Then examine all arguments upon function calls and local variables at the interesting places. For variables that are pointers please print their dereferenced value (like 'p *x'). This could be time consuming. Some more straightforward things to (re-)test. First, are you absolutely sure that the problem never happens without the patch? Could you please retest that? Please do not touch anything under /boot, just recompile zfsboottest with the patch reverted and run it a few time. Then, could you please test the patch with the code from head? Again, no need to change you real boot blocks, just checkout sys/boot from head, patch it, recompile zfsboottest and test it. I hope that we will be able to find the root cause. Thank you! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 08:45:17 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B82F106566B; Wed, 23 Nov 2011 08:45:17 +0000 (UTC) (envelope-from walter.pelissero@iesy.net) Received: from mail01.ish.de (mailout.ish.de [80.69.98.248]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9B08FC0C; Wed, 23 Nov 2011 08:45:15 +0000 (UTC) Received: from [94.79.129.6] (account walter.pelissero@iesy.net HELO scylla.home.lan) by mail-fe-02.mail01.ish.de (CommuniGate Pro SMTP 5.3.13) with ESMTPSA id 500534392; Wed, 23 Nov 2011 09:35:13 +0100 Received: from scylla.home.lan (localhost [127.0.0.1]) by scylla.home.lan (8.14.5/8.14.5) with ESMTP id pAN8ZBpQ004066; Wed, 23 Nov 2011 09:35:11 +0100 (CET) (envelope-from wcp@scylla.home.lan) Received: (from wcp@localhost) by scylla.home.lan (8.14.5/8.14.5/Submit) id pAN8ZBdV004065; Wed, 23 Nov 2011 09:35:11 +0100 (CET) (envelope-from wcp) From: walter@pelissero.de (Walter C. Pelissero) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20172.45119.388882.584514@scylla.home.lan> Date: Wed, 23 Nov 2011 09:35:11 +0100 To: rmacklem@FreeBSD.org In-Reply-To: <201111221637.pAMGbLnM032469@freefall.freebsd.org> References: <201111221637.pAMGbLnM032469@freefall.freebsd.org> X-Mailer: VM 8.1.1 under 23.3.1 (amd64-portbld-freebsd8.2) X-Attribution: WP X-For-Spammers: blacklistme@pelissero.de X-MArch-Archive-ID: 151912 X-MArch-Processing-Time: 0.243s Cc: freebsd-fs@FreeBSD.org Subject: Re: kern/148204: [nfs] UDP NFS causes overload X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: walter@pelissero.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 08:45:17 -0000 rmacklem@FreeBSD.org writes: > I believe this problem might have been fixed by r225234. I can't reproduce the problem on FreeBSD scylla.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Oct 5 15:42:40 CEST 2011 root@scylla.home.lan:/usr/obj/usr/src/sys/GA870AUD3 amd64 -- http://pelissero.de From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 15:50:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 735C8106566B for ; Wed, 23 Nov 2011 15:50:40 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F33418FC0A for ; Wed, 23 Nov 2011 15:50:39 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RTF5o-00038U-Vu for freebsd-fs@freebsd.org; Wed, 23 Nov 2011 16:50:37 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Nov 2011 16:50:36 +0100 Received: from johannes by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Nov 2011 16:50:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Wed, 23 Nov 2011 15:50:17 +0000 Lines: 62 Message-ID: References: <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <89025E71-B020-406A-BA58-BAF6529974A1@irbisnet.com> Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 15:50:40 -0000 On 12/11/2011 15:21, Andriy Bakay wrote: > On 2011-11-11, at 11:36 , Johannes Totz wrote: > >> Hi, >> >> To back up a zfs dataset there are a few possibilities: >> 1) rsync file data to another machine >> 2) zfs-send to another machine, into a zfs dataset >> 3) zfs-send to another machine, dumping the stream to a file >> >> The first one works alright but you loose admin info, properties >> seton the dataset, etc >> The second is prefered but requires another machine which runs >> zfs. The third is bad. >> >> So far I have been doing (3), for daily short-term backups, works, >> tested, everything is peachy. However, I dont like it anymore for >> obvious reasons. Ideally, I would like to go with (2). But I dont have >> another zfs-capable machine, or the machine that I would like to backup >> onto will not ever run zfs. >> >> So I came up with another crazy idea, assuming the remote machine >> exports a block device (somehow): >> 4) zpool-attach the remote block dev as a mirror, let it resilver, >> offline it during the day, at night online it, resilver, and so on >> 5) create a pool on the block dev locally on the >> to-be-backed-up-machine and periodically zfs-send stuff over >> >> I would go for (4), it seems to be the mostly automatic. >> Any thoughts on this? >> Should I expect things to go titsup if there's network issues? As Xin mentioned, (4) is not a good idea. Onlining a device starts a resilver from scratch. This is not incremental, i.e. not suited for a nightly backup thing. > > I am using the following schema: sparse file + GGATE + GELI + ZFS. > The destination (remote) machine export/share sparse file through > GGATE. The source/local machine attach GGATE block device, encrypted > with GELI and on top of it create "local" ZFS pool. You can skip GELI > and/or instead sparse file you can use any block device. In this > scenario destination/remote machine does not even know what inside > that sparse file and does not need to support ZFS. You could > periodically attach GGATE/GELI, import ZFS pool and > zfs-send/zfs-receive snapshot(s). This is quite similar to (5) above, and is what I'm going to do. Thanks to you and Xin for suggestions! > > NOTE: GELI will provide storage security, but I am not sure will it > be secure in terms of transmission. Basically you need to make sure > your GGATE layer go through secure/trusted (VPN, SSH tunnel, trusted > LAN) link. > > You could mirror to remote GGATE devices, but it could lead to some > problems (try to search it in mailing list). In this case I recommend > you to consider HAST. From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 16:09:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E709C106564A; Wed, 23 Nov 2011 16:09:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3761D8FC08; Wed, 23 Nov 2011 16:09:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAG4azU6DaFvO/2dsb2JhbABDhQGmcIFyAQEFI1YbGAICDRkCWRmqa5FrgTCCL4NugX+BFgSIIIwokig X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="145179878" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 23 Nov 2011 11:09:33 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5D4E4B3F21; Wed, 23 Nov 2011 11:09:33 -0500 (EST) Date: Wed, 23 Nov 2011 11:09:33 -0500 (EST) From: Rick Macklem To: walter@pelissero.de Message-ID: <334284849.224232.1322064573365.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20172.45119.388882.584514@scylla.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, rmacklem@FreeBSD.org Subject: Re: kern/148204: [nfs] UDP NFS causes overload X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 16:09:35 -0000 Walter Pelissero wrote: > rmacklem@FreeBSD.org writes: > > I believe this problem might have been fixed by r225234. > > I can't reproduce the problem on > FreeBSD scylla.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #1: Wed Oct 5 > 15:42:40 CEST 2011 root@scylla.home.lan:/usr/obj/usr/src/sys/GA870AUD3 > amd64 > Ok, thanks for the feedback. I'll close the PR. rick > -- > http://pelissero.de From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 16:14:03 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C076106566B; Wed, 23 Nov 2011 16:14:03 +0000 (UTC) (envelope-from rmacklem@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D82288FC16; Wed, 23 Nov 2011 16:14:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pANGE2UE078793; Wed, 23 Nov 2011 16:14:02 GMT (envelope-from rmacklem@freefall.freebsd.org) Received: (from rmacklem@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pANGE24j078788; Wed, 23 Nov 2011 16:14:02 GMT (envelope-from rmacklem) Date: Wed, 23 Nov 2011 16:14:02 GMT Message-Id: <201111231614.pANGE24j078788@freefall.freebsd.org> To: walter@pelissero.de, rmacklem@FreeBSD.org, freebsd-fs@FreeBSD.org From: rmacklem@FreeBSD.org Cc: Subject: Re: kern/148204: [nfs] UDP NFS causes overload X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 16:14:03 -0000 Synopsis: [nfs] UDP NFS causes overload State-Changed-From-To: feedback->closed State-Changed-By: rmacklem State-Changed-When: Wed Nov 23 16:12:35 UTC 2011 State-Changed-Why: Walter reported back that he cannot reproduce the problem with a post r225234 stable/8 kernel, so I believe that the problem is resolved. http://www.freebsd.org/cgi/query-pr.cgi?pr=148204 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 19:00:31 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7816106564A for ; Wed, 23 Nov 2011 19:00:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE0F8FC0C for ; Wed, 23 Nov 2011 19:00:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 01FA84AC1C for ; Wed, 23 Nov 2011 23:00:29 +0400 (MSK) Date: Wed, 23 Nov 2011 23:00:26 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1957615267.20111123230026@serebryakov.spb.ru> To: freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:00:31 -0000 Hello, Freebsd-fs. Does UFS2 with softupdates (without journal) issues BIO_FLUSH to GEOM layer when it need to ensure consistency on on-disk metadata? Does UFS2 with SU+J issues this command? geom_raid5 respects this command, but when write log is enabled, it produces tons of "Unexpected softupate inconsistency" errors on crash. It seems, that there is no BIO_FLUSH and writes, which should be synchronous (metadata updates) isn't :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 19:44:49 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91D52106564A; Wed, 23 Nov 2011 19:44:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E9A678FC0A; Wed, 23 Nov 2011 19:44:48 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pANJii3c030543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Nov 2011 21:44:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pANJii9k045410; Wed, 23 Nov 2011 21:44:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pANJiiY3045409; Wed, 23 Nov 2011 21:44:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Nov 2011 21:44:44 +0200 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rzUde4Gex/lOR0Yy" Content-Disposition: inline In-Reply-To: <1957615267.20111123230026@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:44:49 -0000 --rzUde4Gex/lOR0Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2011 at 11:00:26PM +0400, Lev Serebryakov wrote: > Hello, Freebsd-fs. >=20 > Does UFS2 with softupdates (without journal) issues BIO_FLUSH to > GEOM layer when it need to ensure consistency on on-disk metadata? No. Softupdates do not need flushes. Read about SU in the design and implementation, or standalone article about it. >=20 > Does UFS2 with SU+J issues this command? Again, no. >=20 > geom_raid5 respects this command, but when write log is enabled, it > produces tons of "Unexpected softupate inconsistency" errors on crash. > It seems, that there is no BIO_FLUSH and writes, which should be > synchronous (metadata updates) isn't :( You are making wrong conclusions from the false assumptions. The only requirement of the SU is that writes reported as done by disk driver are indeed safely landed in the involatile storage. --rzUde4Gex/lOR0Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7NTSwACgkQC3+MBN1Mb4i44QCbBgbyz0wpxZ2lGj09UAnpX0Ei rWQAoKSRyUstDNyjTDe9MCp+ogyln8pR =OTx7 -----END PGP SIGNATURE----- --rzUde4Gex/lOR0Yy-- From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 20:04:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CA271065673 for ; Wed, 23 Nov 2011 20:04:20 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3DB8FC17 for ; Wed, 23 Nov 2011 20:04:20 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 962844AC31; Thu, 24 Nov 2011 00:04:18 +0400 (MSK) Date: Thu, 24 Nov 2011 00:04:14 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1391930411.20111124000414@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 20:04:20 -0000 Hello, Kostik. You wrote 23 =ED=EE=FF=E1=F0=FF 2011 =E3., 23:44:44: >> Does UFS2 with softupdates (without journal) issues BIO_FLUSH to >> GEOM layer when it need to ensure consistency on on-disk metadata? > No. Softupdates do not need flushes. It need flushes. Because WITHOUT flashes on modern storage architectures there is no way to be sure, that (I'm quoting your last sentence) "writes reported as done by disk driver are indeed safely landed in the involatile storage." It is sad, but it is true. Disk controllers have caches, disks have caches. In virtual environment and with NAS (iSCSIS/FC/Whatever) everything is even worse. And every layer LAYS about "landing", it was shown, for example, by Brad Fitzpatrick many years ago (http://brad.livejou= rnal.com/2116715.html). If SU don't mark its writes in special way as strictly-synchronous, SU could not be sure, that data is really LANDED when bio is marked as complete one. As far as I understand, there is no such way to mark bio with BIO_WRITE command as such special case, and only way to ensure landing is to call BIO_FLUSH after BIO_WRITE. > You are making wrong conclusions from the false assumptions. > The only requirement of the SU is that writes reported as done by disk > driver are indeed safely landed in the involatile storage. See above. Only BIO_FLUSH could give some (but, again, not 100%, but "best effort") guarantee, that completed BIO_WRITE is really landed. Data could be queued on many layers, and without explicit FLUSH it could not be really written for seconds or even minutes (but reported as so). For example, for RAID5 descent performance it is vital to have some write cache. And when it is software implementation, UPS could not help from system panics. So, it is very sad, that SU and SU+J don't epress their requirements via code! It seems, that even SU+J will not help from crashes in case when some GEOM does write caching. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 22:21:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E1B7106564A; Wed, 23 Nov 2011 22:21:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C23DC8FC0A; Wed, 23 Nov 2011 22:21:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D5DF04AC1C; Thu, 24 Nov 2011 02:21:49 +0400 (MSK) Date: Thu, 24 Nov 2011 02:21:45 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <337241442.20111124022145@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 22:21:52 -0000 Hello, Kostik. You wrote 23 =ED=EE=FF=E1=F0=FF 2011 =E3., 23:44:44: > You are making wrong conclusions from the false assumptions. It seems to me, that FFS2/SU and SUJ are built on wrong assumption, that complete bwrite() without ASYNC flag really means landed data on physical device in any case. It is completely wrong, non-reliable, and prevents from building reliable AND high-performance storage on FreeBSD :( Or, may be, I understand code wrong. It is possible. See below. > The only requirement of the SU is that writes reported as done by disk > driver are indeed safely landed in the involatile storage. I've traced code and found next call chain. Please, correct me if I'm wrong. Softupdates writes all data via bwrite() or bawrite(). bawrite() is Ok, it is Async, it should givew any guarantees about immideat cache flush or ordering. bwrite() calls (in most cases, and in case of GEOM backing) ends in strategy, g_vfs_strategy() in case of GEOM (geom uses generic bufwrite(), which tweaks some flags, does some checks and send struct buf to bop_strategy, which is g_vfs_stratedy() in case of GEOM). g_vfs_strategy() sends request WITHOUT looking into ASYNC flag on "struct buf". We have BIO_ORDERED flags, but it is not used on this codepat= h! Maybe, cheap solution will be to set BIO_ORDERED on every struct bio, which is created for struct buf without ASYNC flag? Or it is too strict? Please note: now GEOM could not guarantee even ordering of SU writing requests now! Disk drivers, which sends such requests to hardware at least, could queue them too or leave them in drive's cache. It is COMPLETELY WRONG! With such disconnection between top-level logic (softupdates) and all driver stack (GEOM and disk drives) I surprised, that FFS2 could be repaired after panic at all! IMHO, it should be fixed ASAP and FFS2 should notify lower layers about writes, which is required to be ordered & landed before bwrite() returns! We have BIO_ORDERED flag, it could be used, but if it is too strict, we could add BIO_SYNC flag, too. ATA/SCSI subsystems already have proper support for BIO_ORDERED, and adding BIO_SYNC will not a big deal on low level, also, it could be easily added to g_vfs_strategy(), but I'm not sure that it will not hurt performance too much -- I'm not sure, that every buf write without ASYNC flag should be strict-SYNC. But I AM SURE, that SU/SU+J writes MUST BE DONE STRICT SYNC. P.S. I added geom@ into CC: as it seems to be UFS<->GEOM interaction problem. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Wed Nov 23 22:37:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D86F106564A for ; Wed, 23 Nov 2011 22:37:45 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C8B538FC08 for ; Wed, 23 Nov 2011 22:37:44 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 09DDC4AC1C; Thu, 24 Nov 2011 02:37:43 +0400 (MSK) Date: Thu, 24 Nov 2011 02:37:39 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <858572754.20111124023739@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 22:37:45 -0000 Hello, Kostik. You wrote 23 =ED=EE=FF=E1=F0=FF 2011 =E3., 23:44:44: >> GEOM layer when it need to ensure consistency on on-disk metadata? > No. Softupdates do not need flushes. And it seems, that fflsuh() is never becomes BIO_FLUSH or BIO_WRITE with BIO_ORDERED flag. It looks like disaster. It means, that fflush() can not guarantee its contract at all! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 15:10:17 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8DD106564A for ; Thu, 24 Nov 2011 15:10:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 171868FC08 for ; Thu, 24 Nov 2011 15:10:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAOFAGnD079981 for ; Thu, 24 Nov 2011 15:10:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAOFAGl9079980; Thu, 24 Nov 2011 15:10:16 GMT (envelope-from gnats) Date: Thu, 24 Nov 2011 15:10:16 GMT Message-Id: <201111241510.pAOFAGl9079980@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Johannes Totz" Cc: Subject: Re: kern/154491: [smbfs] smb_co_lock: recursive lock for object 1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johannes Totz List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:10:17 -0000 The following reply was made to PR kern/154491; it has been noted by GNATS. From: "Johannes Totz" To: , Cc: Subject: Re: kern/154491: [smbfs] smb_co_lock: recursive lock for object 1 Date: Thu, 24 Nov 2011 15:08:38 -0000 Same thing on FreeBSD XXX 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0 r227793: Mon Nov 21 20:19:04 GMT 2011 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 15:52:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C536A106566C for ; Thu, 24 Nov 2011 15:52:06 +0000 (UTC) (envelope-from rs@bytecamp.net) Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mx1.freebsd.org (Postfix) with ESMTP id 224748FC13 for ; Thu, 24 Nov 2011 15:52:05 +0000 (UTC) Received: (qmail 75670 invoked by uid 89); 24 Nov 2011 16:25:25 +0100 Received: from stella.bytecamp.net (HELO ?212.204.60.37?) (rs%bytecamp.net@212.204.60.37) by mail.bytecamp.net with CAMELLIA256-SHA encrypted SMTP; 24 Nov 2011 16:25:25 +0100 Message-ID: <4ECE61E5.7070003@bytecamp.net> Date: Thu, 24 Nov 2011 16:25:25 +0100 From: Robert Schulze Organization: bytecamp GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: cap cache-ssds usage on zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:52:06 -0000 Hi there, is there a way to limit the amount of space which is used on cache devices in ZFS? I mean, without doing partitioning or such. The reason for this to do is that GC on most SSDs will fail when the cache-SSDs are full (which is the case in our configuration: 7M free of 75 GB). with kind regards, Robert Schulze From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 15:58:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476191065670 for ; Thu, 24 Nov 2011 15:58:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D77B8FC18 for ; Thu, 24 Nov 2011 15:58:18 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:edef:2506:ccaa:fc4] (unknown [IPv6:2001:7b8:3a7:0:edef:2506:ccaa:fc4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 039565C37; Thu, 24 Nov 2011 16:58:16 +0100 (CET) Message-ID: <4ECE6999.8070503@FreeBSD.org> Date: Thu, 24 Nov 2011 16:58:17 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111115 Thunderbird/9.0 MIME-Version: 1.0 To: Robert Schulze References: <4ECE61E5.7070003@bytecamp.net> In-Reply-To: <4ECE61E5.7070003@bytecamp.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: cap cache-ssds usage on zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 15:58:18 -0000 On 2011-11-24 16:25, Robert Schulze wrote: > is there a way to limit the amount of space which is used on cache > devices in ZFS? I mean, without doing partitioning or such. Why can't you use partitioning? That seems the simplest solution here. No need to reinvent the wheel... From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 16:42:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52B4A106566B for ; Thu, 24 Nov 2011 16:42:39 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8438FC08 for ; Thu, 24 Nov 2011 16:42:38 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RTcNg-0007De-8d for freebsd-fs@freebsd.org; Thu, 24 Nov 2011 17:42:36 +0100 Received: from cpe-188-129-114-88.dynamic.amis.hr ([188.129.114.88]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Nov 2011 17:42:36 +0100 Received: from ivoras by cpe-188-129-114-88.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Nov 2011 17:42:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Thu, 24 Nov 2011 17:42:15 +0100 Lines: 16 Message-ID: References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-114-88.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 16:42:39 -0000 On 23.11.2011. 20:44, Kostik Belousov wrote: > The only requirement of the SU is that writes reported as done by disk > driver are indeed safely landed in the involatile storage. Well, yes, that was the idea, and it works surprisingly well even though hardware today lies about it. Some time ago I've written a patch as an learning excercise which issues a BIO_FLUSH when it thinks SU needs it - it may or may not be correct so I didn't even try to commit it: http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch Of course, reviews are welcome :) From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 17:50:10 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2F3106566B for ; Thu, 24 Nov 2011 17:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 721618FC15 for ; Thu, 24 Nov 2011 17:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pAOHo9uP028826 for ; Thu, 24 Nov 2011 17:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pAOHo91l028825; Thu, 24 Nov 2011 17:50:09 GMT (envelope-from gnats) Date: Thu, 24 Nov 2011 17:50:09 GMT Message-Id: <201111241750.pAOHo91l028825@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Johannes Totz" Cc: Subject: Re: kern/154491: [smbfs] smb_co_lock: recursive lock for object 1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Johannes Totz List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 17:50:10 -0000 The following reply was made to PR kern/154491; it has been noted by GNATS. From: "Johannes Totz" To: , Cc: Subject: Re: kern/154491: [smbfs] smb_co_lock: recursive lock for object 1 Date: Thu, 24 Nov 2011 17:43:54 -0000 Trying to unload smbfs.ko after these messages leaves the machine in some sort of zombie state. Ping to it works, but everything else is dead, no io, no keyboard input on console, numlock is dead. This is on 9-stable, r227793, x64. From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 18:03:04 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B06106564A for ; Thu, 24 Nov 2011 18:03:04 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD108FC14 for ; Thu, 24 Nov 2011 18:03:03 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id pAOI2x0b066625; Thu, 24 Nov 2011 18:02:59 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id pAOI2x38020458; Thu, 24 Nov 2011 18:02:59 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id pAOI2x3J020454; Thu, 24 Nov 2011 18:02:59 GMT Date: Thu, 24 Nov 2011 18:02:59 GMT Message-Id: <201111241802.pAOI2x3J020454@higson.cam.lispworks.com> From: Martin Simmons To: lev@freebsd.org In-reply-to: <858572754.20111124023739@serebryakov.spb.ru> (message from Lev Serebryakov on Thu, 24 Nov 2011 02:37:39 +0400) References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <858572754.20111124023739@serebryakov.spb.ru> Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 18:03:04 -0000 >>>>> On Thu, 24 Nov 2011 02:37:39 +0400, Lev Serebryakov said: > > And it seems, that fflsuh() is never becomes BIO_FLUSH or BIO_WRITE > with BIO_ORDERED flag. It looks like disaster. > > It means, that fflush() can not guarantee its contract at all! Stdio's fflush doesn't have that contract -- it just flushes the user space buffers, not the kernel buffers. __Martin From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 19:25:15 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81C1A106566B for ; Thu, 24 Nov 2011 19:25:15 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2068E8FC14 for ; Thu, 24 Nov 2011 19:25:15 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 9B0D64AC31; Thu, 24 Nov 2011 23:25:13 +0400 (MSK) Date: Thu, 24 Nov 2011 23:25:08 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1844081550.20111124232508@serebryakov.spb.ru> To: Martin Simmons In-Reply-To: <201111241802.pAOI2x3J020454@higson.cam.lispworks.com> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <858572754.20111124023739@serebryakov.spb.ru> <201111241802.pAOI2x3J020454@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 19:25:15 -0000 Hello, Martin. You wrote 24 =ED=EE=FF=E1=F0=FF 2011 =E3., 22:02:59: > Stdio's fflush doesn't have that contract -- it just flushes the user spa= ce > buffers, not the kernel buffers. Ok, let it be fsync(2). BTW, I can not see your and Kostik messages in fs@ list, only my personal copy via "CC". Is it Ok!? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 19:26:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E89721065672; Thu, 24 Nov 2011 19:26:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id AF90C8FC12; Thu, 24 Nov 2011 19:26:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 7540D4AC31; Thu, 24 Nov 2011 23:26:46 +0400 (MSK) Date: Thu, 24 Nov 2011 23:26:41 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <113503620.20111124232641@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 19:26:48 -0000 Hello, Ivan. You wrote 24 =ED=EE=FF=E1=F0=FF 2011 =E3., 20:42:15: > Some time ago I've written a patch as an learning excercise which issues > a BIO_FLUSH when it thinks SU needs it - it may or may not be correct so > I didn't even try to commit it: > http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch > Of course, reviews are welcome :) I'll give it a try. But adding BIO_SYNC flag will be better to avoid additional operations. I'm trying to measuer it impact now for very naive implementation (add BIO_SYNC flag to system, teach ata/scsi layer about it and set it for every BIO which is created from BUF without "ASYNC" flag). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 19:29:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 615E91065674; Thu, 24 Nov 2011 19:29:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 272AA8FC1B; Thu, 24 Nov 2011 19:29:39 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 5FCC94AC1C; Thu, 24 Nov 2011 23:29:38 +0400 (MSK) Date: Thu, 24 Nov 2011 23:29:33 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1359447341.20111124232933@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 19:29:39 -0000 Hello, Ivan. You wrote 24 =ED=EE=FF=E1=F0=FF 2011 =E3., 20:42:15: > http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch Your soulution could be merged with my one -- you've added special flag at BUF level, which could be good idea. But, on other hand, IMHO any non-ASYNC BUF should be converted to SYNC BIO. Now we break semantic of B_ASYNC flag -- don't guarantee sync operation on GEOM elvel when buffer request one (by not-setting B_ASYNC). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 21:55:23 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8DA106564A for ; Thu, 24 Nov 2011 21:55:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4F28C8FC13 for ; Thu, 24 Nov 2011 21:55:21 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA08248; Thu, 24 Nov 2011 23:55:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RThGI-000AIw-ER; Thu, 24 Nov 2011 23:55:18 +0200 Message-ID: <4ECEBD44.6090900@FreeBSD.org> Date: Thu, 24 Nov 2011 23:55:16 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> <20111121201332.03ecadf1@naclador.mos32.de> <4ECAC272.5080500@FreeBSD.org> In-Reply-To: <4ECAC272.5080500@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 21:55:23 -0000 on 23/11/2011 00:25 Andriy Gapon said the following: > Unfortunately the logs that you captured do not reveal a source of the problem. > I think that it would make sense to set a breakpoint at the zfs_mount function > ('b zfs_mount'). When the program stops at a break point, you can then 'step' > through the code. Then examine all arguments upon function calls and local > variables at the interesting places. For variables that are pointers please > print their dereferenced value (like 'p *x'). This could be time consuming. > > Some more straightforward things to (re-)test. > First, are you absolutely sure that the problem never happens without the patch? > Could you please retest that? Please do not touch anything under /boot, just > recompile zfsboottest with the patch reverted and run it a few time. > Then, could you please test the patch with the code from head? Again, no need > to change you real boot blocks, just checkout sys/boot from head, patch it, > recompile zfsboottest and test it. Or another idea is to use valgrind ... which I have actually done myself and found the problem. While I am working on a proper solution, please try this quick patch: http://people.freebsd.org/~avg/zfsboot.read_mos.patch -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Nov 24 23:58:48 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ED66106564A for ; Thu, 24 Nov 2011 23:58:48 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id DFCE18FC12 for ; Thu, 24 Nov 2011 23:58:47 +0000 (UTC) Received: from nskntcmgw06p ([61.9.169.166]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20111124235845.GGSI3825.nskntmtas02p.mx.bigpond.com@nskntcmgw06p>; Thu, 24 Nov 2011 23:58:45 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nskntcmgw06p with BigPond Outbound id 1Byj1i0032AGJ5o01Byl77; Thu, 24 Nov 2011 23:58:45 +0000 X-Authority-Analysis: v=2.0 cv=aYnjbGUt c=1 sm=1 a=+rWFdGQzZE3xDYVtG1Y/Og==:17 a=z1TLwsU0kBEA:10 a=kj9zAlcOel0A:10 a=mIXDIbH41VYKOlUu_hEA:9 a=jRxk7AjWHwIE8fAZRqQA:7 a=CjuIK1q_8ugA:10 a=+rWFdGQzZE3xDYVtG1Y/Og==:117 Date: Fri, 25 Nov 2011 10:58:43 +1100 From: Andrew Reilly To: Johannes Totz Message-ID: <20111124235843.GB96603@johnny.reilly.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 23:58:48 -0000 On Fri, Nov 11, 2011 at 04:36:29PM +0000, Johannes Totz wrote: > To back up a zfs dataset there are a few possibilities: > 1) rsync file data to another machine > 2) zfs-send to another machine, into a zfs dataset > 3) zfs-send to another machine, dumping the stream to a file Backing up to another machine clearly has advantages, but it's not the only way. I use ZFS send/receive to backup to a removable drive on the same machine, and it seems to be working quite nicely. > The first one works alright but you loose admin info, properties set on > the dataset, etc > The second is prefered but requires another machine which runs zfs. Method 2 does require the receiver to be running zfs, but it seems to be the only good way. Well, if you want to remote-backup to a machine not running ZFS then rsync from a zfs snapshot should get most of the way there. Modern rsync is pretty good about metadata and sparse files, I think. (Having said that, I haven't used that method for a long time.) > The third is bad. Tell me about it! I was saving zfs send streams to a UFS disk as a backkup strategy for ages. When I needed it, I discovered that there is no recovery or redundancy in zfs receive: it just stopped, unable to read the filesystem. Toast. > So far I have been doing (3), for daily short-term backups, works, > tested, everything is peachy. However, I dont like it anymore for > obvious reasons. Ideally, I would like to go with (2). But I dont have > another zfs-capable machine, or the machine that I would like to backup > onto will not ever run zfs. FWIW, my backup script is now based on: zfs snapshot tank/${1}@0 || error "problem making new snapshot on $1" zfs send -i tank/${1}@1 tank/${1}@0 | zfs recv -vF bkp2pool/$1 || error "problem sending incremental fs packet on $1" with appropriate snapshot rotation and checking scripts before and after. Seems to be working OK, and I really like the confidence that being able to wander around inside the readable backups provides. I do think that backup is something of a weakness for ZFS at the moment. Sure, live filesystems and snapshots are clearly cool, and the modern way and all, but there is an awful lot of flexibility and ease of undersanding in the model of a "backup file on a tape." Doesn't have to be on a tape, but the moral equivalent to dump/restore would (in my book) be a wonderful addition to ZFS, if anyone felt inclined. Just padding the send/receive serialisation format with enough checksum and restart information to allow detection and graceful recovery from read errors in the backup medium would do the job. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 00:07:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BB19106566B for ; Fri, 25 Nov 2011 00:07:12 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01BC58FC12 for ; Fri, 25 Nov 2011 00:07:11 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so3999950vbb.13 for ; Thu, 24 Nov 2011 16:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BAFDvBUSPtXvEL/KBByej6uY+RtlPpEkhydemmR9YV0=; b=tpBP6MDMiSzFiHMzXDT1qqBB2qyARU6n/UtQPliibiPjWmyNtRf0Xulvhw82vBVXna F/koabnDaCt1FWU+qx3o9+L+Fh0ocBc0LKE4g4SYyIsoZ1HVK8SgfT6rPJus3oc+AScm ZVYyUm0SxxULwyC77XYvOdfBPhj4gi2ZaKojo= MIME-Version: 1.0 Received: by 10.52.27.131 with SMTP id t3mr31902577vdg.29.1322179630846; Thu, 24 Nov 2011 16:07:10 -0800 (PST) Received: by 10.220.190.71 with HTTP; Thu, 24 Nov 2011 16:07:10 -0800 (PST) In-Reply-To: <20111124235843.GB96603@johnny.reilly.home> References: <20111124235843.GB96603@johnny.reilly.home> Date: Thu, 24 Nov 2011 16:07:10 -0800 Message-ID: From: Freddie Cash To: Andrew Reilly Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Johannes Totz Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 00:07:12 -0000 On Thu, Nov 24, 2011 at 3:58 PM, Andrew Reilly wrote: > I do think that backup is something of a weakness for ZFS at > the moment. Sure, live filesystems and snapshots are clearly > cool, and the modern way and all, but there is an awful lot of > flexibility and ease of undersanding in the model of a "backup > file on a tape." Doesn't have to be on a tape, but the moral > equivalent to dump/restore would (in my book) be a wonderful > addition to ZFS, if anyone felt inclined. Just padding the > send/receive serialisation format with enough checksum and > restart information to allow detection and graceful recovery > from read errors in the backup medium would do the job. One could probably work around this by doing a zfs send to a file, then running it through parchive [1] to generate all the redundancy data. Granted, I've never used par, so it may or may not be feasible. [1] http://parchive.sourceforge.net -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 00:12:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A4E6106564A for ; Fri, 25 Nov 2011 00:12:18 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0096F8FC0A for ; Fri, 25 Nov 2011 00:12:17 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RTjOp-00070J-Jf for freebsd-fs@freebsd.org; Fri, 25 Nov 2011 01:12:15 +0100 Received: from 78-86-4-158.zone2.bethere.co.uk ([78.86.4.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Nov 2011 01:12:15 +0100 Received: from johannes by 78-86-4-158.zone2.bethere.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Nov 2011 01:12:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Date: Fri, 25 Nov 2011 00:12:02 +0000 Lines: 25 Message-ID: References: <20111124235843.GB96603@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-86-4-158.zone2.bethere.co.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 00:12:18 -0000 On 25/11/2011 00:07, Freddie Cash wrote: > On Thu, Nov 24, 2011 at 3:58 PM, Andrew Reillywrote: > >> I do think that backup is something of a weakness for ZFS at >> the moment. Sure, live filesystems and snapshots are clearly >> cool, and the modern way and all, but there is an awful lot of >> flexibility and ease of undersanding in the model of a "backup >> file on a tape." Doesn't have to be on a tape, but the moral >> equivalent to dump/restore would (in my book) be a wonderful >> addition to ZFS, if anyone felt inclined. Just padding the >> send/receive serialisation format with enough checksum and >> restart information to allow detection and graceful recovery >> from read errors in the backup medium would do the job. > > > One could probably work around this by doing a zfs send to a file, then > running it through parchive [1] to generate all the redundancy data. > Granted, I've never used par, so it may or may not be feasible. > > [1] http://parchive.sourceforge.net yeah, was thinking of doing that at some stage. but then send/receive format is not guaranteed to be stable (has anybody done any tests on this? try a v1 send with a v28 receive?). From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 00:15:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6FB2106566B for ; Fri, 25 Nov 2011 00:15:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70C3D8FC12 for ; Fri, 25 Nov 2011 00:15:49 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so4004773vbb.13 for ; Thu, 24 Nov 2011 16:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a2qrYiWIguVKkWpOsoLpABBoyEHGFW8uGX56TLUd+Ic=; b=fsuV+JNh8aKGp63Lipr1moE1IMpckuORo7RD68EVnmbjpzNKVF4XPIRdrAJWZUqvkl o/84XhHYVwPYbt85mL1pRMyURZH4jSIIAAt2of3cBFiMyRA944wVVQnRlZ5om3D42T0K 8yflDGNMeHxo9DPldx1VPQE0P86kVZNAHlpzE= MIME-Version: 1.0 Received: by 10.52.99.74 with SMTP id eo10mr14002270vdb.12.1322180148753; Thu, 24 Nov 2011 16:15:48 -0800 (PST) Received: by 10.220.190.71 with HTTP; Thu, 24 Nov 2011 16:15:48 -0800 (PST) In-Reply-To: References: <20111124235843.GB96603@johnny.reilly.home> Date: Thu, 24 Nov 2011 16:15:48 -0800 Message-ID: From: Freddie Cash To: Johannes Totz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: backing up zfs dataset X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 00:15:50 -0000 On Thu, Nov 24, 2011 at 4:12 PM, Johannes Totz wrote: > On 25/11/2011 00:07, Freddie Cash wrote: > >> On Thu, Nov 24, 2011 at 3:58 PM, Andrew Reilly** >> wrote: >> >> I do think that backup is something of a weakness for ZFS at >>> the moment. Sure, live filesystems and snapshots are clearly >>> cool, and the modern way and all, but there is an awful lot of >>> flexibility and ease of undersanding in the model of a "backup >>> file on a tape." Doesn't have to be on a tape, but the moral >>> equivalent to dump/restore would (in my book) be a wonderful >>> addition to ZFS, if anyone felt inclined. Just padding the >>> send/receive serialisation format with enough checksum and >>> restart information to allow detection and graceful recovery >>> from read errors in the backup medium would do the job. >>> >> >> >> One could probably work around this by doing a zfs send to a file, then >> running it through parchive [1] to generate all the redundancy data. >> Granted, I've never used par, so it may or may not be feasible. >> >> [1] http://parchive.sourceforge.**net >> > > yeah, was thinking of doing that at some stage. but then send/receive > format is not guaranteed to be stable (has anybody done any tests on this? > try a v1 send with a v28 receive?). > I haven't tried it, but the consensus I've seen on the zfs-discuss mailing list is that so long as the receive side is of a higher (or equal) version to the send side, it's supposed to work. In theory. ;) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 06:08:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E14106564A; Fri, 25 Nov 2011 06:08:12 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2DA8FC13; Fri, 25 Nov 2011 06:08:11 +0000 (UTC) Received: from nskntcmgw07p ([61.9.169.167]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20111124230825.KUAE28461.nskntmtas06p.mx.bigpond.com@nskntcmgw07p>; Thu, 24 Nov 2011 23:08:25 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nskntcmgw07p with BigPond Outbound id 1B8N1i00K2AGJ5o01B8Rhe; Thu, 24 Nov 2011 23:08:25 +0000 X-Authority-Analysis: v=2.0 cv=N56r5hBB c=1 sm=1 a=+rWFdGQzZE3xDYVtG1Y/Og==:17 a=z1TLwsU0kBEA:10 a=R0KOSDEtWRsA:10 a=kj9zAlcOel0A:10 a=69ks7eD_NYYmXlrLNYgA:9 a=dd4w7-GCHr3Z5rRXV2QA:7 a=CjuIK1q_8ugA:10 a=+rWFdGQzZE3xDYVtG1Y/Og==:117 Date: Fri, 25 Nov 2011 10:08:22 +1100 From: Andrew Reilly To: John Message-ID: <20111124230822.GA96603@johnny.reilly.home> References: <20111101034118.GA73746@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111101034118.GA73746@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: (Yet Another) Damaged directory on ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 06:08:12 -0000 On Tue, Nov 01, 2011 at 03:41:18AM +0000, John wrote: > Hi Folks, > > We have a zfs fileserver running 9.0-RC1 which appears to have locked > up in a manner similar to the "Damanged directory on ZFS" thread. > > It started after a zfs snapshat which appears to have hung. At > that point, an "ls" command on a directory which is either empty > or contains only other directories works correctly. An "ls" on > a directory containing a file will hang. Just want to add a sort-of "me too", to this question, in the hope that I will learn something useful. For a couple of weeks I've been seeing messages in my daily security reports along the lines of: find: /usr/src/.zfs/snapshot: bad file descriptor I can get the same message now by just cd'ing into one of the two "broken" .zfs directories and comparing ls -F output with a version that doesn't check the inode data: ls: snapshot: Bad file descriptor shares/ "zfs list -r -t snapshot" shows all of the snapshots created by my nightly backups to still exist, seemingly. A zpool scrub tank did not change or make them go away. No processes appear to be stuck, wedged or otherwise broken. FWIW I'm running: FreeBSD johnny.reilly.home 9.0-RC1 FreeBSD 9.0-RC1 #4: Sat Nov 5 14:52:15 EST 2011 root@johnny.reilly.home:/usr/obj/usr/src/sys/GENERIC amd64 Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 11:38:03 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79BE7106566B; Fri, 25 Nov 2011 11:38:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id EAC418FC20; Fri, 25 Nov 2011 11:38:02 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAPBbx6M002233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Nov 2011 13:37:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAPBbxVl053331; Fri, 25 Nov 2011 13:37:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAPBbu7S053330; Fri, 25 Nov 2011 13:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Nov 2011 13:37:56 +0200 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <20111125110235.GB1642@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ueB5pLXoW+W2Rkrh" Content-Disposition: inline In-Reply-To: <20111125110235.GB1642@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 11:38:03 -0000 --ueB5pLXoW+W2Rkrh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 12:02:35PM +0100, Pawel Jakub Dawidek wrote: > On Wed, Nov 23, 2011 at 09:44:44PM +0200, Kostik Belousov wrote: > > On Wed, Nov 23, 2011 at 11:00:26PM +0400, Lev Serebryakov wrote: > > > Hello, Freebsd-fs. > > >=20 > > > Does UFS2 with softupdates (without journal) issues BIO_FLUSH to > > > GEOM layer when it need to ensure consistency on on-disk metadata? > > No. Softupdates do not need flushes. >=20 > Well, they do for two reasons: > 1. To properly handle sync operations (fsync(2), O_SYNC). > 2. To maintain consistent on-disk structures. >=20 > The second point is there, because BIO_FLUSH is the only way to avoid > reordering (apart from turning off disk write cache). >=20 > SU assumes no I/O reordering will happen, which is very weak assumption. You are not saying the whole truth there. SU only depends on the device reporting the finished write to not lie. The disk layer performing reordering of the writes, or device itself reordering (but properly reported with some tagging, e.g. NCQ) are very much fine with SU. Harware that reports finished write and not making the data to stable storage, or software driver that does such thing itself are just utterly broken. --ueB5pLXoW+W2Rkrh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7PfhQACgkQC3+MBN1Mb4ioRQCg6I8GeoOVbhpOS3V6IcusyQJE 9qAAni+RRHbWm3KFCec7lzaCIswO42oK =G4IE -----END PGP SIGNATURE----- --ueB5pLXoW+W2Rkrh-- From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 12:27:45 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD68F106566B; Fri, 25 Nov 2011 12:27:45 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4308FC08; Fri, 25 Nov 2011 12:27:45 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 43E6B4AC1C; Fri, 25 Nov 2011 16:27:44 +0400 (MSK) Date: Fri, 25 Nov 2011 16:27:38 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1798256069.20111125162738@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <20111125110235.GB1642@garage.freebsd.pl> <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:27:45 -0000 Hello, Kostik. You wrote 25 =ED=EE=FF=E1=F0=FF 2011 =E3., 15:37:56: > Harware that reports finished write and not making the data to stable > storage, or software driver that does such thing itself are just > utterly broken. Ok, than any modern hardware, especially high-performance one, is "utterly broken". We need to live with this. Almost all this hardware provide some knobs to fix situation in critical cases -- flags for synchronious write, etc. FFS/SU/SU_J doesn't use these knobs. All such flags are lost on "struct buf" <-> "str= uct bio" boundary. I like patch from ivoars@, and even more like approach with new flag for BIO and changes in ATA and SCSI drivers to support this. And my geom_raid5, which NEEDS write cache, too. Alexander Motin (mav@), AHCI driver author and person, who do a lot of work in GEOM now, agree with me (I could provide you with quotes from off-list message exchange in Russian). He agrees to add support for this flag to AHCI/ATA layer, if it will be introduced. IMHO, something should be done here. And this ``should be done'' is not ``somebody should done this.'' I could do coding, testing (but not excessive performance one 00 I don't have enough spare hardware), mav@ seems to be ready to make performance tests. But here is one trick: FFS2/SU code is very fragile, and I will need supervision from FFS guru. And if FFS guru thinks, that all storage hardware in world should be fixed (in pricv of huge perofrmance degradation), and FFS/SU is Ok as-is, it will be impossible. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 12:30:01 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E76D0106564A; Fri, 25 Nov 2011 12:30:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A8B8C8FC17; Fri, 25 Nov 2011 12:30:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D038C4AC1C; Fri, 25 Nov 2011 16:30:00 +0400 (MSK) Date: Fri, 25 Nov 2011 16:29:55 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <811912711.20111125162955@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <20111125110235.GB1642@garage.freebsd.pl> <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:30:02 -0000 Hello, Kostik. You wrote 25 =ED=EE=FF=E1=F0=FF 2011 =E3., 15:37:56: >> The second point is there, because BIO_FLUSH is the only way to avoid >> reordering (apart from turning off disk write cache). Here is BIO_ORDERED flag, but, again, FFS -> GEOM path doesn't use it. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 19:20:10 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5711065670; Fri, 25 Nov 2011 19:20:10 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFD78FC15; Fri, 25 Nov 2011 19:20:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:Mime-Version; bh=WfSOLegWPyQqhcph8/kt81XRSe83humkyFQZGtDdkO4=; b=dgMst82goRDtRClIqYnfi+qEpHlWoxIQNQZg4quligq9oFi6Zq/R1RdDUtR94CK9e7bcb1Kpo7pAfVt7TdJEpv5cxBhApUdI0sltfXzzKG9EUaUQHbz/C0XwXYUb6t45; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RU1Jg-00052X-Fl; Fri, 25 Nov 2011 13:20:09 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1322248801-1863-1862/5/1; Fri, 25 Nov 2011 19:20:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2011 13:20:01 -0600 From: Mark Felder To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Message-Id: <95d00c1b714837aa32e7da72bc4afd03@feld.me> X-Sender: feld@feld.me User-Agent: Roundcube Webmail/0.6 X-SA-Score: -1.0 Cc: Subject: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:20:11 -0000 13:14:32 nas:~ > uname -a FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M:=20 Fri Nov 25 10:07:48 CST 2011 =20 root@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64 This seemed to start happening sometime after RC1. I tried 8-STABLE and=20 it's happening there too right now. I think whatever caused this was=20 MFC'd. I've also reproduced this on completely different hardware=20 running a single disk ZFS pool. I'm getting this output in dmesg after these hangs I keep seeing. uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_ktable() at pfr_create_ktable+0xd8 pfr_ina_define() at pfr_ina_define+0x12b pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_ktable() at pfr_create_ktable+0xd8 pfr_ina_define() at pfr_ina_define+0x179 pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_kentry() at pfr_create_kentry+0x73 pfr_ina_define() at pfr_ina_define+0x2ef pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_kentry() at pfr_create_kentry+0x73 pfr_ina_define() at pfr_ina_define+0x2ef pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_kentry() at pfr_create_kentry+0x73 pfr_ina_define() at pfr_ina_define+0x2ef pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_kentry() at pfr_create_kentry+0x73 pfr_ina_define() at pfr_ina_define+0x2ef pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrkentry" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_table.c:75 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_kentry() at pfr_create_kentry+0x73 pfr_ina_define() at pfr_ina_define+0x2ef pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_ktable() at pfr_create_ktable+0xd8 pfr_ina_define() at pfr_ina_define+0x12b pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks=20 held: exclusive sleep mutex pf task mtx (pf task mtx) r =3D 0=20 (0xffffffff8199af20) locked @=20 /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c4 uma_zalloc_arg() at uma_zalloc_arg+0x335 pfr_create_ktable() at pfr_create_ktable+0xd8 pfr_ina_define() at pfr_ina_define+0x179 pfioctl() at pfioctl+0x1c5a devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 =2D-- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800da711c, rsp = =3D=20 0x7fffffff9d28, rbp =3D 0x7fffffffa1f0 --- From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 19:39:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40470106566B for ; Fri, 25 Nov 2011 19:39:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B79B98FC15 for ; Fri, 25 Nov 2011 19:39:29 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2826919vcb.13 for ; Fri, 25 Nov 2011 11:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QxIx6rhGEGVOqFzP8dNOmsvZZw381XHbUBgl2HEQO44=; b=crGP4iniOtjhdmJx1wcxk52IV5VCQpXrSLdnzrMhVwpVkoceymIq1o8SzMLwVzYMCe HRx/84KUK7/12E3fZ6yBQXV1l2naVvUAE+nHdpDCkCmpUiOKDLWmkZsOsKbcFFhGUwes vpI4AVMD/Y4OIO3tqSWtXqi4vsn03Nqcsfn64= MIME-Version: 1.0 Received: by 10.52.65.114 with SMTP id w18mr34569121vds.4.1322249968192; Fri, 25 Nov 2011 11:39:28 -0800 (PST) Received: by 10.220.183.13 with HTTP; Fri, 25 Nov 2011 11:39:28 -0800 (PST) In-Reply-To: <95d00c1b714837aa32e7da72bc4afd03@feld.me> References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> Date: Fri, 25 Nov 2011 11:39:28 -0800 Message-ID: From: Freddie Cash To: Mark Felder Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:39:30 -0000 On Fri, Nov 25, 2011 at 11:20 AM, Mark Felder wrote: > 13:14:32 nas:~ > uname -a > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M: > Fri Nov 25 10:07:48 CST 2011 root@nas.feld.me:/usr/obj/**tank/svn/sys/GENERIC > amd64 > > This seemed to start happening sometime after RC1. I tried 8-STABLE and > it's happening there too right now. I think whatever caused this was MFC'd. > I've also reproduced this on completely different hardware running a single > disk ZFS pool. > > I'm getting this output in dmesg after these hangs I keep seeing. > > uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks > held: > There's a lot of uma_* stuff in there. Just curious, what's the following sysctl set to: vfs.zfs.zio.use_uma Back in the 8.x days, it was recommended to set it to 0 due to bugs: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html No idea if this is still the case or not, but you may want to try toggling that sysctl and see if it makes a difference. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 20:56:21 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4743C1065673; Fri, 25 Nov 2011 20:56:21 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id F0DB48FC16; Fri, 25 Nov 2011 20:56:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:References:In-Reply-To:Subject:To:From:Date:Content-Type:Mime-Version; bh=3qsPWV999y6gw2pWnyaAeEerFuAhcJFp+ARd1ZnFNqk=; b=qp0ZWPCE3QQQ6wVYdwHixELeJs0NW51zEmxE8eOhr1rVstKSheODBLFdijpZZFQAp7ioU4SzENIcI668na2k454RvbONtl/T4aJGFYg3iSikfdsNZkvajCPyhUXkR3+O; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RU2ok-0007SK-Az; Fri, 25 Nov 2011 14:56:19 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1322254572-1863-1862/5/2; Fri, 25 Nov 2011 20:56:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Fri, 25 Nov 2011 14:56:11 -0600 From: Mark Felder To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org In-Reply-To: References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> Message-Id: X-Sender: feld@feld.me User-Agent: Roundcube Webmail/0.6 X-SA-Score: -1.0 Cc: Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 20:56:21 -0000 On 25.11.2011 13:39, Freddie Cash wrote: > > There's a lot of uma_* stuff in there. Just curious, what's the > following > sysctl set to: > > vfs.zfs.zio.use_uma > > Back in the 8.x days, it was recommended to set it to 0 due to bugs: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html > > No idea if this is still the case or not, but you may want to try > toggling > that sysctl and see if it makes a difference. Confirmed mine is set to 0. From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 21:47:27 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DBB0106566B; Fri, 25 Nov 2011 21:47:27 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id BAF0A8FC18; Fri, 25 Nov 2011 21:47:26 +0000 (UTC) Received: from naclador.mos32.de (ppp-188-174-66-97.dynamic.mnet-online.de [188.174.66.97]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id 96B8C3C07F00; Fri, 25 Nov 2011 22:47:24 +0100 (CET) Date: Fri, 25 Nov 2011 22:47:22 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111125224722.6cf3a299@naclador.mos32.de> In-Reply-To: <4ECEBD44.6090900@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> <20111121201332.03ecadf1@naclador.mos32.de> <4ECAC272.5080500@FreeBSD.org> <4ECEBD44.6090900@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6+hhrzn27pjrXUVnlunT9aN"; protocol="application/pgp-signature" Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 21:47:27 -0000 --Sig_/6+hhrzn27pjrXUVnlunT9aN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 24 Nov 2011 23:55:16 +0200 Andriy Gapon wrote: > Or another idea is to use valgrind ... which I have actually done > myself and found the problem. > While I am working on a proper solution, please try this quick patch: > http://people.freebsd.org/~avg/zfsboot.read_mos.patch Thanks! For the record: All systems I'm working on are of amd64 architecture. My test VM as well es the fileserver I initial ran into the problem. No more memory corruptions with the patch, but booting now stops with "ZFS: zfs_alloc()/zfs_free() mismatch". If I comment out lines 145-148 in the zfsboottest.c you linked, I can successfully read files from the pool by doing ./zfsboottest . This also works correctly when omitting up to two vdevs of my RAID-Z2 pool: # ./zfsboottest /boot/zfsloader /dev/da{0,1,2}p2 2>/dev/null | md5 336c56a04c8d6d432df999b35ce459f7 # md5 /boot/zfsloader MD5 (/boot/zfsloader) =3D 336c56a04c8d6d432df999b35ce459f7 After applying the patch from [1] (the thread references the same output I get, even if the conclusion doesn't fit) I can sometimes boot my VM. This seems to correlate with how much is written to the pool. Quickly rebooting after the system comes up works, but waiting a few minutes always results in getting the mismatch error on the reboot. After that only booting with unpatched gptzfsboot works (whereafter the patched one works again for one reboot or so). Regards Florian [1] http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026338.html --Sig_/6+hhrzn27pjrXUVnlunT9aN Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7QDOsACgkQLvW/2gp2pPyynwCgjPiF67wrDwrU8PPbJ64Co0JN 9CQAmwbE6j5dBBhXbLuwttex20i70ZbA =8N2d -----END PGP SIGNATURE----- --Sig_/6+hhrzn27pjrXUVnlunT9aN-- From owner-freebsd-fs@FreeBSD.ORG Fri Nov 25 23:02:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E0E6106564A for ; Fri, 25 Nov 2011 23:02:22 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E19888FC16 for ; Fri, 25 Nov 2011 23:02:21 +0000 (UTC) Received: from localhost (unknown [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 474D5FDA; Fri, 25 Nov 2011 16:18:04 +0100 (CET) Date: Fri, 25 Nov 2011 16:16:47 +0100 From: Pawel Jakub Dawidek To: Kostik Belousov Message-ID: <20111125151646.GC1642@garage.freebsd.pl> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <20111125110235.GB1642@garage.freebsd.pl> <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 23:02:22 -0000 --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 01:37:56PM +0200, Kostik Belousov wrote: > On Fri, Nov 25, 2011 at 12:02:35PM +0100, Pawel Jakub Dawidek wrote: > > On Wed, Nov 23, 2011 at 09:44:44PM +0200, Kostik Belousov wrote: > > > On Wed, Nov 23, 2011 at 11:00:26PM +0400, Lev Serebryakov wrote: > > > > Hello, Freebsd-fs. > > > >=20 > > > > Does UFS2 with softupdates (without journal) issues BIO_FLUSH to > > > > GEOM layer when it need to ensure consistency on on-disk metadata? > > > No. Softupdates do not need flushes. > >=20 > > Well, they do for two reasons: > > 1. To properly handle sync operations (fsync(2), O_SYNC). > > 2. To maintain consistent on-disk structures. > >=20 > > The second point is there, because BIO_FLUSH is the only way to avoid > > reordering (apart from turning off disk write cache). > >=20 > > SU assumes no I/O reordering will happen, which is very weak assumption. > You are not saying the whole truth there. >=20 > SU only depends on the device reporting the finished write to not lie. > The disk layer performing reordering of the writes, or device itself > reordering (but properly reported with some tagging, e.g. NCQ) are > very much fine with SU. Yes, the consolusion is that for SU to keep its state consistent on-disk you need either truly synchronous writes or no reordering. You don't need synchronous writes to maintain SU consistency, you only need to keep ordering right. Because synchronous writes are hard to count on these days, you need to ensure the ordering is right by either using BIO_FLUSH or some (nonexistent) BIO_BARRIER. Synchronous writes (or BIO_FLUSH) are needed to handle O_SYNC/fsync(2) properly, which UFS currently doesn't care about. > Harware that reports finished write and not making the data to stable > storage, or software driver that does such thing itself are just > utterly broken. Well, we ask hardware to do this by default - we turn on disk write cache by default. Solaris doesn't do that, for example. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --GPJrCs/72TxItFYR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk7PsV4ACgkQForvXbEpPzSTOwCfdXCm92/beJgivKtHg97dDys6 OX0An0oI3p8xAcTCjASbl6x6Jh8/NEl3 =lvpy -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 07:25:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E0A1065672 for ; Sat, 26 Nov 2011 07:25:14 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id D39188FC0C for ; Sat, 26 Nov 2011 07:25:13 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pAQ7PDow056289; Fri, 25 Nov 2011 23:25:13 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201111260725.pAQ7PDow056289@chez.mckusick.com> To: Kostik Belousov In-reply-to: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> Date: Fri, 25 Nov 2011 23:25:13 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:25:14 -0000 Kostik, You are entirely correct when you say that the requirement for SU and SU+J is that it requires that notification of a disk-write complete mean that the data is on the disk (stable). The problem that arises is that (apparently) some tag-queue implementations report back that tags have been written when in fact they have not been written. I believe that they only way to ensure that a tagged request is on stable store is to send a BIO_BARRIER request to the disk. The BIO_BARRIER request is not supposed to return until all I/O requests that were sent down prior to the BIO_BARRIER have been committed to stable store. If in fact the disk hardware lies about tag completion, my proposed way for SU and SU+J to use BIO_BARRIER is to send one down periodically (say every 100ms) and then defer processing any I/O completions from before the barrier request until the BIO_BARRIER completes. Since most SU activity is going on in background, the delay should not be too noticable. The main place where it would likely show up is in fsync which could be delayed for up to the period (100ms). For such cases, the fsync should issue its own BIO_BARRIER once it has initiated all of its required I/O. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 07:26:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F16106566C for ; Sat, 26 Nov 2011 07:26:26 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 76AA18FC28 for ; Sat, 26 Nov 2011 07:26:25 +0000 (UTC) Received: by wwo28 with SMTP id 28so3645870wwo.1 for ; Fri, 25 Nov 2011 23:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=/53/Sn0EmeYFabJxyDYMWPjF27pGWvacBOWnccNVRcU=; b=NtoAGHraagkCTCcGdxjkqWyb8UcOnqOQqqbVZDWrmZ3bi2J1csao2ofJHJSV8LVnB1 S/UfWyKvE14s39ZDY6ak6GHWQq3DdKvPleKoP7RT+DktBROyHYzmg+T+uDqXmZZvndSr P1+30fGjB2wo+D+Iauk90Gtj5IbhqumBe50MM= Received: by 10.180.91.8 with SMTP id ca8mr36935090wib.22.1322292384513; Fri, 25 Nov 2011 23:26:24 -0800 (PST) Received: from [192.168.1.11] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id em4sm30545057wbb.20.2011.11.25.23.26.23 (version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 23:26:24 -0800 (PST) Message-ID: <4ED0949A.8080602@gmail.com> Date: Sat, 26 Nov 2011 08:26:18 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: zvol and zfs send no file on the receiving side. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:26:26 -0000 Hello all! After some reluctance using zfs i decided it was time to just use it, and it make my life a lot easier. Thank you all ! One thing i can not get to work however is sending and receiving a zfs volume. I have a master so to say, and a bacup server. On the master the pool is named storage, on the backup machine the pool is called tank. on the master i did the following. # zfs create -V10G storage/iscsitest if i do a zfs list -t volume, i see that the volume is there. # zfs list -t volume NAME USED AVAIL REFER MOUNTPOINT storage/iscsitest 10.3G 65.9G 16K - If i go to the directory /storage and do a ls -al i see my zvol file. # ls -al total 1901416 drwxr-xr-x 4 root wheel 5 Nov 25 17:44 . drwxr-xr-x 19 root wheel 1024 Nov 25 11:33 .. -rw-r--r-- 1 root wheel 10737418240 Nov 25 20:46 iscsitest Ok all is fine, i can create a scsi target pointing to storage/iscsitest, and it works, and i use a esxi host to mount it. I did put a virtual machine on it so i have some data in the zvol. Works great. Now i want to make a backup of that zvol so i can create a kind of cold standby server. This way when the master dies for what ever reason, my zvols are on another server as a backup, but if things really get troublesome i can share them as iscsi target! So on the master i create a snapshot of my zvol. #zfs snapshot storage/iscsitest@snap1 Check with zfs list -t snapshot to see if i have a snapshot. #zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT storage/iscsitest@snap1 0 - 16K - Well there it is. now i send that zvol to my backup server. So the following command should do it. # zfs send -R storage/iscsitest@snap1 | ssh root@192.168.50.200 zfs recv -v tank/iscsitest Password: mypasss receiving full stream of storage/iscsitest@snap1 into tank/iscsitest@snap1 received 3.85KB stream in 1 seconds (3.85KB/sec) on my backup server, i now have the following #zfs list NAME USED AVAIL REFER MOUNTPOINT tank 159G 427G 31K /tank tank/iscsitest 10.3G 438G 16K - tank/share 149G 427G 136G /mnt Ok that looks fine, lets see if i have some snapshots here. #zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT tank/iscsitest@snap1 0 - 16K - Ok that looks good. Let see if there is a volume # zfs list -t volume NAME USED AVAIL REFER MOUNTPOINT tank/iscsitest 10.3G 438G 16K - Well all looks good, now lets look at the file so i can share this over iscsi. cd /tank #ls -al total 4 drwxr-xr-x 2 root wheel 2 Nov 25 21:45 ./ drwxr-xr-x 22 root wheel 512 Nov 25 21:54 ../ Where is my file??? I am trying to get this done for a long time now, and i can not get it to work!! i did do a export / import, but no file! Also tried doing a rollback on the backup server. Also a local backup does not work. # zfs send -R storage/iscsitest@snap1 | zfs recv -v storage/iscsitest-bck receiving full stream of storage/iscsitest@snap1 into storage/iscsitest-bck@snap1 received 3.85KB stream in 1 seconds (3.85KB/sec) # zfs list NAME USED AVAIL REFER MOUNTPOINT storage 411G 45.3G 1.81G /storage storage/iscsitest 10.3G 55.6G 16K - storage/iscsitest-bck 10.3G 55.6G 16K - # zfs list -t volume NAME USED AVAIL REFER MOUNTPOINT storage/iscsitest 10.3G 55.6G 16K - storage/iscsitest-bck 10.3G 55.6G 16K - # zfs list NAME USED AVAIL REFER MOUNTPOINT storage/iscsitest 10.3G 55.6G 16K - storage/iscsitest-bck 10.3G 55.6G 16K - # ls -al total 1901416 drwxr-xr-x 4 root wheel 5 Nov 25 17:44 . drwxr-xr-x 19 root wheel 1024 Nov 25 11:33 .. -rw-r--r-- 1 root wheel 10737418240 Nov 25 20:46 iscsitest So again no file iscsitest-bck What am i missing.! This is on FreeBSD 9.0 RC2 AMD64 Thanks again for the wonderful work on ZFS. regards Johan From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 07:27:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B03D106566B for ; Sat, 26 Nov 2011 07:27:47 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 224418FC14 for ; Sat, 26 Nov 2011 07:27:46 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pAQ7Rlh6056867; Fri, 25 Nov 2011 23:27:47 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201111260727.pAQ7Rlh6056867@chez.mckusick.com> To: Ivan Voras In-reply-to: Date: Fri, 25 Nov 2011 23:27:47 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:27:47 -0000 Your proposed change is definitely useful, though really just applies to filesystems running without SU and SU+J. The cases where bwrite are used are when we are using synchronous write to maintain filesystem consistency (e.g., the filesystem before SU). Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 07:37:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835A0106566C; Sat, 26 Nov 2011 07:37:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 47FA78FC0C; Sat, 26 Nov 2011 07:37:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0D8CB4AC1C; Sat, 26 Nov 2011 11:37:50 +0400 (MSK) Date: Sat, 26 Nov 2011 11:37:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1355750307.20111126113744@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20111125151646.GC1642@garage.freebsd.pl> References: <1957615267.20111123230026@serebryakov.spb.ru> <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <20111125110235.GB1642@garage.freebsd.pl> <20111125113756.GZ50300@deviant.kiev.zoral.com.ua> <20111125151646.GC1642@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:37:52 -0000 Hello, Pawel. You wrote 25 =ED=EE=FF=E1=F0=FF 2011 =E3., 19:16:47: > Because synchronous writes are hard to count on these days, you need to > ensure the ordering is right by either using BIO_FLUSH or some > (nonexistent) BIO_BARRIER. Here IS BIO_ORDERED. And disksort() function respect it. Drivers are not. But I more like adding BIO_FSYNC flag, which will means "Ordered, and, pleas try be as synchronious as possible". :) Now I have VM running to calculate number of bwrite()'s from softupdate code vs "simple" bwrite()s, by adding flag to "struct buf" for EACH softupdate bwrite(). But here is a problem, see below. > Synchronous writes (or BIO_FLUSH) are needed to handle O_SYNC/fsync(2) > properly, which UFS currently doesn't care about. Yep, and this too. But I'm not sure, that I could identify all codepaths in FFS/UFS/SoftUpdates/SU+J which starts in (a) SU updates and (b) O_SYNC wtires (c) fsync() calls. And adding THE SAME flag for all cases is slightly too much (see above), as O_SYNC and fsync() needs true sync, and SU needs only ordering flag. It is possible to add all these into GEOM, and ATA/AHCI author (Alexander Motin) is ready to add support for them to ATA/AHCI, but, again, I need help from UFS/FFS/SU guru to add all needed and only needed flags in each and every proper place. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 07:52:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FAC31065676; Sat, 26 Nov 2011 07:52:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA2558FC0A; Sat, 26 Nov 2011 07:52:55 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 928F84AC1C; Sat, 26 Nov 2011 11:52:54 +0400 (MSK) Date: Sat, 26 Nov 2011 11:52:48 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <147455115.20111126115248@serebryakov.spb.ru> To: Kirk McKusick In-Reply-To: <201111260727.pAQ7Rlh6056867@chez.mckusick.com> References: <201111260727.pAQ7Rlh6056867@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 07:52:56 -0000 Hello, Kirk. You wrote 26 =ED=EE=FF=E1=F0=FF 2011 =E3., 11:27:47: > Your proposed change is definitely useful, though really just applies > to filesystems running without SU and SU+J. The cases where bwrite > are used are when we are using synchronous write to maintain > filesystem consistency (e.g., the filesystem before SU). It is why I'm asking, or even begging, for help from you or other person, who understand SU/SU+J well for help to make it properly! Which codepaths in ffs_softdep.c are used with SU/SU+J? For example, bwrite() is used in softdep_process_journal() or clear_unlinked_inodedep()-- I see here contradiction with statement, that brwite() is only used WITHOUT SU and SU+J. But it seems, that I don't understand this code at all. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 08:03:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 078B41065677; Sat, 26 Nov 2011 08:03:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 97D2A8FC12; Sat, 26 Nov 2011 08:03:55 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAQ83qgN055798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Nov 2011 10:03:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAQ83pWT059912; Sat, 26 Nov 2011 10:03:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAQ83pHt059911; Sat, 26 Nov 2011 10:03:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Nov 2011 10:03:51 +0200 From: Kostik Belousov To: Kirk McKusick Message-ID: <20111126080351.GD50300@deviant.kiev.zoral.com.ua> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aWoxrSeOuqWGYfm5" Content-Disposition: inline In-Reply-To: <201111260725.pAQ7PDow056289@chez.mckusick.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:03:57 -0000 --aWoxrSeOuqWGYfm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 11:25:13PM -0800, Kirk McKusick wrote: > Kostik, >=20 > You are entirely correct when you say that the requirement for > SU and SU+J is that it requires that notification of a disk-write > complete mean that the data is on the disk (stable). The problem > that arises is that (apparently) some tag-queue implementations > report back that tags have been written when in fact they have > not been written.=20 Right, and my belief that real hardware is not much affected, except probably some ultra-cheap and old ATA disks. Another issue is broken-by-design 'drivers' which authors do not understand the environment they programming for. >=20 > I believe that they only way to ensure that a tagged request is > on stable store is to send a BIO_BARRIER request to the disk. The > BIO_BARRIER request is not supposed to return until all I/O > requests that were sent down prior to the BIO_BARRIER have been > committed to stable store. >=20 > If in fact the disk hardware lies about tag completion, my > proposed way for SU and SU+J to use BIO_BARRIER is to send > one down periodically (say every 100ms) and then defer processing > any I/O completions from before the barrier request until the > BIO_BARRIER completes. Since most SU activity is going on in > background, the delay should not be too noticable. The main > place where it would likely show up is in fsync which could be > delayed for up to the period (100ms). For such cases, the fsync > should issue its own BIO_BARRIER once it has initiated all of > its required I/O. I do not see how this proposal change much, except limiting potential havoc to the last 100ms of system operation. In fact, reordering, besides causing fs consistency problems, may cause the security issues as well [*]. If user data is written into the reused blocks, but metadata update was ordered after data write, we can end with the arbitrary override of the sensititive authorization or accounting information. * I expect some people going wonky at this point and immediately remove corresponding driver from ports. P.S. Sorry for being grumpy. --aWoxrSeOuqWGYfm5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7QnWcACgkQC3+MBN1Mb4h2CgCcC2ob7hPtDcYfGQFZZzuoUEeb 4sMAoMwBNpMp/oCd4EbZNiCV+jUn17pX =7dr3 -----END PGP SIGNATURE----- --aWoxrSeOuqWGYfm5-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 08:04:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7754106564A for ; Sat, 26 Nov 2011 08:04:55 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DE638FC14 for ; Sat, 26 Nov 2011 08:04:55 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 1C9064AC1C; Sat, 26 Nov 2011 12:04:54 +0400 (MSK) Date: Sat, 26 Nov 2011 12:04:48 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <22120688.20111126120448@serebryakov.spb.ru> To: Kirk McKusick In-Reply-To: <201111260725.pAQ7PDow056289@chez.mckusick.com> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:04:55 -0000 Hello, Kirk. You wrote 26 =ED=EE=FF=E1=F0=FF 2011 =E3., 11:25:13: > You are entirely correct when you say that the requirement for > SU and SU+J is that it requires that notification of a disk-write > complete mean that the data is on the disk (stable). The problem > that arises is that (apparently) some tag-queue implementations > report back that tags have been written when in fact they have > not been written. Or any GEOM implements write cache. Please, don't forget, that now FS doesn't ask disk driver to write block, it asks GEOM stack, which could be composed from several nodes, located on several physically independent computers (don't forget about geom_gate, iSCSI, etc). Or any hardware implements big write cache, too. Every HDD or controller will report not-queued write as complete after copying data into cache (if WC is enabled). And even if cache is baked by battery, nobody promise to flush it in proper (from SU point of view) order. And even worse, if cache is not battery-backed (but server itself IS), or its flush depends on drivers (GEOM case), and here is system crash. > I believe that they only way to ensure that a tagged request is > on stable store is to send a BIO_BARRIER request to the disk. The > BIO_BARRIER request is not supposed to return until all I/O > requests that were sent down prior to the BIO_BARRIER have been > committed to stable store. IMHO, idea with per-request flag, which driver will translate into appropriate device flags (may be, in barrier, but maybe not -- depends on device capabilities) is much better. BIO_BARRIER will flush ALL write cache by design. It is barrier, and it hasn't any references to previous requests, it is flush-them-all request. It could be HUGE performance impact, if you will flush large write cache of controller every 100ms. But if SU/fsync()/O_SYNC requests will be marked with special flag, GEOM stack and controller will be able to process these requests separately on one hand, and will not flush cache on timer basis, on other, if it is possible. Maybe, on some hardware, it will have same effect as barrier, but I'm sure, that there IS hardware, which could handle such requests much more effectively, that full cache flush. And, yes, GEOM too. Again, I, as maintainer of geom_raid5, know how vital to have good cache in this module (with some requests reside in it for tens of secinds!), and I don't see any way to implement barrier, but flush cache on each barrier -- which effectively disable cache at all. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 08:14:02 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 557EF106564A for ; Sat, 26 Nov 2011 08:14:02 +0000 (UTC) (envelope-from lev@freebsd.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3BE8FC0A for ; Sat, 26 Nov 2011 08:14:02 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C51BD4AC1C; Sat, 26 Nov 2011 12:14:00 +0400 (MSK) Date: Sat, 26 Nov 2011 12:13:54 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1961318852.20111126121354@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111126080351.GD50300@deviant.kiev.zoral.com.ua> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> <20111126080351.GD50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:14:02 -0000 Hello, Kostik. You wrote 26 =ED=EE=FF=E1=F0=FF 2011 =E3., 12:03:51: >> You are entirely correct when you say that the requirement for >> SU and SU+J is that it requires that notification of a disk-write >> complete mean that the data is on the disk (stable). The problem >> that arises is that (apparently) some tag-queue implementations >> report back that tags have been written when in fact they have >> not been written.=20 > Right, and my belief that real hardware is not much affected, You have wrong idea about modern hardware, sorry. Again: don't forget multi-megabyte caches, and absence of any guarantees, in which order these caches will be flashed. Many controllers and drives itself group writes. And if companion for data block in cache is found earlier than companion for metadata block (as drive doesn't distinguish them) or waiting timeout, data block will be written first. The same applicable to two metadata blocks, of course. And it is not question of BROKEN QUEUEING. Again, I'm speaking not about cheap ATA drivers here, but about expensive high-performance RAID controllers ands server drives with huge caches. > except probably some ultra-cheap and old ATA disks. Another issue > is broken-by-design 'drivers' which authors do not understand the > environment they programming for. And, again, or you have synchronous from top to bottoms storage stack and performance, which will be miserable, compared to other OSes, or you need to give some freedom to driver authors and provide hints about semantic of personal operations to them. Every drive and controller, which does write caching and reordering (except old, cheap broken ATA ones) HAVE flags and knobs to send this individual block to plactes as soon as possible. But now drivers doesn't have any idea when they should use these flags. And they don't use them. > I do not see how this proposal change much, except limiting potential > havoc to the last 100ms of system operation. In fact, reordering, > besides causing fs consistency problems, may cause the security issues > as well [*]. If user data is written into the reused blocks, but > metadata update was ordered after data write, we can end with the > arbitrary override of the sensititive authorization or accounting > information. It is why metadata requests should be marked as non-reordable, non-queuable. Personal requests, not some global barrier every 100ms. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 08:41:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 505B4106564A; Sat, 26 Nov 2011 08:41:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id F10DD8FC0A; Sat, 26 Nov 2011 08:41:54 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAQ8fpRP060003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Nov 2011 10:41:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAQ8fpCK060088; Sat, 26 Nov 2011 10:41:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAQ8fp3k060087; Sat, 26 Nov 2011 10:41:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Nov 2011 10:41:51 +0200 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20111126084151.GH50300@deviant.kiev.zoral.com.ua> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> <20111126080351.GD50300@deviant.kiev.zoral.com.ua> <1961318852.20111126121354@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uu8WkaNTGbYHJAd1" Content-Disposition: inline In-Reply-To: <1961318852.20111126121354@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kirk McKusick , freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 08:41:56 -0000 --Uu8WkaNTGbYHJAd1 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 26, 2011 at 12:13:54PM +0400, Lev Serebryakov wrote: > Hello, Kostik. > You wrote 26 =CE=CF=D1=C2=D2=D1 2011 =C7., 12:03:51: >=20 > >> You are entirely correct when you say that the requirement for > >> SU and SU+J is that it requires that notification of a disk-write > >> complete mean that the data is on the disk (stable). The problem > >> that arises is that (apparently) some tag-queue implementations > >> report back that tags have been written when in fact they have > >> not been written.=20 > > Right, and my belief that real hardware is not much affected, > You have wrong idea about modern hardware, sorry. >=20 > Again: don't forget multi-megabyte caches, and absence of any > guarantees, in which order these caches will be flashed. Many > controllers and drives itself group writes. And if companion for data > block in cache is found earlier than companion for metadata block (as > drive doesn't distinguish them) or waiting timeout, data block will > be written first. The same applicable to two metadata blocks, of > course. And it is not question of BROKEN QUEUEING. >=20 > Again, I'm speaking not about cheap ATA drivers here, but about > expensive high-performance RAID controllers ands server drives with > huge caches. >=20 > > except probably some ultra-cheap and old ATA disks. Another issue > > is broken-by-design 'drivers' which authors do not understand the > > environment they programming for. > And, again, or you have synchronous from top to bottoms storage > stack and performance, which will be miserable, compared to other > OSes, or you need to give some freedom to driver authors and provide > hints about semantic of personal operations to them. Every drive and > controller, which does write caching and reordering (except old, > cheap broken ATA ones) HAVE flags and knobs to send this individual > block to plactes as soon as possible. But now drivers doesn't have > any idea when they should use these flags. And they don't use them. Sigh. In-kernel i/o subsystem is already asynchronous by design. You have to make special arrangements to get synchronous writes of the blocks (like using bwrite()). And even if you do, buf layer emulates the sync operation by blocking the thread until async even happen. Whole buffer i/o (including reads) operates using bio_done callbacks called on the operation end. In fact, there is inherited uglyness due to async nature, namely, the kernel-owned buffer locks. Getting rid of them would be much more useful then breaking UFS. The non-broken driver must not return the 'completed' bio into the up queue until write is sent to hardware and hardware reported the completion. Raid controllers which aggressively cache the writes use nvram or battery backups, and do not allow to turn on write cache if battery is non-functional. I had not seen SU inconsistencies on RAID 6 on mfi(4), despite one our machine has unfortunate habit of dropping boot disk over SATA channel each week, for 2 years. >=20 > > I do not see how this proposal change much, except limiting potential > > havoc to the last 100ms of system operation. In fact, reordering, > > besides causing fs consistency problems, may cause the security issues > > as well [*]. If user data is written into the reused blocks, but > > metadata update was ordered after data write, we can end with the > > arbitrary override of the sensititive authorization or accounting > > information. > It is why metadata requests should be marked as non-reordable, > non-queuable. Personal requests, not some global barrier every 100ms. >=20 You again missed the point - if metadata is not reordable, but user data is, you get security issues. They are similar (but inverse) to what I described in the previous paragraph. --Uu8WkaNTGbYHJAd1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7Qpk8ACgkQC3+MBN1Mb4gpgQCfUVp3nqV+JAnWk+UEsU3DOPIK 5WwAnRf6jq28W3yqR1kOQwBNbOpZ3rPz =IEoy -----END PGP SIGNATURE----- --Uu8WkaNTGbYHJAd1-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 10:56:52 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906561065670 for ; Sat, 26 Nov 2011 10:56:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C60A38FC08 for ; Sat, 26 Nov 2011 10:56:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA03572; Sat, 26 Nov 2011 12:56:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUFw8-000H6i-7a; Sat, 26 Nov 2011 12:56:48 +0200 Message-ID: <4ED0C5EE.2000001@FreeBSD.org> Date: Sat, 26 Nov 2011 12:56:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Johan Hendriks References: <4ED0949A.8080602@gmail.com> In-Reply-To: <4ED0949A.8080602@gmail.com> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: zvol and zfs send no file on the receiving side. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 10:56:52 -0000 on 26/11/2011 09:26 Johan Hendriks said the following: > If i go to the directory /storage and do a ls -al > i see my zvol file. I wonder why you decided that that file is your zvol. Please read up on what zvol really is. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 11:06:53 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0782A106564A; Sat, 26 Nov 2011 11:06:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2231F8FC08; Sat, 26 Nov 2011 11:06:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03661; Sat, 26 Nov 2011 13:06:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUG5Q-000H70-Rn; Sat, 26 Nov 2011 13:06:24 +0200 Message-ID: <4ED0C830.6040805@FreeBSD.org> Date: Sat, 26 Nov 2011 13:06:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Mark Felder References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> In-Reply-To: <95d00c1b714837aa32e7da72bc4afd03@feld.me> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 11:06:53 -0000 on 25/11/2011 21:20 Mark Felder said the following: > 13:14:32 nas:~ > uname -a > FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3 r227971M: Fri Nov > 25 10:07:48 CST 2011 root@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64 > > This seemed to start happening sometime after RC1. I tried 8-STABLE and it's > happening there too right now. I think whatever caused this was MFC'd. I've also > reproduced this on completely different hardware running a single disk ZFS pool. > > > I'm getting this output in dmesg after these hangs I keep seeing. > > > uma_zalloc_arg: zone "pfrktable" with the following non-sleepable locks held: > exclusive sleep mutex pf task mtx (pf task mtx) r = 0 (0xffffffff8199af20) > locked @ /tank/svn/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:1589 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > _witness_debugger() at _witness_debugger+0x2e > witness_warn() at witness_warn+0x2c4 > uma_zalloc_arg() at uma_zalloc_arg+0x335 > pfr_create_ktable() at pfr_create_ktable+0xd8 > pfr_ina_define() at pfr_ina_define+0x12b > pfioctl() at pfioctl+0x1c5a > devfs_ioctl_f() at devfs_ioctl_f+0x7a > kern_ioctl() at kern_ioctl+0xcd > sys_ioctl() at sys_ioctl+0xfd > amd64_syscall() at amd64_syscall+0x3ac > Xfast_syscall() at Xfast_syscall+0xf7 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800da711c, rsp = > 0x7fffffff9d28, rbp = 0x7fffffffa1f0 --- Please note that all these messages are about pf. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 11:22:54 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD53106564A for ; Sat, 26 Nov 2011 11:22:54 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 669B78FC08 for ; Sat, 26 Nov 2011 11:22:54 +0000 (UTC) Received: by wwe5 with SMTP id 5so3560628wwe.31 for ; Sat, 26 Nov 2011 03:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bOKKy6xSE+VaVeFgeOEWH4Emi+pIB0EApCRkfJXSKdA=; b=MSxcvfNNPRIueHNlGTaPmVniAY0r79YXgriCT43WGZpK27S7Y+nLZ5xktGGloLUEmp Q4QjU4xO5BKV0sThtQceO3z+PNM5e29nmGOSJjJD1cYB0HVWNa44KCWrjpUbL7rrRnzh qVRwnbLPn0GkzF/NRpvuL4RkEsZkkm4M5LPKs= Received: by 10.180.101.132 with SMTP id fg4mr1178187wib.26.1322306573555; Sat, 26 Nov 2011 03:22:53 -0800 (PST) Received: from [192.168.1.11] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id ff1sm8393019wbb.5.2011.11.26.03.22.53 (version=SSLv3 cipher=OTHER); Sat, 26 Nov 2011 03:22:53 -0800 (PST) Message-ID: <4ED0CC0C.3010309@gmail.com> Date: Sat, 26 Nov 2011 12:22:52 +0100 From: johan Hendriks User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4ED0949A.8080602@gmail.com> <4ED0C5EE.2000001@FreeBSD.org> In-Reply-To: <4ED0C5EE.2000001@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: zvol and zfs send no file on the receiving side. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 11:22:54 -0000 Op 26-11-11 11:56, Andriy Gapon schreef: > on 26/11/2011 09:26 Johan Hendriks said the following: >> If i go to the directory /storage and do a ls -al >> i see my zvol file. > I wonder why you decided that that file is your zvol. > Please read up on what zvol really is. > > > Please enlighten me, i am struggling way to long with this. How do i set my iscsi target then. On the master i set it to. #LUN0 Storage /storage/iscsitest 10GB Wait now i type this, i think i am not using the zvol at all, but just creates a file on my zpool, that get shared as a target. I need to set it to something like this. LUN0 Storage /dev/zvol/tank/istgttest 10GB Am i right here? Thanks by the way, sometimes a little pointer is all you need. When struggling with something you overlook some vital things. I will try things tonight. regards Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 11:39:43 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF41E106566C for ; Sat, 26 Nov 2011 11:39:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0838FC18 for ; Sat, 26 Nov 2011 11:39:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03974; Sat, 26 Nov 2011 13:39:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RUGba-000H82-RN; Sat, 26 Nov 2011 13:39:38 +0200 Message-ID: <4ED0CFF9.4030503@FreeBSD.org> Date: Sat, 26 Nov 2011 13:39:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Florian Wagner References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> <20111121201332.03ecadf1@naclador.mos32.de> <4ECAC272.5080500@FreeBSD.org> <4ECEBD44.6090900@FreeBSD.org> <20111125224722.6cf3a299@naclador.mos32.de> In-Reply-To: <20111125224722.6cf3a299@naclador.mos32.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 11:39:43 -0000 on 25/11/2011 23:47 Florian Wagner said the following: > No more memory corruptions with the patch, but booting now stops with > "ZFS: zfs_alloc()/zfs_free() mismatch". This happens only with real boot, not with zfsboottest? > If I comment out lines 145-148 in the zfsboottest.c you linked, I can > successfully read files from the pool by doing ./zfsboottest Ah, right, those lines were left there by mistake during merge. > . This also works correctly when omitting up to two > vdevs of my RAID-Z2 pool: > > # ./zfsboottest /boot/zfsloader /dev/da{0,1,2}p2 2>/dev/null | md5 > 336c56a04c8d6d432df999b35ce459f7 > # md5 /boot/zfsloader > MD5 (/boot/zfsloader) = 336c56a04c8d6d432df999b35ce459f7 > > > After applying the patch from [1] (the thread references the same > output I get, even if the conclusion doesn't fit) I can sometimes > boot my VM. This seems to correlate with how much is written to the > pool. Quickly rebooting after the system comes up works, but waiting a > few minutes always results in getting the mismatch error on the reboot. > After that only booting with unpatched gptzfsboot works (whereafter the > patched one works again for one reboot or so). Oh, strangeness... -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 12:49:30 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01E5106566B; Sat, 26 Nov 2011 12:49:30 +0000 (UTC) (envelope-from florian@wagner-flo.net) Received: from umbracor.wagner-flo.net (umbracor.wagner-flo.net [213.165.81.202]) by mx1.freebsd.org (Postfix) with ESMTP id 760098FC08; Sat, 26 Nov 2011 12:49:30 +0000 (UTC) Received: from naclador.mos32.de (ppp-188-174-34-223.dynamic.mnet-online.de [188.174.34.223]) by umbracor.wagner-flo.net (Postfix) with ESMTPSA id 5D4F83C07F00; Sat, 26 Nov 2011 13:49:29 +0100 (CET) Date: Sat, 26 Nov 2011 13:49:27 +0100 From: Florian Wagner To: Andriy Gapon Message-ID: <20111126134927.60fe5097@naclador.mos32.de> In-Reply-To: <4ED0CFF9.4030503@FreeBSD.org> References: <20111015214347.09f68e4e@naclador.mos32.de> <4E9ACA9F.5090308@FreeBSD.org> <20111019082139.1661868e@auedv3.syscomp.de> <4E9EEF45.9020404@FreeBSD.org> <20111019182130.27446750@naclador.mos32.de> <4EB98E05.4070900@FreeBSD.org> <20111119211921.7ffa9953@naclador.mos32.de> <4EC8CD14.4040600@FreeBSD.org> <20111120121248.5e9773c8@naclador.mos32.de> <4EC91B36.7060107@FreeBSD.org> <20111120191018.1aa4e882@naclador.mos32.de> <4ECA2DBD.5040701@FreeBSD.org> <20111121201332.03ecadf1@naclador.mos32.de> <4ECAC272.5080500@FreeBSD.org> <4ECEBD44.6090900@FreeBSD.org> <20111125224722.6cf3a299@naclador.mos32.de> <4ED0CFF9.4030503@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//+8v1rer=FeMFRn.9d_uvdF"; protocol="application/pgp-signature" Cc: freebsd-fs@FreeBSD.org Subject: Re: Extending zfsboot.c to allow selecting filesystem from boot.config X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 12:49:30 -0000 --Sig_//+8v1rer=FeMFRn.9d_uvdF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 26 Nov 2011 13:39:37 +0200 Andriy Gapon wrote: > on 25/11/2011 23:47 Florian Wagner said the following: > > No more memory corruptions with the patch, but booting now stops > > with "ZFS: zfs_alloc()/zfs_free() mismatch". >=20 > This happens only with real boot, not with zfsboottest? Yes, zfsboottest works without issues. > > If I comment out lines 145-148 in the zfsboottest.c you linked, I > > can successfully read files from the pool by doing ./zfsboottest > > >=20 > Ah, right, those lines were left there by mistake during merge. >=20 > > . This also works correctly when omitting up to two > > vdevs of my RAID-Z2 pool: > >=20 > > # ./zfsboottest /boot/zfsloader /dev/da{0,1,2}p2 2>/dev/null | md5 > > 336c56a04c8d6d432df999b35ce459f7 > > # md5 /boot/zfsloader > > MD5 (/boot/zfsloader) =3D 336c56a04c8d6d432df999b35ce459f7 > >=20 > >=20 > > After applying the patch from [1] (the thread references the same > > output I get, even if the conclusion doesn't fit) I can sometimes > > boot my VM. This seems to correlate with how much is written to the > > pool. Quickly rebooting after the system comes up works, but > > waiting a few minutes always results in getting the mismatch error > > on the reboot. After that only booting with unpatched gptzfsboot > > works (whereafter the patched one works again for one reboot or so). >=20 > Oh, strangeness... Yeah. I'll try applying your patches to head instead of stable/8 in the next days and test that. To make matters easier, can you tell me which revision of head they are based on? Regards Florian --Sig_//+8v1rer=FeMFRn.9d_uvdF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7Q4FgACgkQLvW/2gp2pPyEbACfYIAhVtowcLSjSsDtSPij7pvN 49kAni1M1DfSjNs3Sr5XXrmf37s816gZ =0tQe -----END PGP SIGNATURE----- --Sig_//+8v1rer=FeMFRn.9d_uvdF-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 12:56:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0721065672; Sat, 26 Nov 2011 12:56:55 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 360148FC18; Sat, 26 Nov 2011 12:56:54 +0000 (UTC) Received: by wwe5 with SMTP id 5so3681109wwe.31 for ; Sat, 26 Nov 2011 04:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CxeOAQC0UrI/vOTSisNWOz644yMYc9XhZolDONmpFH0=; b=fHRop2/I2eVOAFwdF1Xz8rnijBrtk7JNZ1z1F1Kg5fhwlGf+TseldvuaTFF6VCdiVL +Pr0BfL5Ck2P/PK5LvmwITBCiWEwZj4vLzwGq+zZydXMUVB5VW3cHe8r2sylBlfUejy8 1tIcX/S9dagU+CUgos9niAu04OIG46l3CWYJw= Received: by 10.180.108.114 with SMTP id hj18mr39201943wib.2.1322312214062; Sat, 26 Nov 2011 04:56:54 -0800 (PST) Received: from [192.168.1.11] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPS id fg15sm7797685wbb.7.2011.11.26.04.56.53 (version=SSLv3 cipher=OTHER); Sat, 26 Nov 2011 04:56:53 -0800 (PST) Message-ID: <4ED0E214.3090506@gmail.com> Date: Sat, 26 Nov 2011 13:56:52 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4ED0949A.8080602@gmail.com> <20111126120727.GB8794@garage.freebsd.pl> In-Reply-To: <20111126120727.GB8794@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek Subject: Re: zvol and zfs send no file on the receiving side. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 12:56:55 -0000 Pawel Jakub Dawidek schreef: > On Sat, Nov 26, 2011 at 08:26:18AM +0100, Johan Hendriks wrote: >> Hello all! >> >> After some reluctance using zfs i decided it was time to just use it, >> and it make my life a lot easier. >> Thank you all ! >> >> One thing i can not get to work however is sending and receiving a zfs >> volume. >> >> I have a master so to say, and a bacup server. >> On the master the pool is named storage, on the backup machine the pool >> is called tank. >> >> on the master i did the following. >> >> # zfs create -V10G storage/iscsitest >> >> if i do a zfs list -t volume, i see that the volume is there. >> >> # zfs list -t volume >> NAME USED AVAIL REFER MOUNTPOINT >> storage/iscsitest 10.3G 65.9G 16K - >> >> If i go to the directory /storage and do a ls -al >> i see my zvol file. >> >> # ls -al >> total 1901416 >> drwxr-xr-x 4 root wheel 5 Nov 25 17:44 . >> drwxr-xr-x 19 root wheel 1024 Nov 25 11:33 .. >> -rw-r--r-- 1 root wheel 10737418240 Nov 25 20:46 iscsitest > Very interesting that you have this file here. It surely wasn't created > by ZFS. ZVOL is not regular file, it is a GEOM provider (disk-like device) > and can be found in /dev/zvol/storage/iscsitest. > I think that the file gets created by the istgt software itself. i set that path in /usr/local/etc/istgt/istgt.conf #LUN0 Storage /storage/iscsitest 10GB That make me think that it was my zvol. Well i am glad this is solved it caused me lot of headache, but i have learned a lot :D Tonight i will try it all! regards and thank you both for your time. Johan Hendriks From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 15:20:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E863106566C for ; Sat, 26 Nov 2011 15:20:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDE858FC08 for ; Sat, 26 Nov 2011 15:20:04 +0000 (UTC) Received: by ghbg20 with SMTP id g20so4719287ghb.13 for ; Sat, 26 Nov 2011 07:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=q4IIkdzrtlXdxe0bEvfIUevVlB3v3vZjx1LQ2pZRPbE=; b=bwWfr0iV8ZBPO4d5QeAYe5/22s2OqidGhnm1PtPGHzuXKztYWBrYjjGOQmXqxfac9r 1nmLd9TzTqHjnhgBZmkubkwx72d/+8lg3R34q74EPO+UulWGZR90sBiTcei8grH5SFSt Jw+oiuahBGig6+/8qdgBIbSynplz4d1lQPNxE= Received: by 10.236.154.42 with SMTP id g30mr55333521yhk.3.1322320804187; Sat, 26 Nov 2011 07:20:04 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.101.134.16 with HTTP; Sat, 26 Nov 2011 07:19:23 -0800 (PST) In-Reply-To: <201111260727.pAQ7Rlh6056867@chez.mckusick.com> References: <201111260727.pAQ7Rlh6056867@chez.mckusick.com> From: Ivan Voras Date: Sat, 26 Nov 2011 16:19:23 +0100 X-Google-Sender-Auth: fFdhagajv21SdMkddLeXU-zOr4Q Message-ID: To: Kirk McKusick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 15:20:05 -0000 On 26 November 2011 08:27, Kirk McKusick wrote: > Your proposed change is definitely useful, though really just applies > to filesystems running without SU and SU+J. The cases where bwrite > are used are when we are using synchronous write to maintain > filesystem consistency (e.g., the filesystem before SU). Ok but I think the question here is: are synchronous writes enough, or a BIO_FLUSH needs to be sent down to the drives at critical moments? You are the best to say what is good for UFS but from what I've learned from other filesystems (including Linux), it seems that all of those use some kind of write barrier / BIO_FLUSH to be safe. Some docs: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarr.html From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 17:12:35 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434321065670; Sat, 26 Nov 2011 17:12:35 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 238078FC12; Sat, 26 Nov 2011 17:12:34 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pAQHCY8G081783; Sat, 26 Nov 2011 09:12:34 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201111261712.pAQHCY8G081783@chez.mckusick.com> To: lev@FreeBSD.org In-reply-to: <147455115.20111126115248@serebryakov.spb.ru> Date: Sat, 26 Nov 2011 09:12:34 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@FreeBSD.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 17:12:35 -0000 Kostik has it right. The requirement for SU and SU+J is simply that the underlying I/O subsystem not issue bio_done on a write until it is on stable store. If the I/O subsystem wants to cache it for a while (multiple seconds) before writing it to disk that is fine (SU thinks in terms of 30-second intervals). The only thing that SU requires is that the subsystem NOT lie by issuing the bio_done before it has committed the data to disk. Perhaps what we need is a "delay acknowledgement until done' flag to make this clear. My previous suggestion of using BIO_BARRIER was just a way to try and enforce this behavior. Based on the performance and other issues raised, this is clearly a bad idea. So, my question to you is how can we reliably get the underlying systems to not lie to us about the stability of our I/O request? Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sat Nov 26 22:47:46 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CB81065670; Sat, 26 Nov 2011 22:47:46 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 390EA8FC08; Sat, 26 Nov 2011 22:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:To:Date:From:Subject:Content-Transfer-Encoding:Content-Type:Mime-Version:In-Reply-To:References; bh=8Um6e29uqcjnkeX1jUGG+zFHrT0p+GOGZwi/KdzYF20=; b=Im+pekVUM9yM7Gpr5eUrRrFARwZ+C7bXl0BT4GSmmy0gtA3yb09UGlOPQ+GuaY72u5f82j1lsEdIFJQoyBWpa5yNVGOfYhzvt9rO+77Z8tN0vN88lLoznw06dxJAYJqg; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RUR28-000KyD-F6; Sat, 26 Nov 2011 16:47:45 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1322347658-1863-1862/5/3; Sat, 26 Nov 2011 22:47:38 +0000 References: <95d00c1b714837aa32e7da72bc4afd03@feld.me> <20111126104840.GA8794@garage.freebsd.pl> User-Agent: K-9 Mail for Android In-Reply-To: <20111126104840.GA8794@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mark Felder Date: Sat, 26 Nov 2011 16:47:35 -0600 To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Message-Id: X-SA-Score: -1.0 Cc: Subject: Re: zfs i/o hangs on 9-PRERELEASE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 22:47:46 -0000 It appears that I'm mistaken about those messages then . However this = does both happen on my AMD x6 and Intel Atom machines with different = hard drives, controllers, etc. I feel it would be unlikely to be = hardware.=20 Unfortunately the procstat command is probably of no use because I can't = interact with the console or ssh for the periods of time when it is = hanging (sometimes in excess of a minute). Zpool scrubs come up clean = and I never see any errors reported. I've been running this hardware for = 2 years and v28 for quite some time. It doesn't seem like it started = happening until I upgraded to a build past RC1. I don't know where to = find RC1 media and I don't know the svn revision of RC1 so I haven't = tried. Regards, Mark