From owner-freebsd-fs@FreeBSD.ORG Sun Sep 19 01:02:30 2010 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 2B934106566B for ; Sun, 19 Sep 2010 01:02:30 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0DCFC8FC12 for ; Sun, 19 Sep 2010 01:02:29 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o8J12T11093786; Sat, 18 Sep 2010 18:02:29 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o8J12TMK093785; Sat, 18 Sep 2010 18:02:29 -0700 (PDT) (envelope-from obrien) Date: Sat, 18 Sep 2010 18:02:29 -0700 From: "David O'Brien" To: Kostik Belousov Message-ID: <20100919010229.GB93245@dragon.NUXI.org> References: <20100917180738.GA51572@dragon.NUXI.org> <20100917190907.GQ2389@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100917190907.GQ2389@deviant.kiev.zoral.com.ua> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-fs@freebsd.org Subject: Re: [PATCH] replace INVARIANTS+panic() with KASSERT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2010 01:02:30 -0000 On Fri, Sep 17, 2010 at 10:09:07PM +0300, Kostik Belousov wrote: > On Fri, Sep 17, 2010 at 11:07:38AM -0700, David O'Brien wrote: > Isn't this reverted ? I believe that all conditions for panics/printf > should be reverted in KASSERTs. Yes, thanks. > > -#ifdef notyet > > - if (bp) > > - brelse(bp); > > -#endif > > Please leave both notyet blocks in indir_trunc() as is. > There are patches in progress that change this fragments, and you > supposedly seen them. Will do. Do you if you will commit them soon? -- -- David (obrien@FreeBSD.org) From owner-freebsd-fs@FreeBSD.ORG Sun Sep 19 01:08:02 2010 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 A6374106564A; Sun, 19 Sep 2010 01:08:02 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 546768FC15; Sun, 19 Sep 2010 01:08:02 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o8J18203093890; Sat, 18 Sep 2010 18:08:02 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o8J182Gf093889; Sat, 18 Sep 2010 18:08:02 -0700 (PDT) (envelope-from obrien) Date: Sat, 18 Sep 2010 18:08:02 -0700 From: "David O'Brien" To: Pawel Jakub Dawidek Message-ID: <20100919010802.GC93245@dragon.NUXI.org> References: <20100917180738.GA51572@dragon.NUXI.org> <20100917191609.GA1902@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100917191609.GA1902@garage.freebsd.pl> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-fs@FreeBSD.org Subject: Re: [PATCH] replace INVARIANTS+panic() with KASSERT X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2010 01:08:02 -0000 On Fri, Sep 17, 2010 at 09:16:09PM +0200, Pawel Jakub Dawidek wrote: > David, have you actually tried to boot with your patch in place? > Every single change you made is wrong. You converted: Yes, caught that after extracting the changes from how I was first testing the change (which had the KASSERT macro as a printf instead of panic). I knew I had more testing to go, but wanted to know if folks thought the changes were positive or if I would get resistance to changing these to KASSERT()s. > One more thing: > > > -#ifdef INVARIANTS > > - if (freeblks->fb_chkcnt != 0 && > > - ((fs->fs_flags & FS_UNCLEAN) == 0 || (flags & LK_NOWAIT) != 0)) > > - printf("handle_workitem_freeblocks: block count\n"); > > -#endif /* INVARIANTS */ > > + KASSERT(freeblks->fb_chkcnt != 0 && > > + ((fs->fs_flags & FS_UNCLEAN) == 0 || (flags & LK_NOWAIT) != 0), > > + ("handle_workitem_freeblocks: block count")); > > You replaced printf() with KASSERT(9) here, not panic(9). Correct. If this is truly an INVARIANTS we should panic. Should the "#ifdef INVARIANTS" be changed to #ifdef DIAGNOSTIC"? -- -- David (obrien@FreeBSD.org) From owner-freebsd-fs@FreeBSD.ORG Sun Sep 19 09:52:02 2010 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 0E9C91065673 for ; Sun, 19 Sep 2010 09:52:02 +0000 (UTC) (envelope-from to.my.trociny@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 94AF78FC1A for ; Sun, 19 Sep 2010 09:52:01 +0000 (UTC) Received: by eyx24 with SMTP id 24so1695564eyx.13 for ; Sun, 19 Sep 2010 02:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:user-agent:mime-version:content-type; bh=Xpnvsz1Q2MWnjP5P14fpF50mWBxgLp2+CPc9I+HpfkM=; b=OLRzFtVi0YswC3HGmD0Lj4//Ilg9Xxx+8P5KtwGBiVVnF5B50C+TP9TbnaAId8QsDQ zCE2rtczL/+a/WAeNPiA3KIcRUiVVvBnhnV0zqgy+3WYGJZI2zWjQuiegTdbxyP/6STD d6jy5jL/sx1SCrbVBa7QqqLj0JdgS/ANteTKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; b=HvGIPMVGRQXx4ZrhCNVuMv4unRyGcKQ+Zpn7dzbo5KJWr0SxAq4BwH46DcPDP8TUE+ w840wiferwVYHPVU2z/V6/7lAt4v5etg+D83qc0sMO0OjW/6Ac+QJBHReHTaw5X6UHxx JdJVEnLat8RUNbzyqf2W/uHiKrAk/3uZQ02XU= Received: by 10.213.46.208 with SMTP id k16mr5751638ebf.20.1284889920252; Sun, 19 Sep 2010 02:52:00 -0700 (PDT) Received: from localhost ([95.69.173.68]) by mx.google.com with ESMTPS id u9sm8972675eeh.23.2010.09.19.02.51.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 19 Sep 2010 02:51:59 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs@freebsd.org Date: Sun, 19 Sep 2010 12:51:54 +0300 Message-ID: <86d3saawn9.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: hastd: possible race when a worker is starting 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, 19 Sep 2010 09:52:02 -0000 Hi, After recent changes in hastd we have the following scenario when a worker process is started: 1) worker process is created; 2) remote connections are established and CONNECT event is sent to parent; 3) threads (among them control thread) are started. Consider a sitution when hastctl request is recevied by parent between (1) and (2). The parent sees that worker is running and sends it a request and waits for a response. The request should be processed by control thread, but it is not started yet. Instead the worker sends CONNECT event and waits for a response from the parent. We have a deadlock. I was able to reproduce this scenario running a script that runs 'hastctl status' requests in background and periodically kills the worker to start a new one: ---------------------------------------------------------------------- #!/bin/sh hastctl role primary storage while true; do hastctl status storage > /dev/null done & while sleep 1; do pid=`ps auxww | awk '/hastd: storage \(primary\)/ {print $2}'` if [ -n "${pid}" ]; then kill "${pid}" sleep 1; npid=`ps auxww | awk '/hastd: storage \(primary\)/ {print $2}'` if [ "${pid}" = "${npid}" ]; then echo "Process ${pid} was not killed" >&2 exit 1 fi fi done ---------------------------------------------------------------------- [root@lolek ~]# ./test_event2.sh Process 17559 was not killed [root@lolek ~]# ps auxww |grep hast root 17563 2.0 0.3 10924 1764 1 S 1:03PM 0:00.01 hastctl status storage root 3334 0.0 0.5 11244 2488 ?? Ss 12:13PM 0:02.06 /sbin/hastd -ddd root 17559 0.0 0.5 11244 2520 ?? S 1:03PM 0:00.01 hastd: storage (primary) (hastd) root 17561 0.0 0.3 10924 1764 1 S 1:03PM 0:00.01 hastctl status storage [root@lolek ~]# gdb /usr/obj/usr/src/sbin/hastd/hastd 3334 (gdb) bt #0 0x28300ed5 in recvfrom () from /lib/libc.so.7 #1 0x28286f52 in recv () from /lib/libc.so.7 #2 0x0805f237 in proto_common_recv (fd=41, data=0xbfbfeaa7 "(", size=5) at /usr/src/sbin/hastd/proto_common.c:77 #3 0x0805f68d in sp_recv (ctx=0x2850e550, data=0xbfbfeaa7 "(", size=5) at /usr/src/sbin/hastd/proto_socketpair.c:185 #4 0x0805ec61 in proto_recv (conn=0x2850e540, data=0xbfbfeaa7, size=5) at /usr/src/sbin/hastd/proto.c:207 #5 0x0804e42e in hast_proto_recv_hdr (conn=0x2850e540, nvp=0xbfbfeae4) at /usr/src/sbin/hastd/hast_proto.c:308 #6 0x0804c83f in control_status_worker (res=0x284eb500, nvout=0x2850e4d0, no=0) at /usr/src/sbin/hastd/control.c:160 #7 0x0804cc9f in control_status (cfg=0x28419600, nvout=0x2850e4d0, res=0x284eb500, name=0x2851042c "storage", no=0) at /usr/src/sbin/hastd/control.c:248 #8 0x0804cfbb in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:348 #9 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 #10 0x0805076d in main (argc=0, argv=0xbfbfecd0) at /usr/src/sbin/hastd/hastd.c:792 [root@lolek ~]# gdb /usr/obj/usr/src/sbin/hastd/hastd 17559 (gdb) bt #0 0x28300ed5 in recvfrom () from /lib/libc.so.7 #1 0x28286f52 in recv () from /lib/libc.so.7 #2 0x0805f237 in proto_common_recv (fd=43, data=0xbfbfe9e7 "(", size=5) at /usr/src/sbin/hastd/proto_common.c:77 #3 0x0805f68d in sp_recv (ctx=0x2850e570, data=0xbfbfe9e7 "(", size=5) at /usr/src/sbin/hastd/proto_socketpair.c:185 #4 0x0805ec61 in proto_recv (conn=0x2850e560, data=0xbfbfe9e7, size=5) at /usr/src/sbin/hastd/proto.c:207 #5 0x0804e42e in hast_proto_recv_hdr (conn=0x2850e560, nvp=0xbfbfea24) at /usr/src/sbin/hastd/hast_proto.c:308 #6 0x0804db3c in event_send (res=0x284eb500, event=1) at /usr/src/sbin/hastd/event.c:69 #7 0x0805a1d1 in init_remote (res=0x284eb500, inp=0x0, outp=0x0) at /usr/src/sbin/hastd/primary.c:671 #8 0x0805a7f4 in hastd_primary (res=0x284eb500) at /usr/src/sbin/hastd/primary.c:810 #9 0x0804c6d5 in control_set_role_common (cfg=0x28419600, nvout=0x2850e4d0, role=2 '\002', res=0x284eb500, name=0x28510442 "storage", no=0) at /usr/src/sbin/hastd/control.c:117 #10 0x0804cf91 in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:344 #11 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 #12 0x0805076d in main (argc=0, argv=0xbfbfecd0) at /usr/src/sbin/hastd/hastd.c:792 This is for primary worker but I believe the same issue is with secondary. The fix would be e.g. to start control thread before sending any event. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Sun Sep 19 09:57:17 2010 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 7ACBF1065670 for ; Sun, 19 Sep 2010 09:57:17 +0000 (UTC) (envelope-from to.my.trociny@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 058D88FC0A for ; Sun, 19 Sep 2010 09:57:16 +0000 (UTC) Received: by eyx24 with SMTP id 24so1696059eyx.13 for ; Sun, 19 Sep 2010 02:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:user-agent:mime-version:content-type; bh=V1GnAy8yQZDuichHOi7I8kJMfFpUaHROTt7qdZ74b00=; b=DFYsvGObfx3xoPGbFlRg7FMgRaqt11YSuOvqWDyHSPTif8OassXOT9nDZcVmukNhfD NH3OJudUq2llXAMFR8ncFsmLuVCsUdQniS9Xi4wHsZuYWYeEpve2HFUpfxCDdG83SNNc VMI0lnOy8Mk+CuB9F+x+rsomsVjXM3AY2piH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; b=L22XJua5tDELXm5sL0jP6XfXq/UQvRTfdNEv9Vw/wKEF0RiRRJ2OtNv09DNSjt/pM4 1iiLtutzadwiUwRmkV0T7ILqi7SOucOw7Rl3BIcB9TKxGV2ONe8/ythE5RB0i9Kui6pz sD97PWGyT0jJoEzXryxsR4r2O/pvKBznpHHak= Received: by 10.213.26.14 with SMTP id b14mr1555930ebc.15.1284890234603; Sun, 19 Sep 2010 02:57:14 -0700 (PDT) Received: from localhost ([95.69.173.68]) by mx.google.com with ESMTPS id z55sm8980146eeh.15.2010.09.19.02.57.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 19 Sep 2010 02:57:13 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs@freebsd.org Date: Sun, 19 Sep 2010 12:57:10 +0300 Message-ID: <868w2yaweh.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: hastd: parent got stuck in waitpid() 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, 19 Sep 2010 09:57:17 -0000 Hi, When trying to produce the scenario described in another thread (hastd: possible race when a worker is starting) I stepped on another issue. I was running the following script: #!/bin/sh for i in `jot 1000`; do hastctl status storage > /dev/null done & for i in `jot 1000`; do hastctl role init storage hastctl role primary storage done Parent hastd got stuck but that time when changing the role to init and terminating the worker: in waitpid() after sending kill() to the worker. It looked like the signal was lost. I don't have a clue how this might happen but it is rather easy reproducible in my environment with the script above. After the hung: [root@lolek /usr/src/sbin/hastctl]# ps auxww |grep hast root 3334 0.0 0.5 11244 2372 ?? Is 12:13PM 0:00.10 /sbin/hastd -ddd root 3473 0.0 7.0 44908 35664 ?? I 12:13PM 0:00.43 hastd: storage (primary) (hastd) root 3474 0.0 0.3 10924 1764 1 I+ 12:13PM 0:00.01 hastctl role init storage root 3475 0.0 0.3 10924 1764 1 I+ 12:13PM 0:00.01 hastctl status storage [root@lolek /usr/src/sbin/hastctl]# gdb /usr/obj/usr/src/sbin/hastd/hastd 3334 [Switching to Thread 28404140 (LWP 100070)] 0x282b9689 in wait4 () from /lib/libc.so.7 (gdb) bt #0 0x282b9689 in wait4 () from /lib/libc.so.7 #1 0x282902a3 in waitpid () from /lib/libc.so.7 #2 0x280de272 in waitpid () from /lib/libthr.so.3 #3 0x0804c664 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=1 '\001', res=0x284eb500, name=0x284a4442 "storage", no=0) at /usr/src/sbin/hastd/control.c:103 #4 0x0804cf91 in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:344 #5 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 #6 0x0805076d in main (argc=0, argv=0xbfbfecd0) at /usr/src/sbin/hastd/hastd.c:792 (gdb) fr 3 #3 0x0804c664 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=1 '\001', res=0x284eb500, name=0x284a4442 "storage", no=0) at /usr/src/sbin/hastd/control.c:103 103 } else if (waitpid(res->hr_workerpid, NULL, 0) != (gdb) list 98 if (res->hr_workerpid != 0) { 99 if (kill(res->hr_workerpid, SIGTERM) < 0) { 100 pjdlog_errno(LOG_WARNING, 101 "Unable to kill worker process %u", 102 (unsigned int)res->hr_workerpid); 103 } else if (waitpid(res->hr_workerpid, NULL, 0) != 104 res->hr_workerpid) { 105 pjdlog_errno(LOG_WARNING, 106 "Error while waiting for worker process %u", 107 (unsigned int)res->hr_workerpid); [root@lolek /usr/src/sbin/hastctl]# gdb /usr/obj/usr/src/sbin/hastd/hastd 3473 Thread 8 (Thread 28404140 (LWP 100079)): #0 0x282a14bb in sigtimedwait () from /lib/libc.so.7 #1 0x280dff3b in sigtimedwait () from /lib/libthr.so.3 #2 0x0805e5ec in guard_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1986 #3 0x0805aa47 in hastd_primary (res=0x284eb500) at /usr/src/sbin/hastd/primary.c:828 #4 0x0804c6d5 in control_set_role_common (cfg=0x28419600, nvout=0x2850e0d0, role=2 '\002', res=0x284eb500, name=0x284a4442 "storage", no=0) at /usr/src/sbin/hastd/control.c:117 #5 0x0804cf91 in control_handle (cfg=0x28419600) at /usr/src/sbin/hastd/control.c:344 #6 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 #7 0x0805076d in main (argc=0, argv=0xbfbfecd0) at /usr/src/sbin/hastd/hastd.c:792 Thread 7 (Thread 28404280 (LWP 100089)): #0 0x2834b233 in ioctl () from /lib/libc.so.7 #1 0x0805b0f4 in ggate_recv_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:943 #2 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #3 0x00000000 in ?? () Thread 6 (Thread 284043c0 (LWP 100090)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x284a14e0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284a14c0 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x284ea110, lock=0x284ea108) at synch.h:149 #12 0x0805b767 in local_send_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1081 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 5 (Thread 28404500 (LWP 100091)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x284a15e0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284a15c0 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x284ea114, lock=0x284ea10c) at synch.h:149 #12 0x0805bd3f in remote_send_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1166 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 4 (Thread 28404640 (LWP 100093)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x284a1660 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284a1640 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x284ea124, lock=0x284ea11c) at synch.h:149 #12 0x0805c58e in remote_recv_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1312 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 3 (Thread 28404780 (LWP 100094)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x284a16e0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284a16c0 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x806ba54, lock=0x806ba50) at synch.h:149 #12 0x0805cc3b in ggate_send_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1432 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 2 (Thread 284048c0 (LWP 100095)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x28bf48e0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284a16c0 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x806ba54, lock=0x806ba50) at synch.h:149 #12 0x0805cc3b in ggate_send_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1432 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 2 (Thread 284048c0 (LWP 100095)): #0 0x280e6ea7 in __error () from /lib/libthr.so.3 #1 0x280e6a88 in __error () from /lib/libthr.so.3 #2 0x28bf48e0 in ?? () ---Type to continue, or q to quit--- #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x28bf48c0 in ?? () #6 0x00000000 in ?? () #7 0xbf4f9e84 in ?? () #8 0x00000000 in ?? () #9 0x280e53ef in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x280e4c8e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x0805b6a8 in cv_wait (cv=0x806ba60, lock=0x806ba5c) at synch.h:149 #12 0x0805d053 in sync_thread (arg=0x284eb500) at /usr/src/sbin/hastd/primary.c:1528 #13 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 1 (Thread 28404a00 (LWP 100096)): #0 0x28300ed5 in recvfrom () from /lib/libc.so.7 #1 0x28286f52 in recv () from /lib/libc.so.7 #2 0x0805f237 in proto_common_recv (fd=33, data=0xbf3f8f47 "", size=5) at /usr/src/sbin/hastd/proto_common.c:77 #3 0x0805f68d in sp_recv (ctx=0x2850e3f0, data=0xbf3f8f47 "", size=5) at /usr/src/sbin/hastd/proto_socketpair.c:185 #4 0x0805ec61 in proto_recv (conn=0x2850e3e0, data=0xbf3f8f47, size=5) at /usr/src/sbin/hastd/proto.c:207 #5 0x0804e42e in hast_proto_recv_hdr (conn=0x2850e3e0, nvp=0xbf3f8f80) at /usr/src/sbin/hastd/hast_proto.c:308 #6 0x0804d0b7 in ctrl_thread (arg=0x284eb500) at /usr/src/sbin/hastd/control.c:385 #7 0x280dc35f in pthread_getprio () from /lib/libthr.so.3 #8 0x00000000 in ?? () -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Mon Sep 20 11:06:55 2010 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 6359F1065705 for ; Mon, 20 Sep 2010 11:06:55 +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 3675D8FC17 for ; Mon, 20 Sep 2010 11:06:55 +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 o8KB6tFK014941 for ; Mon, 20 Sep 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8KB6sCS014939 for freebsd-fs@FreeBSD.org; Mon, 20 Sep 2010 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Sep 2010 11:06:54 GMT Message-Id: <201009201106.o8KB6sCS014939@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, 20 Sep 2010 11:06:55 -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/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/150207 fs zpool import -d /dev tries to open weird devices o kern/149855 fs [gvinum] growfs causes fsck to report errors in Filesy o kern/149495 fs [zfs] chflags sappend on zfs not working right o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/147292 fs [nfs] [patch] readahead missing in nfs client options 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 o kern/146375 fs [nfs] [patch] Typos in macro variables names in sys/fs 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 o 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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 kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in o kern/142914 fs [zfs] ZFS performance degradation over time 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD 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/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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 o 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/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr 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 o 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/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w 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/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs 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 p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files 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/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B 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 mv(1): moving a directory changes its mtime 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 p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex 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 bin/107692 fs newfs(8): newfs -O 1 doesn't create consistent filesys o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic 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 f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in 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/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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 kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi 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 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 kern/33464 fs [ufs] soft update inconsistencies after system crash o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 194 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 20 13:25:14 2010 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 2B117106566C for ; Mon, 20 Sep 2010 13:25:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 793098FC08 for ; Mon, 20 Sep 2010 13:25:13 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 18C3745D8D; Mon, 20 Sep 2010 15:25:12 +0200 (CEST) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7CE2845C9C; Mon, 20 Sep 2010 15:25:06 +0200 (CEST) Date: Mon, 20 Sep 2010 15:24:50 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100920132450.GE2410@garage.freebsd.pl> References: <86d3saawn9.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EXKGNeO8l0xGFBjy" Content-Disposition: inline In-Reply-To: <86d3saawn9.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: possible race when a worker is starting 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, 20 Sep 2010 13:25:14 -0000 --EXKGNeO8l0xGFBjy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 19, 2010 at 12:51:54PM +0300, Mikolaj Golub wrote: > Hi, >=20 > After recent changes in hastd we have the following scenario when a worker > process is started: >=20 > 1) worker process is created; > 2) remote connections are established and CONNECT event is sent to parent; > 3) threads (among them control thread) are started. >=20 > Consider a sitution when hastctl request is recevied by parent between (1= ) and > (2). The parent sees that worker is running and sends it a request and wa= its > for a response. The request should be processed by control thread, but it= is > not started yet. Instead the worker sends CONNECT event and waits for a > response from the parent. We have a deadlock. >=20 > I was able to reproduce this scenario running a script that runs 'hastctl > status' requests in background and periodically kills the worker to start= a > new one: >=20 > ---------------------------------------------------------------------- >=20 > #!/bin/sh >=20 > hastctl role primary storage >=20 > while true; do > hastctl status storage > /dev/null > done & >=20 > while sleep 1; do > pid=3D`ps auxww | awk '/hastd: storage \(primary\)/ {print $2}'` > if [ -n "${pid}" ]; then > kill "${pid}" > sleep 1; > npid=3D`ps auxww | awk '/hastd: storage \(primary\)/ {pri= nt $2}'` > if [ "${pid}" =3D "${npid}" ]; then > echo "Process ${pid} was not killed" >&2 > exit 1 > fi > fi > done >=20 > ---------------------------------------------------------------------- >=20 > [root@lolek ~]# ./test_event2.sh=20 > Process 17559 was not killed >=20 > [root@lolek ~]# ps auxww |grep hast > root 17563 2.0 0.3 10924 1764 1 S 1:03PM 0:00.01 hastctl = status storage > root 3334 0.0 0.5 11244 2488 ?? Ss 12:13PM 0:02.06 /sbin/ha= std -ddd > root 17559 0.0 0.5 11244 2520 ?? S 1:03PM 0:00.01 hastd: s= torage (primary) (hastd) > root 17561 0.0 0.3 10924 1764 1 S 1:03PM 0:00.01 hastctl = status storage >=20 > [root@lolek ~]# gdb /usr/obj/usr/src/sbin/hastd/hastd 3334 >=20 > (gdb) bt > #0 0x28300ed5 in recvfrom () from /lib/libc.so.7 > #1 0x28286f52 in recv () from /lib/libc.so.7 > #2 0x0805f237 in proto_common_recv (fd=3D41, data=3D0xbfbfeaa7 "(", size= =3D5) > at /usr/src/sbin/hastd/proto_common.c:77 > #3 0x0805f68d in sp_recv (ctx=3D0x2850e550, data=3D0xbfbfeaa7 "(", size= =3D5) > at /usr/src/sbin/hastd/proto_socketpair.c:185 > #4 0x0805ec61 in proto_recv (conn=3D0x2850e540, data=3D0xbfbfeaa7, size= =3D5) > at /usr/src/sbin/hastd/proto.c:207 > #5 0x0804e42e in hast_proto_recv_hdr (conn=3D0x2850e540, nvp=3D0xbfbfeae= 4) > at /usr/src/sbin/hastd/hast_proto.c:308 > #6 0x0804c83f in control_status_worker (res=3D0x284eb500, nvout=3D0x2850= e4d0, no=3D0) > at /usr/src/sbin/hastd/control.c:160 > #7 0x0804cc9f in control_status (cfg=3D0x28419600, nvout=3D0x2850e4d0, r= es=3D0x284eb500,=20 > name=3D0x2851042c "storage", no=3D0) at /usr/src/sbin/hastd/control.c= :248 > #8 0x0804cfbb in control_handle (cfg=3D0x28419600) at /usr/src/sbin/hast= d/control.c:348 > #9 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 > #10 0x0805076d in main (argc=3D0, argv=3D0xbfbfecd0) at /usr/src/sbin/has= td/hastd.c:792 >=20 > [root@lolek ~]# gdb /usr/obj/usr/src/sbin/hastd/hastd 17559 >=20 > (gdb) bt > #0 0x28300ed5 in recvfrom () from /lib/libc.so.7 > #1 0x28286f52 in recv () from /lib/libc.so.7 > #2 0x0805f237 in proto_common_recv (fd=3D43, data=3D0xbfbfe9e7 "(", size= =3D5) > at /usr/src/sbin/hastd/proto_common.c:77 > #3 0x0805f68d in sp_recv (ctx=3D0x2850e570, data=3D0xbfbfe9e7 "(", size= =3D5) > at /usr/src/sbin/hastd/proto_socketpair.c:185 > #4 0x0805ec61 in proto_recv (conn=3D0x2850e560, data=3D0xbfbfe9e7, size= =3D5) > at /usr/src/sbin/hastd/proto.c:207 > #5 0x0804e42e in hast_proto_recv_hdr (conn=3D0x2850e560, nvp=3D0xbfbfea2= 4) > at /usr/src/sbin/hastd/hast_proto.c:308 > #6 0x0804db3c in event_send (res=3D0x284eb500, event=3D1) at /usr/src/sb= in/hastd/event.c:69 > #7 0x0805a1d1 in init_remote (res=3D0x284eb500, inp=3D0x0, outp=3D0x0) > at /usr/src/sbin/hastd/primary.c:671 > #8 0x0805a7f4 in hastd_primary (res=3D0x284eb500) at /usr/src/sbin/hastd= /primary.c:810 > #9 0x0804c6d5 in control_set_role_common (cfg=3D0x28419600, nvout=3D0x28= 50e4d0, role=3D2 '\002',=20 > res=3D0x284eb500, name=3D0x28510442 "storage", no=3D0) at /usr/src/sb= in/hastd/control.c:117 > #10 0x0804cf91 in control_handle (cfg=3D0x28419600) at /usr/src/sbin/hast= d/control.c:344 > #11 0x08050357 in main_loop () at /usr/src/sbin/hastd/hastd.c:682 > #12 0x0805076d in main (argc=3D0, argv=3D0xbfbfecd0) at /usr/src/sbin/has= td/hastd.c:792 >=20 > This is for primary worker but I believe the same issue is with secondary. >=20 > The fix would be e.g. to start control thread before sending any event. Thanks for the report and analysis. Could you try this patch: http://people.freebsd.org/~pjd/patches/hastd.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EXKGNeO8l0xGFBjy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyXYKIACgkQForvXbEpPzQYHwCgpmfaPYBLx6+OKpuLh3PZFZsU nn8Ani81FaDawZ/BP53CMWs8e6A7fiG4 =wG3l -----END PGP SIGNATURE----- --EXKGNeO8l0xGFBjy-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 20 15:42:04 2010 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 83C1E1065670; Mon, 20 Sep 2010 15:42:04 +0000 (UTC) (envelope-from to.my.trociny@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 A022C8FC19; Mon, 20 Sep 2010 15:42:03 +0000 (UTC) Received: by eyx24 with SMTP id 24so2022688eyx.13 for ; Mon, 20 Sep 2010 08:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=u0aN8WWkkHoqdx79IiL5UCI57dtZcUql+rFQO5v8oRY=; b=YEEljGodCgLSk96mco/NH2IrX/+qmIJCGPwIhM5xHHXNpa27Qz56OesSj0wwob4fCN GFH2+b4OMLqTUQjgeFttxlcvAXCB2arM3B/RXProindVXU9HteE8HHTvq56JPGkZUNII i3I+/AjkgQ8GxogA0gV8q2QDDsGPps5MKlSdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=cBHxFtNnOl7QQaYujckNVKclgfbJRv/gadmDjfpZnF1g8BX/dB8DRvB5mAeJxTaq1F 2IT3DXGS8gHy27HGiZFWlLUtq0Bwc2A/VmwzD7Wp0yrT0EUFcAXeejd0M6u12Xop2TXP 52C4OX9qXqE9atbuuDeDQcHz5CiYn4C3bAAcQ= Received: by 10.213.32.70 with SMTP id b6mr2989130ebd.19.1284997322483; Mon, 20 Sep 2010 08:42:02 -0700 (PDT) Received: from localhost (vpn-195-69-247-164.customer.onet.com.ua [195.69.247.164]) by mx.google.com with ESMTPS id z55sm11155982eeh.21.2010.09.20.08.42.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 08:42:01 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <86d3saawn9.fsf@kopusha.home.net> <20100920132450.GE2410@garage.freebsd.pl> X-Comment-To: Pawel Jakub Dawidek Date: Mon, 20 Sep 2010 18:41:57 +0300 In-Reply-To: <20100920132450.GE2410@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Mon, 20 Sep 2010 15:24:50 +0200") Message-ID: <86k4mg5smy.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: hastd: possible race when a worker is starting 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, 20 Sep 2010 15:42:04 -0000 On Mon, 20 Sep 2010 15:24:50 +0200 Pawel Jakub Dawidek wrote: PJD> Thanks for the report and analysis. Could you try this patch: PJD> http://people.freebsd.org/~pjd/patches/hastd.patch Before applying the patch I also reproduced deadlock on secondary. After applying the patch I was not able to reproduced the deadlock on both primary and secondary. Also no other new issues have been noticed running patched hastd so far (the problem with hang in wait4() described in other thread persists). So the patch looks good for me :-). -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Mon Sep 20 21:20:39 2010 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 EFF2D106566B for ; Mon, 20 Sep 2010 21:20:38 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFD728FC15 for ; Mon, 20 Sep 2010 21:20:35 +0000 (UTC) Received: by iwn34 with SMTP id 34so5387067iwn.13 for ; Mon, 20 Sep 2010 14:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=XYBCqP87gelRk+hSqM+XaaRKWRcE44XqB7a4n79Phbo=; b=LTSJ83BHF/Ld286D374IaVH0EktMfR3o2k42c6P9BuETZYLnYZwe5ZlLHT2cHh5kWG 28ptOSjiteRA/bKkjDNI2oniNkqxU7EG40RhggYbs3afH7VKTF/z//GbNGtlrFnzS38l Nltuh1ge41srnuWBE7TuWYjqnsWWfJHv42VUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qIf5Aw70lVcSx8OgzQDDu0MVpNinLFY1lRIbGexrH6d6MPUd/TpPAskmlA6h9RtEZ9 QNsx7pby32H2BC75dgyhxDeJpBpwAHBlZnkZ5OBMhzAk146AiRLjupVbXW7Nb+b2G5Zw HBx8aYQhJ0+TGqtNWgexunh3Jh77l5v028sPw= MIME-Version: 1.0 Received: by 10.231.190.149 with SMTP id di21mr10672241ibb.166.1285016201513; Mon, 20 Sep 2010 13:56:41 -0700 (PDT) Received: by 10.231.206.145 with HTTP; Mon, 20 Sep 2010 13:56:41 -0700 (PDT) Date: Mon, 20 Sep 2010 15:56:41 -0500 Message-ID: From: Jamie Ostrowski To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: understanding block distribution in UFS2 filesystems 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, 20 Sep 2010 21:20:39 -0000 I thought I understood how block distribution in UFS2 filesystems work, until I tried running dumpfs on one of my filesystems. The output really confused me, and the man page doesn't get into detail in explaining the output. Can anyone explain why I am seeing references to the same "free blocks" in different cylinder groups? I thought that the block numbers were unique across the entire filesystem, but from the output of dumpfs, I see references to free blocks 0-7 in almost every cylinder group. So are the blocks that are in each cylinder group numbered start over with a new block 0 in each cylinder group? In other words, which picture below is true, A, or B: Cylinder group 0: Uses blocks 0-4000 Cylinder group 1: Uses blocks 4001-8000 Cylinder group 2: Uses blocks 8001-12000 OR -- B: Cylinder group 0: Uses blocks 0-4000 Cylinder group 1: Uses blocks 0-8000 Cylinder group 2: Uses blocks 0-7000 (IE in that sense blocks must be referenced not only by the block number but by the cylinder group they are in) I sure hope so, otherwise I am completely lost on this dumpfs output. Thanks to anyone who can help clear up some of this confusion. - Jamie From owner-freebsd-fs@FreeBSD.ORG Mon Sep 20 22:40:53 2010 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 E7E73106566C for ; Mon, 20 Sep 2010 22:40:53 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id 816438FC0C for ; Mon, 20 Sep 2010 22:40:53 +0000 (UTC) Received: (qmail 88856 invoked by uid 2000); 20 Sep 2010 22:40:52 -0000 Date: Mon, 20 Sep 2010 17:40:52 -0500 From: "Rick C. Petty" To: Jamie Ostrowski Message-ID: <20100920224052.GA88762@rix.kiwi-computer.com> 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: understanding block distribution in UFS2 filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 22:40:54 -0000 On Mon, Sep 20, 2010 at 03:56:41PM -0500, Jamie Ostrowski wrote: > I thought I understood how block distribution in UFS2 filesystems work, > until I tried running dumpfs on one of my filesystems. The output really > confused me, and the man page doesn't get into detail in explaining the > output. Can anyone explain why I am seeing references to the same "free > blocks" in different cylinder groups? > > I thought that the block numbers were unique across the entire > filesystem, but from the output of dumpfs, I see references to free blocks > 0-7 in almost every cylinder group. I suspect the block numbers (which are actually fragment numbers) are relative to each cylinder group. Blocks 0-7 are free in all cylinder groups except the first one, which is used for bootstrap. > So are the blocks that are in each cylinder group numbered start over > with a new block 0 in each cylinder group? > > In other words, which picture below is true, A, or B: > > > Cylinder group 0: Uses blocks 0-4000 > Cylinder group 1: Uses blocks 4001-8000 > Cylinder group 2: Uses blocks 8001-12000 This is correct. Each cylinder group contains its own bitmap of free space, a copy of the super block, and the inodes for that group. -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 09:38:38 2010 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 DB159106564A; Tue, 21 Sep 2010 09:38:38 +0000 (UTC) (envelope-from prvs=1880be0987=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 41F098FC22; Tue, 21 Sep 2010 09:38:38 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 10:27:44 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 10:27:41 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011281280.msg; Tue, 21 Sep 2010 10:27:41 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1880be0987=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> Date: Tue, 21 Sep 2010 10:27:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 09:38:38 -0000 Ok here's the results from without limiting ARC in anyway in loader.conf ARC Size: Current Size: 15.08% 1544.27M (arcsize) Target Size: (Adaptive) 15.08% 1544.47M (c) Min Size (Hard Limit): 12.50% 1280.00M (c_min) Max Size (High Water): ~8:1 10240.00M (c_max) Mem: 40M Active, 4849M Inact, 1671M Wired, 199M Cache, 20M Buf, 159M Free Swap: 4096M Total, 784K Used, 4095M Free So in effect we have a machine with 7GB of RAM but we are only getting 1.5GB worth of caching, the rest is being eaten up by memory sendfile forces into Inact and ARC never seems to push back to balance this out :( Next test is going to be sendfile off but keeping no manual tuning. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 09:49:08 2010 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 AC987106564A for ; Tue, 21 Sep 2010 09:49:08 +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 E8C638FC12 for ; Tue, 21 Sep 2010 09:49:07 +0000 (UTC) Received: from porto.topspin.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 MAA01524; Tue, 21 Sep 2010 12:49:05 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OxzTF-000Nww-4b; Tue, 21 Sep 2010 12:49:05 +0300 Message-ID: <4C987F90.6000006@freebsd.org> Date: Tue, 21 Sep 2010 12:49:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> In-Reply-To: <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 09:49:08 -0000 on 21/09/2010 12:27 Steven Hartland said the following: > forces into Inact and ARC never seems to push back to balance this out :( Just a general note here. ARC is not designed to "push back". It's designed to give up memory under pressure, it's designed to expand into free space, it's not designed to create the pressure. Incorrect language produces incorrect perception resulting in incorrect expectations. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 09:52:03 2010 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 D850B106566C for ; Tue, 21 Sep 2010 09:52:03 +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 1F19F8FC16 for ; Tue, 21 Sep 2010 09:52:02 +0000 (UTC) Received: from porto.topspin.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 MAA01614; Tue, 21 Sep 2010 12:51:59 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OxzW3-000Nx8-KQ; Tue, 21 Sep 2010 12:51:59 +0300 Message-ID: <4C98803F.7000901@freebsd.org> Date: Tue, 21 Sep 2010 12:51:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> In-Reply-To: <4C987F90.6000006@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 09:52:03 -0000 on 21/09/2010 12:49 Andriy Gapon said the following: > on 21/09/2010 12:27 Steven Hartland said the following: >> forces into Inact and ARC never seems to push back to balance this out :( > > Just a general note here. > ARC is not designed to "push back". It's designed to give up memory under > pressure, it's designed to expand into free space, it's not designed to create > the pressure. > Incorrect language produces incorrect perception resulting in incorrect > expectations. > I guess what I wanted to say is - why do you want ARC to grow more in this case? When you know that the data that sendfile uses is in those Inactive pages. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 10:55:18 2010 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 6944F1065673; Tue, 21 Sep 2010 10:55:18 +0000 (UTC) (envelope-from prvs=1880be0987=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C85BF8FC14; Tue, 21 Sep 2010 10:55:17 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 11:55:12 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 11:55:12 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011281684.msg; Tue, 21 Sep 2010 11:55:11 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1880be0987=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> Date: Tue, 21 Sep 2010 11:55:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 10:55:18 -0000 ----- Original Message ----- From: "Andriy Gapon" To: "Steven Hartland" Cc: Sent: Tuesday, September 21, 2010 10:51 AM Subject: Re: zfs very poor performance compared to ufs due to lack of cache? > on 21/09/2010 12:49 Andriy Gapon said the following: >> on 21/09/2010 12:27 Steven Hartland said the following: >>> forces into Inact and ARC never seems to push back to balance this out :( >> >> Just a general note here. >> ARC is not designed to "push back". It's designed to give up memory under >> pressure, it's designed to expand into free space, it's not designed to create >> the pressure. >> Incorrect language produces incorrect perception resulting in incorrect >> expectations. It was my understanding that ARC when looking for available memory took Inactive pages into account? > I guess what I wanted to say is - why do you want ARC to grow more in this case? > When you know that the data that sendfile uses is in those Inactive pages. Well my understanding thus far, correct me if this is wrong, is that unless the data in the memory populated by the use of sendfile "matches" those in ARC, having it occupy that memory is pointless as it will never get used? If this is the case all you will see is a cycling of memory use for different files and the overall result will be that only ever 1.5G of files are actually cached, everything else must still be read from disk "and" copied in memory before being sent? What I would expect is the natural balance to be achieved, with Inactive pages and ARC having an pretty even split. So on this machine with 7G say 500M possibly 1G general overhead at a real push it would result in 3G Inactive pages from sendfile matching the 3G of ARC? ATM the only way to achieve this seems to be to manually tune min arc setting to this level? Sorry this is all questions, as I really don't have a clear picture of how this all works :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 11:07:49 2010 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 84D181065670 for ; Tue, 21 Sep 2010 11:07:49 +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 C14438FC12 for ; Tue, 21 Sep 2010 11:07:48 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA03510; Tue, 21 Sep 2010 14:07:45 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C989201.20506@freebsd.org> Date: Tue, 21 Sep 2010 14:07:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> In-Reply-To: <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 11:07:49 -0000 on 21/09/2010 13:55 Steven Hartland said the following: > > ----- Original Message ----- From: "Andriy Gapon" > To: "Steven Hartland" > Cc: > Sent: Tuesday, September 21, 2010 10:51 AM > Subject: Re: zfs very poor performance compared to ufs due to lack of cache? > > >> on 21/09/2010 12:49 Andriy Gapon said the following: >>> on 21/09/2010 12:27 Steven Hartland said the following: >>>> forces into Inact and ARC never seems to push back to balance this out :( >>> >>> Just a general note here. >>> ARC is not designed to "push back". It's designed to give up memory under >>> pressure, it's designed to expand into free space, it's not designed to create >>> the pressure. >>> Incorrect language produces incorrect perception resulting in incorrect >>> expectations. > > It was my understanding that ARC when looking for available memory took Inactive > pages into account? In what sense? Inactive is not free. Inactive pages are as used as ARC pages. >> I guess what I wanted to say is - why do you want ARC to grow more in this case? >> When you know that the data that sendfile uses is in those Inactive pages. > > Well my understanding thus far, correct me if this is wrong, is that unless the data > in the memory populated by the use of sendfile "matches" those in ARC, having it > occupy that memory is pointless as it will never get used? I don't follow your use of word "matches". As long as data populated by sendfile is in memory (using your terminology) sendfile is able to re-use it without additional trips to ARC or to disk. > If this is the case all you will see is a cycling of memory use for different > files and the > overall result will be that only ever 1.5G of files are actually cached, > everything else > must still be read from disk "and" copied in memory before being sent? Inactive is also a cache. > What I would expect is the natural balance to be achieved, with Inactive pages and > ARC having an pretty even split. So on this machine with 7G say 500M possibly 1G > general overhead at a real push it would result in 3G Inactive pages from sendfile > matching the 3G of ARC? > > ATM the only way to achieve this seems to be to manually tune min arc setting to this > level? > > Sorry this is all questions, as I really don't have a clear picture of how this > all works :( Yes, you really need to understand how VM works first. Think of "what sendfile populates" as L1 cache and ARC as L2 cache with inclusive relation-ship (i.e. the same data can be in both). The differences from CPUs is that balance of sizes between L1 and L2 is established dynamically. Another difference is that some operations like read(2) bypass L1 and go to L2 directly. If you use operations that work through L1 and most of your data is already in L1, then why you'd want L2 to be large? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 11:25:07 2010 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 457661065670; Tue, 21 Sep 2010 11:25:07 +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 4760A8FC0A; Tue, 21 Sep 2010 11:25:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA03935; Tue, 21 Sep 2010 14:25:03 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C98960F.9020404@freebsd.org> Date: Tue, 21 Sep 2010 14:25:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Andre Oppermann References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90E328.20606@freebsd.org> <4C90E869.8000400@freebsd.org> <4C90EDA1.6020501@freebsd.org> <4C90F4F6.209@freebsd.org> In-Reply-To: <4C90F4F6.209@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org, Konstantin Belousov Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 11:25:07 -0000 on 15/09/2010 19:31 Andriy Gapon said the following: > on 15/09/2010 19:00 Andre Oppermann said the following: >> Is there a quick way of deciding within sendfile(2) whether a file resides >> on a filesystem that doesn't use the buffer cache? > > I don't know of any reliable way to do it. > If I understood correctly what Kostik suggested in a chat, then we could abstract core sendfile<->vm<->fs logic into a new vop, say vop_sendpages (don't mind the name much). std_sendpages would do what code in kern_sendfile does today and would be used by most of filesystems. But some filesystems could override it e.g. to avoid using VM page cache. Or, perhaps, we could even add EXT_ZFSARC type of mbuf that would know how to work with data buffers held in ARC and unhold them when done. That would make sendfile work on ZFS through a single cache. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 12:03:04 2010 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 1E7791065670; Tue, 21 Sep 2010 12:03:04 +0000 (UTC) (envelope-from prvs=1880be0987=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7DF7E8FC13; Tue, 21 Sep 2010 12:03:03 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 13:02:58 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 13:02:58 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011281927.msg; Tue, 21 Sep 2010 13:02:56 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1880be0987=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andriy Gapon" References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C85E91E.1010602@icyb.net.ua><4C873914.40404@freebsd.org><20100908084855.GF2465@deviant.kiev.zoral.com.ua><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> <4C989201.2 0506@freebsd.org> Date: Tue, 21 Sep 2010 13:02:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 12:03:04 -0000 ----- Original Message ----- From: "Andriy Gapon" > Yes, you really need to understand how VM works first. > Think of "what sendfile populates" as L1 cache and ARC as L2 cache with inclusive > relation-ship (i.e. the same data can be in both). The differences from CPUs is > that balance of sizes between L1 and L2 is established dynamically. Another > difference is that some operations like read(2) bypass L1 and go to L2 directly. > If you use operations that work through L1 and most of your data is already in L1, > then why you'd want L2 to be large? Thanks for bearing with me, I think a quick example might help explain my understanding to which I hope you will correct me ;-) We have nginx serving some files and we have:- * machine with 7G RAM * file1 & file2 both 1GB in size * max ARC can grow to is 1.5GB * Inactive can grow to 5GB Now the process:- First client requests file1, its loaded from disk into ARC and then transferred and in doing so populates pages which are "inactive" Client 1 result: * all of file1 in ARC and in Inactive Second client requests file2, its also loaded into ARC, pushing 500MB of file1 out as max ARC is 1.5GB, it is then transferred and hence populates inactive pages. Client 2 result: * half of file1 in ARC but all still in Inactive * all of file2 in ARC and Inactive Third client requests file1, now what happens here? Do we have to go back to disk to get the 500MB of file1 which is now not in ARC or is the file transferred directly from the Inactive pages which where never touched? >From my tests it seems that to serve a file to a client using sendfile without having to read it from disk you need said file in ARC. See sendfile on and primarycache set to metadata results. So to use your caching analogy it seems that sendfile cant use the L1 cache unless its also present in L2 for whatever reason. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 12:19:11 2010 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 1537C106566C for ; Tue, 21 Sep 2010 12:19:11 +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 51BD28FC14 for ; Tue, 21 Sep 2010 12:19:10 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA05141; Tue, 21 Sep 2010 15:19:06 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C98A2BA.1080004@freebsd.org> Date: Tue, 21 Sep 2010 15:19:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> <4C989201.2 0506@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 12:19:11 -0000 on 21/09/2010 15:02 Steven Hartland said the following: > ----- Original Message ----- From: "Andriy Gapon" > >> Yes, you really need to understand how VM works first. >> Think of "what sendfile populates" as L1 cache and ARC as L2 cache with inclusive >> relation-ship (i.e. the same data can be in both). The differences from CPUs is >> that balance of sizes between L1 and L2 is established dynamically. Another >> difference is that some operations like read(2) bypass L1 and go to L2 directly. >> If you use operations that work through L1 and most of your data is already in L1, >> then why you'd want L2 to be large? > > Thanks for bearing with me, I think a quick example might help explain my > understanding > to which I hope you will correct me ;-) > > We have nginx serving some files and we have:- > * machine with 7G RAM > * file1 & file2 both 1GB in size > * max ARC can grow to is 1.5GB > * Inactive can grow to 5GB > > Now the process:- > First client requests file1, its loaded from disk into ARC and then transferred and > in doing so populates pages which are "inactive" > > Client 1 result: > * all of file1 in ARC and in Inactive > > Second client requests file2, its also loaded into ARC, pushing 500MB of file1 out > as max ARC is 1.5GB, it is then transferred and hence populates inactive pages. > > Client 2 result: > * half of file1 in ARC but all still in Inactive > * all of file2 in ARC and Inactive > > Third client requests file1, now what happens here? Do we have to go back to disk to > get the 500MB of file1 which is now not in ARC or is the file transferred directly > from > the Inactive pages which where never touched? Yes, it should be transferred from the Inactive cache. > From my tests it seems that to serve a file to a client using sendfile without > having to > read it from disk you need said file in ARC. See sendfile on and primarycache set to > metadata results. Yeah, I am puzzled by that. But, OTOH, I don't know that feature of ZFS well enough to say what additional pessimizations may have happened. > So to use your caching analogy it seems that sendfile cant use the L1 cache unless > its also present in L2 for whatever reason. It's possible that this is how it works for you because of some bug. But I don't see anything in the code that would lead to that behavior _after_ the change that was committed in r212650. Change in r212782 might be useful too. In VM theory the data should be just taken from "L1" aka "Inactive" aka page cache. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 13:53:50 2010 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 8CED21065672; Tue, 21 Sep 2010 13:53:50 +0000 (UTC) (envelope-from prvs=1880be0987=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id E82378FC18; Tue, 21 Sep 2010 13:53:49 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 14:53:44 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 21 Sep 2010 14:53:39 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011282452.msg; Tue, 21 Sep 2010 14:53:38 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1880be0987=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andriy Gapon" References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C874F00.3050605@freebsd.org><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> <4C989201.2 0506@freebsd.org> <4C98A2BA.1080004@freebsd.org> Date: Tue, 21 Sep 2010 14:53:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 13:53:50 -0000 ----- Original Message ----- From: "Andriy Gapon" >> From my tests it seems that to serve a file to a client using sendfile without >> having to >> read it from disk you need said file in ARC. See sendfile on and primarycache set to >> metadata results. > > Yeah, I am puzzled by that. > But, OTOH, I don't know that feature of ZFS well enough to say what additional > pessimizations may have happened. Anyone else care to comment on this? >> So to use your caching analogy it seems that sendfile cant use the L1 cache unless >> its also present in L2 for whatever reason. > > It's possible that this is how it works for you because of some bug. > But I don't see anything in the code that would lead to that behavior _after_ the > change that was committed in r212650. Change in r212782 might be useful too. > > In VM theory the data should be just taken from "L1" aka "Inactive" aka page cache. That's what I thought you where saying. Is there a test you would suggest to confirm either way more accurately? What springs to mind is setting primarycache to metadata and requesting a large single file multiple times and see if disk access is zero on the repeat requests. If this turns out to be the case does anyone have an idea where the issue would be? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 14:23:13 2010 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 E057C106564A for ; Tue, 21 Sep 2010 14:23:13 +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 2ABB48FC19 for ; Tue, 21 Sep 2010 14:23:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07914; Tue, 21 Sep 2010 17:23:10 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4C98BFCE.2020202@freebsd.org> Date: Tue, 21 Sep 2010 17:23:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Steven Hartland References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><4C8D087B.5040404@freebsd.org><03537796FAB54E02959E2D64FC83004F@multiplay.co.uk><4C8D280F.3040803@freebsd.org><3FBF66BF11AA4CBBA6124CA435A4A31B@multiplay.co.uk><4C8E4212.30000@freebsd.org> <4C90B4C8.90203@freebsd.org> <6DFACB27CA8A4A22898BC81E55C4FD36@multiplay.co.uk> <4C90D3A1.7030008@freebsd.org> <0B1A90A08DFE4ADA9540F9F3846FDF38@multiplay.co.uk> <4C90EDB8.3040709@freebsd.org> <3F29E8CED7B24805B2D93F62A4EC9559@multiplay.co.uk> <4C9126FB.2020707@freebsd.org> <1E0B9C1145784776A773B99FC1139CD5@multiplay.co.uk> <4C987F90.6000006@freebsd.org> <4C98803F.7000901@freebsd.org> <879BF5981D1B4C7290BDF18286BA1EEC@multiplay.co.uk> <4C989201.2 0506@freebsd.org> <4C98A2BA.1080004@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? 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, 21 Sep 2010 14:23:14 -0000 on 21/09/2010 16:53 Steven Hartland said the following: > That's what I thought you where saying. Is there a test you would suggest to confirm > either way more accurately? Perhaps you can try the test scenario that you described and monitor parameters suggested by Wiktor in this thread. That is, have two large files and set arc max size such that one of them can fit in ARC readily, but two of them won't fit by a large margin. Make sure that remaining RAM is large enough to hold both files in page cache. 1. sendfile one file, then the other 2. record kstat.zfs.misc.arcstats values 3. sendfile the first file again 4. record kstat.zfs.misc.arcstats values If the first file data was re-used from page cache, then you won't see much changes in kstat.zfs.misc.arcstats. If it had to be taken from ARC or from disk, then either ARC hits or ARC misses will grow noticeably. Make sure to not have any parallel activity that could affect kstat.zfs.misc.arcstats. I think kstat.zfs.misc.arcstats.hits and kstat.zfs.misc.arcstats.misses are two primary indicators in this test. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 19:12:36 2010 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 2B1EC1065783 for ; Tue, 21 Sep 2010 19:12:36 +0000 (UTC) (envelope-from zbeeble@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 D2D958FC0A for ; Tue, 21 Sep 2010 19:12:35 +0000 (UTC) Received: by gyg4 with SMTP id 4so2181403gyg.13 for ; Tue, 21 Sep 2010 12:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=cYMq4J4Vb9Kk8hV1x07l9du5alWjD1IWbMqm8JgvQMs=; b=RzyiZvyTxgOe6jqnSmtBA5Jz6yHndQwY8N0XmdDfwyYa0qfBoE22rMMbayZyBU2eH9 zxjrWLr9un/Xmljm78/rIlWMDebfBp/H6UvzSrEtAspjmsIPNyz8t2FNZUia3gXeE31Q BG7BGKvwHMQoCeGljAqCj8Ju2W76NHbBYjJpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eGB3nvWwzsJgh3RN1G8UA9+J3dAEavuiEfUzr5cMjto1yCoQNMMkSVo1Cg4Cxexjts /nJw3cAjBHAvoM6ch9nMfyt7nXeaL8KOjadpEd9hMa18ad6lfjqn2dMvkpRxXqvLAHGK 7wkcNoJ5tuqvvxZ2dYDaK2y8RPR/kgNCcHGVc= MIME-Version: 1.0 Received: by 10.151.144.11 with SMTP id w11mr11717100ybn.313.1285094744942; Tue, 21 Sep 2010 11:45:44 -0700 (PDT) Received: by 10.151.39.7 with HTTP; Tue, 21 Sep 2010 11:45:44 -0700 (PDT) Date: Tue, 21 Sep 2010 14:45:44 -0400 Message-ID: From: Zaphod Beeblebrox To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Oracle to deny deduplication? 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, 21 Sep 2010 19:12:36 -0000 I was poking at a few things today as I was waiting for "zfs update -r" to finish ... which included investigating which zfs features were related to which versions. I was looking for a nice table. On the way to finding a nice table, I crossed this partially complete freebsd-centric table: http://old.nabble.com/ZFS-version-info-td27466164.html ... note from here that deduplication features are introduced in version 21. Something I noticed because I follow -current and I'm interested in the feature. Shortly thereafter I found a nice table (here: http://docs.sun.com/app/docs/doc/819-5461/appendixa-1?a=view ) ... now notice that the official Oracle table lists version 21 of zpool as "Reserved" ... this worries me. Is the solution to the lawsuit against Sun by NetApp (that Oracle settled) that Oracle burys deduplication? This could be bad for people who unbury it. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 19:21:41 2010 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 DC2EA106566C for ; Tue, 21 Sep 2010 19:21:41 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 75C6F8FC1A for ; Tue, 21 Sep 2010 19:21:41 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id o8LJLeKl007477; Tue, 21 Sep 2010 14:21:40 -0500 (CDT) Date: Tue, 21 Sep 2010 14:21:40 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Zaphod Beeblebrox In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Tue, 21 Sep 2010 14:21:40 -0500 (CDT) Cc: freebsd-fs Subject: Re: Oracle to deny deduplication? 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, 21 Sep 2010 19:21:41 -0000 On Tue, 21 Sep 2010, Zaphod Beeblebrox wrote: > > Shortly thereafter I found a nice table (here: > http://docs.sun.com/app/docs/doc/819-5461/appendixa-1?a=view ) > > ... now notice that the official Oracle table lists version 21 of > zpool as "Reserved" ... this worries me. Is the solution to the > lawsuit against Sun by NetApp (that Oracle settled) that Oracle burys > deduplication? This could be bad for people who unbury it. I think that this is just because Solaris 10 Update 9 is recently released and deduplication is not considered robust enough for production use yet. You are looking at a Solaris 10 document. The easy solution was to simply mask it out. The deduplication code is likely still active in Solaris 10 Update 9 zfs, even if it can't be enabled by it. No worries ... Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Tue Sep 21 22:38:23 2010 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 E2CCC1065673 for ; Tue, 21 Sep 2010 22:38:23 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE858FC18 for ; Tue, 21 Sep 2010 22:38:23 +0000 (UTC) Received: by eyx24 with SMTP id 24so2658130eyx.13 for ; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.16.207 with SMTP id p15mr4801280eba.61.1285108702292; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) Received: by 10.14.29.76 with HTTP; Tue, 21 Sep 2010 15:38:22 -0700 (PDT) X-Originating-IP: [69.91.158.134] In-Reply-To: <20100917161847.GA58503@icarus.home.lan> References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> Date: Tue, 21 Sep 2010 15:38:22 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 21 Sep 2010 22:38:24 -0000 On Fri, Sep 17, 2010 at 9:18 AM, Jeremy Chadwick wrote: > Given the severity of this predicament, then why is it people are > disabling the ZIL (via vfs.zfs.zil_disable=1) ? If you don't have a separate log device, synchronous writes are very slow with the ZIL enabled. This isn't such a big deal unless you're using NFS, where essentially every write is synchronous. Then many common operations become conspicuously slow, especially compared to Linux, which isn't as fastidious about requiring data to be flushed all the way to the platters before signaling to NFS clients that the operation is complete. The danger in this case isn't that the pool could be damaged, but that a server crash could result in data not being written to disk even though the client believes the operation completed successfully; essentially, this would be silent data loss, since NFS server reboots are supposed to be invisible to client applications. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 04:26:21 2010 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 2CFAE106564A for ; Wed, 22 Sep 2010 04:26:21 +0000 (UTC) (envelope-from zbeeble@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 DAC898FC14 for ; Wed, 22 Sep 2010 04:26:20 +0000 (UTC) Received: by gyg4 with SMTP id 4so43049gyg.13 for ; Tue, 21 Sep 2010 21:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ot+oAZOZwQtsY/93O6PWhaLFFz9cZgbFcjvoPpeOmo4=; b=i6wvcJn9vTpjk2cSEyy0G8pcllY9QoagsTmc6lgjtFfrEK5VsY1xYX4mqzxiTSgcPI GZ2yCZ2o3ONzgxN9hjuqYcOzE3mEksbIxH75e+o9Vtzi8RC3mRgIaTK6lu9OCeBZYtI2 gRBzdAl4OtDcK5nIJvhkUHQJ1iHdGoqAT3jvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nK2j2KTk/hpBtRQeOcRnwE2EU8lH2QnsvPMU5NvrxH+6wiCxATf5dBN2jZ9k62Nenm o3uBat4mK27I/xsqSQJAMsGP+qHihRJMhpcfbbwF89ipIuAV9ycVCCuzkYDartkJybJI XA2vUu9CCWhceeWgV167BI7530blTMFxOpUxs= MIME-Version: 1.0 Received: by 10.150.216.7 with SMTP id o7mr385740ybg.199.1285129580034; Tue, 21 Sep 2010 21:26:20 -0700 (PDT) Received: by 10.151.39.7 with HTTP; Tue, 21 Sep 2010 21:26:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Sep 2010 00:26:20 -0400 Message-ID: From: Zaphod Beeblebrox To: Bob Friesenhahn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs Subject: Re: Oracle to deny deduplication? 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, 22 Sep 2010 04:26:21 -0000 On Tue, Sep 21, 2010 at 3:21 PM, Bob Friesenhahn wrote: > On Tue, 21 Sep 2010, Zaphod Beeblebrox wrote: >> >> Shortly thereafter I found a nice table (here: >> http://docs.sun.com/app/docs/doc/819-5461/appendixa-1?a=3Dview ) >> >> ... now notice that the official Oracle table lists version 21 of >> zpool as "Reserved" ... this worries me. =A0Is the solution to the >> lawsuit against Sun by NetApp (that Oracle settled) that Oracle burys >> deduplication? =A0This could be bad for people who unbury it. > > I think that this is just because Solaris 10 Update 9 is recently release= d > and deduplication is not considered robust enough for production use yet. > =A0You are looking at a Solaris 10 document. =A0The easy solution was to = simply > mask it out. =A0The deduplication code is likely still active in Solaris = 10 > Update 9 zfs, even if it can't be enabled by it. > > No worries ... Even if you are correct, I'm still quite wary of Oracle's support of ZFS. Oracle is not known as a "nice" entity. But how would that work --- if you update the pool to 23 (22 or 23 is the latest listed there?) then a filesystem with dedup would be read ... but you might not be able to set the attribute? Seems odd. The ZFS implementation of dedup seems so "sensible" ... From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 04:31:57 2010 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 E8B6E1065673 for ; Wed, 22 Sep 2010 04:31:56 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2BE98FC23 for ; Wed, 22 Sep 2010 04:31:56 +0000 (UTC) Received: by iwn34 with SMTP id 34so216975iwn.13 for ; Tue, 21 Sep 2010 21:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=nn6amIezLyWCb9Pv0atapKiJnDcv1dxmWiZOti1YUGM=; b=pWsrh4brRBbLCCeSwBC1LGtqITiIjVcpqjHigpoR9bHgnxsj318Z6n7JUe93vainST f432tuX5MEjas488C5+AM4rTm2rkCng6HdF89JXp3I9zsJZmy8v9oMBgjpX5W26hcKEU k/yiTDgDZybxaZnQFssubXxm722/+jWRzRo6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uZI6NctHtu35GbhTgYKWTv3st9f/ZWA9rrqosvmeTy/akRegnrWd2bHh86z/OrROAE R8i9+EMDouHqRp3Xs3/ECeCqmmmsRdW/s5ni9/BfVPugzPoRFLneSxO714rOa6Jhfc8P j2bKmTeMWIuhssn5K9/HuAMTJ/Vp21criBXao= MIME-Version: 1.0 Received: by 10.231.32.130 with SMTP id c2mr8309794ibd.28.1285129907584; Tue, 21 Sep 2010 21:31:47 -0700 (PDT) Received: by 10.231.177.162 with HTTP; Tue, 21 Sep 2010 21:31:46 -0700 (PDT) Date: Wed, 22 Sep 2010 00:31:46 -0400 Message-ID: From: Adam Stylinski To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 22 Sep 2010 04:31:57 -0000 If I remember correctly, what actually happens is the pending transaction group never gets committed and that data becomes corrupted. The pool should be fully accessible and operational so long as it's never exported as it will fault back to disks for the intent log. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 05:52:09 2010 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 62806106566C for ; Wed, 22 Sep 2010 05:52:09 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 163658FC16 for ; Wed, 22 Sep 2010 05:52:08 +0000 (UTC) Received: by gxk8 with SMTP id 8so57912gxk.13 for ; Tue, 21 Sep 2010 22:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3n1UFVdyTP1b/N0pOkNC7SOFdPasy27ANQjcd71izPg=; b=xj8osXcB1tUwfBICNSHoTH/1Fg+Q9cN9SiJvsY+c7c82RPqAlguqYyKqgBrL8DmvQl up7K6WoQN3JAgVok+L8h44Q9xNgTUrBrcj/hwjQ1ADt1zIfj0+FoimJTv0Y4Zb2xspbt l//9UXUCoE6P2pAou4uJxS+C2561evL1JhVzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kyefs61N8hegzRWY655Gl47xHIzE1IwDd2ilgt1Nt8QMosFd8/eHFDGfZw0OA8tIBE wXsRo5R9QMJaZjDFWn97MTvj2IYtTqJg8SiAofTPB52SkWFGrr8aBj5u2ec+BudAmCe7 MxtDugK/aDRs4axUDGob+WOl/VRz6VuI9J7tE= Received: by 10.150.157.8 with SMTP id f8mr438773ybe.367.1285134728262; Tue, 21 Sep 2010 22:52:08 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-130-119.dsl.klmzmi.sbcglobal.net [99.181.130.119]) by mx.google.com with ESMTPS id q31sm10991479ybk.1.2010.09.21.22.52.04 (version=SSLv3 cipher=RC4-MD5); Tue, 21 Sep 2010 22:52:07 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C999982.8000301@DataIX.net> Date: Wed, 22 Sep 2010 01:52:02 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Adam Stylinski References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 22 Sep 2010 05:52:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/22/2010 00:31, Adam Stylinski wrote: > If I remember correctly, what actually happens is the pending transaction > group never gets committed and that data becomes corrupted. The pool should > be fully accessible and operational so long as it's never exported as it > will fault back to disks for the intent log. The TXN will not be committed to disk, the data becomes *corrupt*, at that point there is nothing available on disk, the pool is unable to continue. Of course the data is still there but the pool _*WILL NOT*_ operate without the ZIL which is determined to be off-disk at the time you created the slog. You do have the possibility to use OpenSolaris to import the pool, not upgrade it and remove the slog. This should be possible unless a upgrade of the pool is eminent and needed before it allows you to use or remove the slog. If it requires you to upgrade your pool then you will no longer be able to use that on FreeBSD. Besides this, ZFSv13 v14 v15 does not have the possibility to continue no matter what you try to do. I think this has already been stated in this thread. The version that allows you to remove the slog... v19. If you have a slog then make sure you mirror it until the option to remove the slog appears "IF IT WILL" in one of our versions. Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJMmZmCAAoJEJBXh4mJ2FR+b9cH/1YbgA1nvOz73pLL1V6HtTn+ EipqczYanYfWjxZQNAjp4kiN9l9FTM8KHu9wWWJkAZgvft2+Ks5IxKC+iek20Nk+ Eu6EljV37I79ayoDLr9n7ptpo4rn5FbRXgg4mbbMRILdmr8v+PeWoMTSeDcgUryr xi5nnAq8411ujPo2ZYcsKI7f8Ak/XIOWBjxuHYMIPZiSmgOxQtuk+ZYcknh72sSR XeZLZ81FQB0j3yy0Xf1PFDQt50Dxx9UtY7NRoOz2KEm1zKgdhQ+va5hIWMtUNXAN kkZZXANAJYbQ/ZU8iwYHeNsTBYwzB0uCbN6VOLt67Ed2dbPizc6XEctBF4kcVu0= =PR1W -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 10:38:16 2010 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 26B8E106566C for ; Wed, 22 Sep 2010 10:38:16 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id D17DC8FC19 for ; Wed, 22 Sep 2010 10:38:15 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 85A94459AF6; Wed, 22 Sep 2010 12:38:13 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 8.8340] X-CRM114-CacheID: sfid-20100922_12380_C5EA89E0 X-CRM114-Status: Good ( pR: 8.8340 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Sep 22 12:38:13 2010 X-DSPAM-Confidence: 0.8406 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4c99dc95682441175099450 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00058, To*FreeBSD.org, 0.00268, 8+STABLE, 0.01000, STABLE, 0.01000, does+a, 0.01000, worse, 0.01000, a+while, 0.99000, (for, 0.01000, disks, 0.01000, disks, 0.01000, but+having, 0.01000, the+system, 0.01845, queue, 0.02245, queue, 0.02245, slow, 0.02519, slow, 0.02519, says, 0.02868, does, 0.03057, load, 0.03330, I+can't, 0.03970, I+can't, 0.03970, nearly, 0.03970, error, 0.04041, I+don't, 0.04601, can't, 0.04691, can't, 0.04691, X-Spambayes-Classification: ham; 0.00 Message-ID: <4C99DC90.70208@fsn.hu> Date: Wed, 22 Sep 2010 12:38:08 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: zcolli (zcollide) state, what does znode dying means? 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, 22 Sep 2010 10:38:16 -0000 Hello, I have a machine, which is heavily hammered with file system operations, running a very recent 8-STABLE. The symptom is that everything works fine for a few minutes, then a lot of processes get into zcolli state (according to top). At that there there are two outcomes: 1. the disks calm down for a while (for long seconds, there is no, or very small amount of IO, verified with gstat), top shows nearly 100% system, a lot of processes are on the run queue (load is in the sky, around 300 and 1000), all operations stop, top refreshes, but I can't really execute new programs, then suddenly the zcolli states change and the IO resumes and the run queue decreases. 2. the system remains in this state, after 5-10 minutes there is still no change, only a reset helps (doesn't even react to CTRL-ALT-DEL, but running programs, like top still refreshes, but no disk IO can be made) zcollide state only appears here: http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c#L915 which says this is due to a dying znode. My question is: what does a dying znode mean? I don't think it's related to the on-disk structure, because the disks seem to be healthy, respond quickly (or at least evenly slow, due to the load, I can't see a disk, which would have a read error, or slow responses). Having slowdowns due to this is bad, but having lockups is a lot more worse... Thanks, From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 10:32:41 2010 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 1E787106564A for ; Wed, 22 Sep 2010 10:32:41 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id D11C38FC17 for ; Wed, 22 Sep 2010 10:32:40 +0000 (UTC) Received: from edmwaa02.telusplanet.net ([66.183.53.162]) by priv-edmwes25.telusplanet.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20100922103239.JZPA2238.priv-edmwes25.telusplanet.net@edmwaa02.telusplanet.net> for ; Wed, 22 Sep 2010 04:32:39 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edmwaa02.telusplanet.net (BorderWare Security Platform) with ESMTP id 8C700274A7BFCC24 for ; Wed, 22 Sep 2010 04:32:39 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 4186462A4 for ; Wed, 22 Sep 2010 03:32:39 -0700 (PDT) Message-ID: <4C99DB46.1020308@telus.net> Date: Wed, 22 Sep 2010 03:32:38 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=yW7ehx59SWrPX9sFlBd+WpMW8w65YBckkgKgQrm99nA= c=1 sm=0 a=GFxPKaE9UbsA:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=AuW3WSKaGibjtbeclFUA:9 a=8QHv6hcEhYCPRbVTHZ8A:7 a=Z6IJy-j2A0lvA9Tov9TKb3zlSBMA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Wed, 22 Sep 2010 11:19:34 +0000 Subject: GPT partition type (GUID) for (g)journal provider partition 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, 22 Sep 2010 10:32:41 -0000 I am using GPT for disk layout and I wish to use a dedicated partition for a gjournal journal provider rather than combining the data and journal into the same provider/partition. The question is this: What partition type (GUID) do I use for the journal partition? The gpart(8) man page lists a number of symbolic names for different FreeBSD partition types, but none seem appropriate for the task. For those that wonder, my reason for separating data and journal is that I am hoping to make up a little bit of the tremendous performance hit that gjournal causes by locating a journal provider in the fastest region of the disk even though its corresponding data provider must necessarily be located in the slower region of the disk. Is there a flaw in that thinking? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 12:28:10 2010 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 A1092106564A; Wed, 22 Sep 2010 12:28:10 +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 77C678FC13; Wed, 22 Sep 2010 12:28: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 o8MCSAc0066546; Wed, 22 Sep 2010 12:28:10 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8MCSAep066542; Wed, 22 Sep 2010 12:28:10 GMT (envelope-from arundel) Date: Wed, 22 Sep 2010 12:28:10 GMT Message-Id: <201009221228.o8MCSAep066542@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/150796: [panic] [suj] [ufs] [softupdates] Panic on portbuild 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, 22 Sep 2010 12:28:10 -0000 Old Synopsis: [panic] [suj] Panic on portbuild New Synopsis: [panic] [suj] [ufs] [softupdates] Panic on portbuild Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: arundel Responsible-Changed-When: Wed Sep 22 12:24:16 UTC 2010 Responsible-Changed-Why: Assign to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150796 From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 13:11:11 2010 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 847C41065694 for ; Wed, 22 Sep 2010 13:11:11 +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 1F5038FC15 for ; Wed, 22 Sep 2010 13:11:10 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX18ytpepA6DgDaYB7ibIdSKHM7GXQvtk9eU@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o8MD0COL029033; Wed, 22 Sep 2010 14:00:12 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o8MD0CX8030036; Wed, 22 Sep 2010 14:00:12 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o8MD0Cbm030033; Wed, 22 Sep 2010 14:00:12 +0100 Date: Wed, 22 Sep 2010 14:00:12 +0100 Message-Id: <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: (message from David Brodbeck on Tue, 21 Sep 2010 15:38:22 -0700) References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 22 Sep 2010 13:11:11 -0000 >>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said: > > If you don't have a separate log device, synchronous writes are very > slow with the ZIL enabled. This isn't such a big deal unless you're > using NFS, where essentially every write is synchronous. Is that true for all versions of NFS? In my experience (on 8.0-RELEASE), NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a variety of different client OSes). __Martin From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 13:20:04 2010 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 1BA9A106566C for ; Wed, 22 Sep 2010 13:20:04 +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 E4CBF8FC15 for ; Wed, 22 Sep 2010 13: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 o8MDK3Rg018838 for ; Wed, 22 Sep 2010 13: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 o8MDK37C018837; Wed, 22 Sep 2010 13:20:03 GMT (envelope-from gnats) Date: Wed, 22 Sep 2010 13:20:03 GMT Message-Id: <201009221320.o8MDK37C018837@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Johannes Totz" Cc: Subject: Re: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block 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: Wed, 22 Sep 2010 13:20:04 -0000 The following reply was made to PR kern/114676; it has been noted by GNATS. From: "Johannes Totz" To: Cc: Subject: Re: kern/114676: [ufs] snapshot creation panics: snapacct_ufs2: bad block Date: Wed, 22 Sep 2010 13:57:23 +0100 Similar problem on 8-stable, crashed during snapshot creation on a UFS2 filesystem. But for me it seems to be caused by HDD errors: acd0: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 Device: /dev/ad4, 12 Currently unreadable (pending) sectors Device: /dev/ad4, 12 Offline uncorrectable sectors From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 13:22:03 2010 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 74F791065696 for ; Wed, 22 Sep 2010 13:22:03 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 270EB8FC1F for ; Wed, 22 Sep 2010 13:22:02 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 98F5C459FE4; Wed, 22 Sep 2010 15:22:01 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000043, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 11.1327] X-CRM114-CacheID: sfid-20100922_15215_DD0E7287 X-CRM114-Status: Good ( pR: 11.1327 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Sep 22 15:22:01 2010 X-DSPAM-Confidence: 0.8516 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4c9a02f972594415313006 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00058, wrote+>, 0.00213, To*FreeBSD.org, 0.00268, wrote, 0.00389, >+I, 0.00490, a+>, 0.00760, >+The, 0.00760, (it, 0.00789, 12+38, 0.01000, system+>, 0.01000, that+>, 0.01000, 8+STABLE, 0.01000, STABLE, 0.01000, >+1, 0.01000, >+2, 0.01000, seems+to, 0.01000, mostly, 0.01000, mass, 0.01000, Nagy, 0.01000, but+>, 0.01000, why+the, 0.01000, a+while, 0.99000, Received*FreeBSD.org>, 0.01000, enabled, 0.01000, (for, 0.01000, this+machine, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id BB511459FC7 for ; Wed, 22 Sep 2010 15:21:56 +0200 (CEST) Message-ID: <4C9A02F1.6020604@fsn.hu> Date: Wed, 22 Sep 2010 15:21:53 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100921 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org References: <4C99DC90.70208@fsn.hu> In-Reply-To: <4C99DC90.70208@fsn.hu> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: zcolli (zcollide) state, what does znode dying means? 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, 22 Sep 2010 13:22:03 -0000 On 09/22/10 12:38, Attila Nagy wrote: > I have a machine, which is heavily hammered with file system > operations, running a very recent 8-STABLE. > The symptom is that everything works fine for a few minutes, then a > lot of processes get into zcolli state (according to top). At that > there there are two outcomes: > 1. the disks calm down for a while (for long seconds, there is no, or > very small amount of IO, verified with gstat), top shows nearly 100% > system, a lot of processes are on the run queue (load is in the sky, > around 300 and 1000), all operations stop, top refreshes, but I can't > really execute new programs, then suddenly the zcolli states change > and the IO resumes and the run queue decreases. > 2. the system remains in this state, after 5-10 minutes there is still > no change, only a reset helps (doesn't even react to CTRL-ALT-DEL, but > running programs, like top still refreshes, but no disk IO can be made) It turned out that due to a restart prefetch got enabled. On this machine it made so much extra IO (it does mostly random reads) that it could livelock itself. The only thing I don't understand is why the IO ceased during the mass zcollide period, that seems to be a wait for something scenario (sometimes endlessly), which is bad. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 17:14:08 2010 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 74C7C1065695 for ; Wed, 22 Sep 2010 17:14:08 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6688FC15 for ; Wed, 22 Sep 2010 17:14:07 +0000 (UTC) Received: by eyx24 with SMTP id 24so260344eyx.13 for ; Wed, 22 Sep 2010 10:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.36.12 with SMTP id r12mr5705615ebd.96.1285175646829; Wed, 22 Sep 2010 10:14:06 -0700 (PDT) Received: by 10.14.29.76 with HTTP; Wed, 22 Sep 2010 10:14:06 -0700 (PDT) X-Originating-IP: [69.91.158.134] In-Reply-To: <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> Date: Wed, 22 Sep 2010 10:14:06 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 22 Sep 2010 17:14:08 -0000 On Wed, Sep 22, 2010 at 6:00 AM, Martin Simmons wrot= e: >>>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said: >> >> If you don't have a separate log device, synchronous writes are very >> slow with the ZIL enabled. =A0This isn't such a big deal unless you're >> using NFS, where essentially every write is synchronous. > > Is that true for all versions of NFS? =A0In my experience (on 8.0-RELEASE= ), > NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a > variety of different client OSes). It does allow clients to request asynchronous flushing. My statement that "essentially every write is synchronous" was a bit of an overstatement; the problem comes when the client issues a COMMIT, which happens frequently when doing some operations, such as extracting tar files. These are the operations that can get quite slow when using NFS with the ZIL enabled and no separate log device. By "quite slow," I mean several minutes to extract a tar file that takes less than a minute with the ZIL disabled. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 17:19:24 2010 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 C81611065670 for ; Wed, 22 Sep 2010 17:19:24 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62D268FC12 for ; Wed, 22 Sep 2010 17:19:23 +0000 (UTC) Received: by eyx24 with SMTP id 24so262286eyx.13 for ; Wed, 22 Sep 2010 10:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.4.73 with SMTP id 9mr1077037ebq.5.1285175963158; Wed, 22 Sep 2010 10:19:23 -0700 (PDT) Received: by 10.14.29.76 with HTTP; Wed, 22 Sep 2010 10:19:22 -0700 (PDT) X-Originating-IP: [69.91.158.134] In-Reply-To: References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> Date: Wed, 22 Sep 2010 10:19:22 -0700 Message-ID: From: David Brodbeck To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 22 Sep 2010 17:19:24 -0000 On Wed, Sep 22, 2010 at 10:14 AM, David Brodbeck wrote: > On Wed, Sep 22, 2010 at 6:00 AM, Martin Simmons wr= ote: >>>>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said: >>> >>> If you don't have a separate log device, synchronous writes are very >>> slow with the ZIL enabled. =A0This isn't such a big deal unless you're >>> using NFS, where essentially every write is synchronous. >> >> Is that true for all versions of NFS? =A0In my experience (on 8.0-RELEAS= E), >> NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a >> variety of different client OSes). > > It does allow clients to request asynchronous flushing. =A0My statement > that "essentially every write is synchronous" was a bit of an > overstatement; the problem comes when the client issues a COMMIT, > which happens frequently when doing some operations, such as > extracting tar files. =A0These are the operations that can get quite > slow when using NFS with the ZIL enabled and no separate log device. > By "quite slow," I mean several minutes to extract a tar file that > takes less than a minute with the ZIL disabled. I should add that there's a very good, if somewhat OpenSolaris-centric, explanation of the issue here: http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine The problem shows up more with ZFS because it enforces proper cache semantics, while many other filesystems do not. This isn't always a satisfactory explanation to users who expect to be able to untar files in a reasonable amount of time, however. ;) From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 19:10:59 2010 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 B29A81065670 for ; Wed, 22 Sep 2010 19:10:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1378FC1E for ; Wed, 22 Sep 2010 19:10:56 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9BABE45CD9; Wed, 22 Sep 2010 21:10:54 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7F49B45C9C; Wed, 22 Sep 2010 21:10:49 +0200 (CEST) Date: Wed, 22 Sep 2010 21:10:29 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100922191028.GD2895@garage.freebsd.pl> References: <868w2yaweh.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline In-Reply-To: <868w2yaweh.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: hastd: parent got stuck in waitpid() 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, 22 Sep 2010 19:10:59 -0000 --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 19, 2010 at 12:57:10PM +0300, Mikolaj Golub wrote: > Hi, >=20 > When trying to produce the scenario described in another thread (hastd: p= ossible > race when a worker is starting) I stepped on another issue. I was running= the > following script: >=20 > #!/bin/sh >=20 > for i in `jot 1000`; do > hastctl status storage > /dev/null > done & > for i in `jot 1000`; do > hastctl role init storage > hastctl role primary storage > done >=20 > Parent hastd got stuck but that time when changing the role to init and > terminating the worker: in waitpid() after sending kill() to the worker. = It > looked like the signal was lost. I don't have a clue how this might happe= n but > it is rather easy reproducible in my environment with the script above. Could you try r213009? The problem was (I believe) that signal mask was configured after we forked, so there was a window where signal could have been delivered, but before we could handled it properly. Now signal mask is configured in the main process and the primary process inherits it, so there is no window anymore. Your test also triggered different bug for me - a descriptor leak, which is now also fixed. Thanks for the reports! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyaVKQACgkQForvXbEpPzTnjQCgvvMwbElJ+bT4YbnEN5iYYL29 4IMAoLkaDA6Zsglnp1g94BMctUOlTXdI =kQsd -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 20:53:27 2010 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 55620106566C; Wed, 22 Sep 2010 20:53:27 +0000 (UTC) (envelope-from to.my.trociny@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 5F4598FC18; Wed, 22 Sep 2010 20:53:26 +0000 (UTC) Received: by eyx24 with SMTP id 24so338210eyx.13 for ; Wed, 22 Sep 2010 13:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=UpmQK3lsd8hTH1iNj+J76pTG0OfH/IVk0ETVjXJDaNs=; b=OXtwzGvvNqquu1WreGp1pWzZi+toNJo0XlbAjyzy24/IzthvMiI1ftVU4eNEyLeI9U tvLyYbtkQTu6ojaZx473exmG94FPKnl6R+qcf6leJw2sq2OIbDLEjMbLM+Cd1rJTmP/o mnmCOTYoHhE5e18yB4BTy1MRFkYZkRbNwBJh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=FGigv6S3iMzEfMXSaj5QMU3N3kfN8YKmz5vD/PvaM0+AWE5Qc2jjmkoRPLNga3YQrA qdBbqWjHWfJyrePsWJllSbKcKWtEfYmt+km9/dcygVFwAE1sWjQgAvLQ4Zh1fw1qLJai HxtxTB9OZfj4Xf7TZESuyRBTtN3FtMDltjVnM= Received: by 10.213.19.203 with SMTP id c11mr5975549ebb.31.1285188805289; Wed, 22 Sep 2010 13:53:25 -0700 (PDT) Received: from localhost ([95.69.171.82]) by mx.google.com with ESMTPS id u9sm15381075eeh.23.2010.09.22.13.53.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Sep 2010 13:53:24 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek References: <868w2yaweh.fsf@kopusha.home.net> <20100922191028.GD2895@garage.freebsd.pl> X-Comment-To: Pawel Jakub Dawidek Date: Wed, 22 Sep 2010 23:53:23 +0300 In-Reply-To: <20100922191028.GD2895@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Wed, 22 Sep 2010 21:10:29 +0200") Message-ID: <86vd5xa4ak.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: hastd: parent got stuck in waitpid() 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, 22 Sep 2010 20:53:27 -0000 On Wed, 22 Sep 2010 21:10:29 +0200 Pawel Jakub Dawidek wrote: PJD> Could you try r213009? PJD> The problem was (I believe) that signal mask was configured after we PJD> forked, so there was a window where signal could have been delivered, PJD> but before we could handled it properly. Now signal mask is configured PJD> in the main process and the primary process inherits it, so there is no PJD> window anymore. Yes, with the latest source I can't get hangs any more. Thank you! -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 21:34:30 2010 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 EA1881065670 for ; Wed, 22 Sep 2010 21:34:30 +0000 (UTC) (envelope-from admin@mai.pp.ru) Received: from mail.tel.ru (mail.tel.ru [87.249.14.90]) by mx1.freebsd.org (Postfix) with ESMTP id A900F8FC08 for ; Wed, 22 Sep 2010 21:34:30 +0000 (UTC) Received: from gw.tel.ru ([87.249.10.61] helo=tel-3bcb62c3ab7) by mail.tel.ru with esmtp (Exim 4.69) (envelope-from ) id 1OyOio-0005s3-OT for freebsd-fs@freebsd.org; Wed, 22 Sep 2010 16:46:51 +0400 Date: Wed, 22 Sep 2010 16:30:19 +0400 From: Roman X-Mailer: The Bat! (v4.0.18) Professional Organization: MAI X-Priority: 3 (Normal) Message-ID: <1711327714.20100922163019@mai.pp.ru> To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 8.1 + ntfs-3g = kernel panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roman List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 21:34:31 -0000 =0D=0AHello. FreeBSD 8.1-RELEASE amd64 fusefs-ntfs-2010.3.6 ntfs-3g /dev/da1p1 /mnt /dev/fuse0 on /mnt (fusefs, local, synchronous) echo "TEST" > /mnt/test -> kernel panic also you can make some file inside /mnt then try to overwrite this file.. -> kernel panic So only basic read and write of files if a bit stable. Is it fusefs or ntfs-3g problem? Maybe broken port(patches not compatible with 8.1)? --=20 Best regards, Bogdanov Roman From owner-freebsd-fs@FreeBSD.ORG Wed Sep 22 21:48:16 2010 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 CEFFC1065670 for ; Wed, 22 Sep 2010 21:48:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26A0B8FC13 for ; Wed, 22 Sep 2010 21:48:15 +0000 (UTC) Received: from porto.topspin.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 AAA09113; Thu, 23 Sep 2010 00:48:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OyXAY-00020B-LK; Thu, 23 Sep 2010 00:48:02 +0300 Message-ID: <4C9A7992.1080200@icyb.net.ua> Date: Thu, 23 Sep 2010 00:48:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Roman References: <1711327714.20100922163019@mai.pp.ru> In-Reply-To: <1711327714.20100922163019@mai.pp.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: FreeBSD 8.1 + ntfs-3g = kernel panic 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, 22 Sep 2010 21:48:16 -0000 on 22/09/2010 15:30 Roman said the following: > > Hello. > > FreeBSD 8.1-RELEASE amd64 > fusefs-ntfs-2010.3.6 > > ntfs-3g /dev/da1p1 /mnt > /dev/fuse0 on /mnt (fusefs, local, synchronous) > > echo "TEST" > /mnt/test > -> kernel panic > > also you can make some file inside /mnt > then try to overwrite this file.. > -> kernel panic Can you report technical information about the panics? Panic messages, stack traces, etc > So only basic read and write of files if a bit stable. > Is it fusefs or ntfs-3g problem? Maybe broken port(patches not > compatible with 8.1)? -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 02:57:06 2010 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 74B7F1065670 for ; Thu, 23 Sep 2010 02:57:06 +0000 (UTC) (envelope-from fbsd@dannysplace.net) Received: from mailgw.dannysplace.net (mailgw.dannysplace.net [204.109.56.184]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC878FC16 for ; Thu, 23 Sep 2010 02:57:05 +0000 (UTC) Received: from [203.206.171.212] (helo=[192.168.10.10]) by mailgw.dannysplace.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oyc00-0000Xe-Do for freebsd-fs@freebsd.org; Thu, 23 Sep 2010 12:57:30 +1000 Message-ID: <4C9AC1F6.90305@dannysplace.net> Date: Thu, 23 Sep 2010 12:56:54 +1000 From: Danny Carroll User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: danny X-Authenticator: plain X-Exim-Version: 4.72 (build at 12-Jul-2010 18:31:29) X-Date: 2010-09-23 12:57:28 X-Connected-IP: 203.206.171.212:58285 X-Message-Linecount: 106 X-Body-Linecount: 94 X-Message-Size: 4314 X-Body-Size: 3789 X-Received-Count: 1 X-Recipient-Count: 1 X-Local-Recipient-Count: 1 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-SA-Exim-Connect-IP: 203.206.171.212 X-SA-Exim-Mail-From: fbsd@dannysplace.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on damka.dannysplace.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mailgw.dannysplace.net) Subject: Devices disappeared after drive shuffle - or - how to recover and mount a slice with UFS partitions. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fbsd@dannysplace.net List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 02:57:06 -0000 I had a strange problem this week and although it's already solved, I am still not sure what went wrong. This is a long email so bear with me ;-) There is a nice recovery procedure at the end and a few questions along the way for someone who knows more than I. I have 15 drives attached to my home fileserver. 12 are connected via an areca controller (configured as pass-through). Data drives. 3 are connected directly to the motherboard SATA controllers. OS Drives. The motherboard is a Supermicro X7SBE with 8Gb RAM. The 3 OS drives are 80Gb seagate sata drives and up till this week one of them was running 7.3-Stable. I wanted to reinstall so I decided to pull the OS drive, re-install 8.1 on one of the other 2 drives and use PJD's procedure for ZFS mirrored root. (http://blogs.freebsdish.org/pjd/2010/08/06/from-sysinstall-to-zfs-only-configuration/) I installed on ad6 and mirrored to ad4. Ad8 was the old 7.3 drive which was pulled from the server to make sure I did not accidentally overwrite it. Install went fine and I was able to plug the old drive back in after the upgrade and see the old 7.3 data (it was again ad8). My problem arose when I decided to test if the ARECA passthrough drives are really 100% passed through. The 12 drives are configured in a zfs raidz array. I use GPT partitions with labels that are used. I powered down, pulled one of the drives (da0) and plugged it into one of the SATA ports. ZFS came up perfectly and a scrub revealed no errors. This tells me that a drive connected to an Areca controller and configured as a pass-through is no different to a drive connected to a standard SATA port. This is good to know if my areca card ever fails. (Areca Pass-through differs from JBOD in that JBOD ignores the Areca's cache (and battery backup) and passthrough does indeed use the cache.) The da0 drive is now ad4, the 2 OS drives are now ad6 and ad8 and the old OS drive (which I plugged back in after the upgrade) is now ad10. All looked good but the 2 slices on the ad10 drive did not show up in /dev/. My data was on the second slice with 4 UFS partitions on that slice. Running fdisk on ad10 showed the slices were there, but just not in /dev/. I had backups but I wanted the data anyway so I used testdisk to create an image of the second slice. (dd would have worked just as well I guess). I then mounted the raw slice via a md0 device. As expected md0a, md0d, md0e and md0f showed up in /dev/ Great... I had my data back! My only real question is. Why did the devices fail to be created in /dev from the original disk? And is there a way to force devfs to rescan a device and create those sub-devices? And now, a procedure for anyone who finds themselves having to recover a slice containing UFS partitions. I kinda guessed my way though this and was surprised that it was so easy. Use sysutils/testdisk to dump the partition to a flat file. mdconfig -a -t vnode -f /data/image.dd -u 0 mount /dev/md0a /oldserv mount /dev/md0f /oldserv/usr mount /dev/md0d /oldserv/var mount /dev/md0e /oldserv/tmp done! Interestingly enough, I tried this with a zvol as well. Use sysutils/testdisk to dump the partition to a flat file. Called image.dd (it was about 70G) Create the zvol: zfs create -V 70G data/oldserv (make sure size is the same) dd if=/data/image.dd of=/dev/zvol/data/oldserv bs=1M Unfortunately it did not work out. The slices were created but I had trouble mounting them. I am not sure why. I learned a little about UFS data recovery, a little about md0 and a little about zvols today. I assume if I had have done the same with the whole disk device instead of the slice, I would have seen md0p2a md0p2d etc in /dev/... -D From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 06:44:26 2010 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 B0D3B1065672 for ; Thu, 23 Sep 2010 06:44:26 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC3C8FC12 for ; Thu, 23 Sep 2010 06:44:26 +0000 (UTC) Received: from edmwaa03.telusplanet.net ([66.183.53.162]) by priv-edmwes25.telusplanet.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20100923064425.TZVT2238.priv-edmwes25.telusplanet.net@edmwaa03.telusplanet.net> for ; Thu, 23 Sep 2010 00:44:25 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edmwaa03.telusplanet.net (BorderWare Security Platform) with ESMTP id 5AA81376EBF00E5F for ; Thu, 23 Sep 2010 00:44:25 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 198806455 for ; Wed, 22 Sep 2010 23:44:25 -0700 (PDT) Message-ID: <4C9AF748.1000801@telus.net> Date: Wed, 22 Sep 2010 23:44:24 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4C99DB46.1020308@telus.net> In-Reply-To: <4C99DB46.1020308@telus.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=lyV+XRjCp92gjFJjEBGdd+uk4cCEHFcEmNbKezYOog0= c=1 sm=0 a=xiDSYVbS4m4A:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=8pif782wAAAA:8 a=_PVBLat-Bp3SsfXtALgA:9 a=XX2tv2Cs97AWHLjOSG4A:7 a=_MeWDVspvEG2nbrt4HeTRPcHs8sA:4 a=wPNLvfGTeEIA:10 a=uksCwDLimwtdvGab:21 a=lSjJdf9Z17SUZsNX:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: GPT partition type (GUID) for (g)journal provider partition 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, 23 Sep 2010 06:44:26 -0000 On 2010-09-22 3:32 AM, Carl wrote: > I am using GPT for disk layout and I wish to use a dedicated partition > for a gjournal journal provider rather than combining the data and > journal into the same provider/partition. The question is this: What > partition type (GUID) do I use for the journal partition? > > The gpart(8) man page lists a number of symbolic names for different > FreeBSD partition types, but none seem appropriate for the task. > > For those that wonder, my reason for separating data and journal is that > I am hoping to make up a little bit of the tremendous performance hit > that gjournal causes by locating a journal provider in the fastest > region of the disk even though its corresponding data provider must > necessarily be located in the slower region of the disk. Is there a flaw > in that thinking? Anyone know the GUID I need to use? Since posting the question I've been trying in vain to find a document listing all known GPT partition type GUIDs. Apple claims it's in the UEFI specification, but it isn't. The largest list is in this Wikipedia article: http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs which provides no references as to where most of the list contents come from. How and by who did the FreeBSD GUIDs get defined? Are there more than appear in that Wikipedia article? Is there no governing body/publication for this sort of thing? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 09:49:24 2010 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 555D1106564A for ; Thu, 23 Sep 2010 09:49:24 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id 13C068FC18 for ; Thu, 23 Sep 2010 09:49:23 +0000 (UTC) Received: from edmwaa01.telusplanet.net ([66.183.53.162]) by priv-edmwes24.telusplanet.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20100923094923.DTHE21073.priv-edmwes24.telusplanet.net@edmwaa01.telusplanet.net>; Thu, 23 Sep 2010 03:49:23 -0600 Received: from oliver.bc.lan (d66-183-53-162.bchsia.telus.net [66.183.53.162]) by edmwaa01.telusplanet.net (BorderWare Security Platform) with ESMTP id 17C230456F9BF93F; Thu, 23 Sep 2010 03:49:22 -0600 (MDT) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 7AE646455; Thu, 23 Sep 2010 02:49:22 -0700 (PDT) Message-ID: <4C9B22A2.6010009@telus.net> Date: Thu, 23 Sep 2010 02:49:22 -0700 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4C99DB46.1020308@telus.net> <4C9AF748.1000801@telus.net> <4C9B06CC.1050702@gmx.com> In-Reply-To: <4C9B06CC.1050702@gmx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=f1k9KPZtpjXamAqXdN00h4MBr3pPUbSyF09b3+e+n1s= c=1 sm=0 a=xiDSYVbS4m4A:10 a=8nJEP1OIZ-IA:10 a=HNgjH8kF64GtJ7EcXKEMsQ==:17 a=MXTecpzVkyA8AYcuB88A:9 a=c4GxevQJ8FA75UYooO5uYInaqQcA:4 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: GPT partition type (GUID) for (g)journal provider partition 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, 23 Sep 2010 09:49:24 -0000 On 2010-09-23 12:50 AM, Nikos Vassiliadis wrote: > freebsd-ufs seems pretty generic. All other FreeBSD GUIDs seem to have > a more special function than freebsd-ufs. Why not freebsd-ufs? If such a partition came prior to the root partition, it would screw up booting, I think. But beyond that? That's the problem - I don't know. Are GPT partition types so meaningless that it's benign to mis-categorize a non-UFS partition as UFS? If so, maybe swiping one from an unrelated OS (eg. Linux swap) is better than possibly upsetting something UFS-related? > The GUIDs known to FreeBSD are defined in /usr/include/sys/gpt.h. Thanks. I was looking for that too. > I guess the GUIDs are defined in co-operation with the UEFI organization > and the applicant organization, for example the FreeBSD project. I presume so, but is that information deemed confidential to members/licensees of UEFI only? Carl / K0802647 From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 13:40:26 2010 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 A4856106564A for ; Thu, 23 Sep 2010 13:40:26 +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 293758FC14 for ; Thu, 23 Sep 2010 13:40:25 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1/GBPJg6Zfd4XqqAT6Co5rqe7bM51vzoSc@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o8NDeNE7000641; Thu, 23 Sep 2010 14:40:23 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o8NDeNkL017809; Thu, 23 Sep 2010 14:40:23 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o8NDeNl5017806; Thu, 23 Sep 2010 14:40:23 +0100 Date: Thu, 23 Sep 2010 14:40:23 +0100 Message-Id: <201009231340.o8NDeNl5017806@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: <4C9AC1F6.90305@dannysplace.net> (message from Danny Carroll on Thu, 23 Sep 2010 12:56:54 +1000) References: <4C9AC1F6.90305@dannysplace.net> Subject: Re: Devices disappeared after drive shuffle - or - how to recover and mount a slice with UFS partitions. 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, 23 Sep 2010 13:40:26 -0000 >>>>> On Thu, 23 Sep 2010 12:56:54 +1000, Danny Carroll said: > > My only real question is. Why did the devices fail to be created in > /dev from the original disk? See if the partitions are listed in the output of: sysctl -b kern.geom.conftxt If not, then it looks like a kernel/geom problem. __Martin From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 14:25:55 2010 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 D35E310656C3 for ; Thu, 23 Sep 2010 14:25:55 +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 A1E648FC1B for ; Thu, 23 Sep 2010 14:25:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3E5B146B9C; Thu, 23 Sep 2010 10:25:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF38D8A04E; Thu, 23 Sep 2010 10:25:50 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Thu, 23 Sep 2010 09:51:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4C99DB46.1020308@telus.net> <4C9AF748.1000801@telus.net> In-Reply-To: <4C9AF748.1000801@telus.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009230951.06592.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Sep 2010 10:25:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Carl Subject: Re: GPT partition type (GUID) for (g)journal provider partition 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, 23 Sep 2010 14:25:55 -0000 On Thursday, September 23, 2010 2:44:24 am Carl wrote: > On 2010-09-22 3:32 AM, Carl wrote: > > I am using GPT for disk layout and I wish to use a dedicated partition > > for a gjournal journal provider rather than combining the data and > > journal into the same provider/partition. The question is this: What > > partition type (GUID) do I use for the journal partition? > > > > The gpart(8) man page lists a number of symbolic names for different > > FreeBSD partition types, but none seem appropriate for the task. > > > > For those that wonder, my reason for separating data and journal is that > > I am hoping to make up a little bit of the tremendous performance hit > > that gjournal causes by locating a journal provider in the fastest > > region of the disk even though its corresponding data provider must > > necessarily be located in the slower region of the disk. Is there a flaw > > in that thinking? > > Anyone know the GUID I need to use? > > Since posting the question I've been trying in vain to find a document > listing all known GPT partition type GUIDs. Apple claims it's in the > UEFI specification, but it isn't. The largest list is in this Wikipedia > article: > > http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs > > which provides no references as to where most of the list contents come > from. > > How and by who did the FreeBSD GUIDs get defined? Are there more than > appear in that Wikipedia article? Is there no governing body/publication > for this sort of thing? The GUID's for FreeBSD were generated by FreeBSD developers. GUID creation is not explicitly coordinated with UEFI. Instead, GUID's are designed to have a very low probability of collisions. You can ask pjd@ if he thinks gjournal warrants a separate partition type and if so a new GUID can be generated and added to -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 16:10:29 2010 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 AE45B1065672 for ; Thu, 23 Sep 2010 16:10:29 +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 2A3518FC1B for ; Thu, 23 Sep 2010 16:10:28 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX18mTwGPvtlEXpfWrM7U4x30r/eg3B5PS6w@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id o8NGAQsR013309; Thu, 23 Sep 2010 17:10:26 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o8NGAPA2018901; Thu, 23 Sep 2010 17:10:25 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o8NGAPkf018898; Thu, 23 Sep 2010 17:10:25 +0100 Date: Thu, 23 Sep 2010 17:10:25 +0100 Message-Id: <201009231610.o8NGAPkf018898@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: (message from David Brodbeck on Wed, 22 Sep 2010 10:19:22 -0700) References: <4C9385B0.2080909@shatow.net> <20100917161847.GA58503@icarus.home.lan> <201009221300.o8MD0Cbm030033@higson.cam.lispworks.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: what happens to pool if ZIL dies on ZFS v14 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, 23 Sep 2010 16:10:29 -0000 >>>>> On Wed, 22 Sep 2010 10:19:22 -0700, David Brodbeck said: > > On Wed, Sep 22, 2010 at 10:14 AM, David Brodbeck wrote: > > On Wed, Sep 22, 2010 at 6:00 AM, Martin Simmons wrote: > >>>>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said: > >>> > >>> If you don't have a separate log device, synchronous writes are very > >>> slow with the ZIL enabled.  This isn't such a big deal unless you're > >>> using NFS, where essentially every write is synchronous. > >> > >> Is that true for all versions of NFS?  In my experience (on 8.0-RELEASE), > >> NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a > >> variety of different client OSes). > > > > It does allow clients to request asynchronous flushing.  My statement > > that "essentially every write is synchronous" was a bit of an > > overstatement; the problem comes when the client issues a COMMIT, > > which happens frequently when doing some operations, such as > > extracting tar files.  These are the operations that can get quite > > slow when using NFS with the ZIL enabled and no separate log device. > > By "quite slow," I mean several minutes to extract a tar file that > > takes less than a minute with the ZIL disabled. > > I should add that there's a very good, if somewhat > OpenSolaris-centric, explanation of the issue here: > http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine > > The problem shows up more with ZFS because it enforces proper cache > semantics, while many other filesystems do not. This isn't always a > satisfactory explanation to users who expect to be able to untar files > in a reasonable amount of time, however. ;) Thanks, I see what you mean. FWIW, both Linux and FreeBSD 7.3 nfs clients appear to be running asynchronously by default (zpool iostat 1 shows bursty writes while extracting with tar), whereas Solaris 10 clients appear to be doing very slow synchronous operations. __Martin From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 18:03:25 2010 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 81DF01065673 for ; Thu, 23 Sep 2010 18:03:25 +0000 (UTC) (envelope-from cal@linu.gs) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 47B148FC13 for ; Thu, 23 Sep 2010 18:03:25 +0000 (UTC) Received: from [77.109.131.203] (port=38577 helo=aare.localnet) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OypkI-000M0p-0y for freebsd-fs@freebsd.org; Thu, 23 Sep 2010 19:38:10 +0200 From: Michael Naef To: "freebsd-fs" Date: Thu, 23 Sep 2010 19:38:00 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201009231938.09548.cal@linu.gs> Subject: Strange behaviour with sappend flag set 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, 23 Sep 2010 18:03:25 -0000 Hi fs people Background: When moving from pre-8.0 to FreeBSD 8.1 on ZFS I realised that the bash history is no longer beeing written if the file has the sappend flag set. Other programs like script (1) however are surprisingly still able to write to such files. So it seemed that they handle file IO differently. (Looking at the source code of both I learned that bash uses write (2) while script uses fwrite (3)... After some more testing and investigation,) it seems that zfs behaves differently to ufs in one point. If I open (2) a file with O_APPEND the fd position pointer is set to the start of the file. When I then write to an fd on a ufs FS in FB6.4, it is automatically moved to the end and the bytes are appended. No problems appear with write to the sappend-flages file. However if I do the same on FB8.1/ZFS, the write fails as "not permitted". When I manually move the position pointer to the end of the file, it works as axpected: FreeBSD 6.4/UFS: root@fb64 [~/michi]# touch gaga root@fb64 [~/michi]# chflags sappend gaga root@fb64 [~/michi]# ./write fd: 3 pos: 0 bytes written: 6 pos: 50 bytes written: 6 FreeBSD 8.1/ZFS: root@server52 [~/michi]# chflags sappend gaga root@fb81 [~/michi]# touch gaga root@fb81 [~/michi]# chflags sappend gaga root@fb81 [~/michi]# ./write fd: 3 pos: 0 ERROR: Operation not permitted pos: 147 bytes written: 6 The source code is: #include #include #include #include #include int main(void){ int file= open("gaga",O_WRONLY|O_APPEND|O_CREAT,0666); int bytes_written= 0; printf("fd: %i\n",file); printf("pos: %i\n",lseek(file,0,SEEK_CUR)); if ((bytes_written= write(file,"write\n",6)) == -1){ printf("ERROR: %s\n",strerror(errno)); }else{ printf("bytes written: %i\n",bytes_written); } lseek(file,0,SEEK_END); printf("pos: %i\n",lseek(file,0,SEEK_CUR)); if ((bytes_written= write(file,"write\n",6)) == -1){ printf("ERROR: %s\n",strerror(errno)); }else{ printf("bytes written: %i\n",bytes_written); } close(file); } Am I missing something or is this a bug (or feature or watsoever ;-) in ZFS? thanks a lot you (z)fs guys and cheers, Michi From owner-freebsd-fs@FreeBSD.ORG Thu Sep 23 23:27:00 2010 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 3C201106564A for ; Thu, 23 Sep 2010 23:27:00 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id F16B98FC08 for ; Thu, 23 Sep 2010 23:26:59 +0000 (UTC) Received: from 46-127-29-79.dclient.hispeed.ch ([46.127.29.79]:47198 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Oyv1A-0006bV-3t; Fri, 24 Sep 2010 01:15:56 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <201009231938.09548.cal@linu.gs> Date: Fri, 24 Sep 2010 01:15:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66757A1E-E445-4AAD-8F57-382D85BFD579@hostpoint.ch> References: <201009231938.09548.cal@linu.gs> To: Michael Naef X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs Subject: Re: Strange behaviour with sappend flag set 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, 23 Sep 2010 23:27:00 -0000 On 23.09.2010, at 19:38, Michael Naef wrote: > If I open (2) a file with O_APPEND the fd position pointer is set=20 > to the start of the file. When I then write to an fd on a ufs FS in=20 > FB6.4, it is automatically moved to the end and the bytes are=20 > appended. No problems appear with write to the sappend-flages file. >=20 > However if I do the same on FB8.1/ZFS, the write fails as "not=20 > permitted". To me, it seems that the zfs_write() VOP incorrectly uses FAPPEND = instead of IO_APPEND when checking the ioflag argument to see if the = current write is an appending one, here: ---- /* * If immutable or not appending then return EPERM */ pflags =3D zp->z_phys->zp_flags; if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && (uio->uio_loffset < zp->z_phys->zp_size))) { ZFS_EXIT(zfsvfs); return (EPERM); } ---- The function comment only mentions IO_APPEND and even later on in = zfs_write() IO_APPEND is used to check wether the offset should be = changed to EOF, so FAPPEND really seems to wrong in the above permission = check. CURRENT and STABLE-8 seem to be affected to. The following patch seems = to fix it (at least Michi's test case works fine with it): ---- diff -ru = ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c --- ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = 2010-05-19 08:49:52.000000000 +0200 +++ ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = 2010-09-23 23:24:43.549846948 +0200 @@ -709,7 +709,7 @@ */ pflags =3D zp->z_phys->zp_flags; if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || - ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && + ((pflags & ZFS_APPENDONLY) && !(ioflag & IO_APPEND) && (uio->uio_loffset < zp->z_phys->zp_size))) { ZFS_EXIT(zfsvfs); return (EPERM); ---- Can someone commit this if the patch is ok? Or should I (or Michi) open = a PR? Markus From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 02:47:41 2010 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 846A6106566B for ; Fri, 24 Sep 2010 02:47:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id B548D8FC08 for ; Fri, 24 Sep 2010 02:47:39 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8O0h0Ka025709 for ; Fri, 24 Sep 2010 10:43:00 +1000 Received: from c122-107-116-249.carlnfd1.nsw.optusnet.com.au (c122-107-116-249.carlnfd1.nsw.optusnet.com.au [122.107.116.249]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8O0gs6v025530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Sep 2010 10:42:57 +1000 Date: Fri, 24 Sep 2010 10:42:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Michael Naef In-Reply-To: <201009231938.09548.cal@linu.gs> Message-ID: <20100924083610.B714@delplex.bde.org> References: <201009231938.09548.cal@linu.gs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs Subject: Re: Strange behaviour with sappend flag set 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, 24 Sep 2010 02:47:41 -0000 On Thu, 23 Sep 2010, Michael Naef wrote: > If I open (2) a file with O_APPEND the fd position pointer is set > to the start of the file. When I then write to an fd on a ufs FS in > FB6.4, it is automatically moved to the end and the bytes are > appended. No problems appear with write to the sappend-flages file. > > However if I do the same on FB8.1/ZFS, the write fails as "not > permitted". When I manually move the position pointer to the end of > the file, it works as axpected: > Am I missing something or is this a bug (or feature or watsoever > ;-) in ZFS? I know little about zfs, but the bug is obvious: from zfs_write(): % /* % * If immutable or not appending then return EPERM % */ % pflags = zp->z_phys->zp_flags; % if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || % ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && % (uio->uio_loffset < zp->z_phys->zp_size))) { % ZFS_EXIT(zfsvfs); % return (EPERM); % } This returns EPERM before advancing the pointer. The comment does less than echo the code. The code also returns EPERM if read-only. The code only returns EPERM for not appending if the file is append-only. Using FAPPEND is a layering violation. That is file descriptor flag (or is it an open-file flag? Anyway, it is not the attribute-file flag) , but here we have an i/o flag. vfs has carefully translated from FAPPEND to IO_APPEND. This is just a spelling error here since the flags have the same value. % ... % /* % * If in append mode, set the io offset pointer to eof. % */ % if (ioflag & IO_APPEND) { This is almost dead code, since we have already failed if the pointer is not already at the end. % /* % * Range lock for a file append: % * The value for the start of range will be determined by % * zfs_range_lock() (to guarantee append semantics). It is unfortunate that vfs doesn't do this, so 10-20 individual file systems have to do it. However, if the vfs lock isn't sufficient, then the advancement must be delayed like it is until the foofs lock is held. % * If this write will cause the block size to increase, % * zfs_range_lock() will lock the entire file, so we must % * later reduce the range after we grow the block size. % */ % rl = zfs_range_lock(zp, 0, n, RL_APPEND); % if (rl->r_len == UINT64_MAX) { % /* overlocked, zp_size can't change */ % woff = uio->uio_loffset = zp->z_phys->zp_size; This case doesn't advance the pointer, so would be broken if we hadn't already checked ZFS_APPEND. % } else { % woff = uio->uio_loffset = rl->r_off; This case does advance the pointer, so is broken since we already checked ZFS_APPEND. % } % } else { The canonical code for advancing the pointer and checking for append-only files is much simpler and less broken: from ffs_write(): % switch (vp->v_type) { % case VREG: % if (ioflag & IO_APPEND) % uio->uio_offset = ip->i_size; % if ((ip->i_flags & APPEND) && uio->uio_offset != ip->i_size) % return (EPERM); ffs_write() is also correctly missing the check for immutable files. The immutable flag should limit open() (and some other operations not including write()), just like the file permissions flags. ffs_write() is also missing the check for read-only mounts. This is subtle. I think the fs cannot be mounted read-only if ffs_write() is reached -- even if the file was opened for writing at a time when the mount was read-write, the file must have been dowgraded to unwriteable of the mount was successfully downgraded to read-only (takes a forced unmount which tends to break applications but shouldn't break the file system). ffs^Wufs_open() also checks the append-only flag (the attribute one) at open() time, and fails then if O_APPEND is not set. This is half good: The behaviour should only depend on the attributes at the time of the open, just like it does for the file permissions and the immutable attributes. But ffs_write() is broken here -- it uses the append-only attribute at the time of the write. This is half bad: unlike the attributes, the O_APPEND flag is intended to be changed for open files (despite the O_ in its name, it can be changed by fcntl()), so checking it at open time is just inconsistent (unless you deny unsetting O_APPEND if the append-only attribute is set, foofs_write() still has to be prepared for the combination of append flags that is disallowed by ffs_open()). Thus it is a bug to check any append flags at open time. The append-only flag at the time of the open should be copied for use at the time of later writes to the open file descriptor (or is it the open file?), and the O_APPEND flag should only be checked at the time of later writes. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 03:16:54 2010 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 710241065670 for ; Fri, 24 Sep 2010 03:16:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6178FC16 for ; Fri, 24 Sep 2010 03:16:53 +0000 (UTC) Received: from c122-107-116-249.carlnfd1.nsw.optusnet.com.au (c122-107-116-249.carlnfd1.nsw.optusnet.com.au [122.107.116.249]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8O3GnKt027275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Sep 2010 13:16:51 +1000 Date: Fri, 24 Sep 2010 13:16:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Markus Gebert In-Reply-To: <66757A1E-E445-4AAD-8F57-382D85BFD579@hostpoint.ch> Message-ID: <20100924122839.P842@delplex.bde.org> References: <201009231938.09548.cal@linu.gs> <66757A1E-E445-4AAD-8F57-382D85BFD579@hostpoint.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs Subject: Re: Strange behaviour with sappend flag set 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, 24 Sep 2010 03:16:54 -0000 On Fri, 24 Sep 2010, Markus Gebert wrote: > On 23.09.2010, at 19:38, Michael Naef wrote: > >> If I open (2) a file with O_APPEND the fd position pointer is set >> to the start of the file. When I then write to an fd on a ufs FS in >> FB6.4, it is automatically moved to the end and the bytes are >> appended. No problems appear with write to the sappend-flages file. >> >> However if I do the same on FB8.1/ZFS, the write fails as "not >> permitted". > > To me, it seems that the zfs_write() VOP incorrectly uses FAPPEND instead of IO_APPEND when checking the ioflag argument to see if the current write is an appending one, here: > > ---- > /* > * If immutable or not appending then return EPERM > */ > pflags = zp->z_phys->zp_flags; > if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || > ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && > (uio->uio_loffset < zp->z_phys->zp_size))) { > ZFS_EXIT(zfsvfs); > return (EPERM); > } > ---- > > The function comment only mentions IO_APPEND and even later on in zfs_write() IO_APPEND is used to check wether the offset should be changed to EOF, so FAPPEND really seems to wrong in the above permission check. Oops, the file[descriptor] append flags aren't all the same like I said in a previous reply. FAPPEND is identical with O_APPEND and is 8, but IO_APPEND is 2. Here zfs is testing IO_NODELOCKED = 8. The use of IO_NODELOCKED is confusing and slightly broken. It is only a flag for vn_rdwr() and a couple of other in-kernel i/o functions. These start with the vnode locked and set IO_NODELOCKED to tell vn_rdwr() not to lock again. Userland writes call vn_rdwr() without the vnode locked and keep IO_NODELOCKED clear to tell vn_rdwr() to lock the vnode. vn_rdwr() doesn't set it so it is garbage after that -- it remains consistent with the vnode lock state for in-kernel writes, but for userland writes it is inconsistent with the vnode lock state below the level of vn_rdwr(). VOP_WRITE() is called from places other than vn_rdwr(), and most or all of these places also fail to set IO_NODELOCKED. They also mostly or always know that they are for in-kernel writes, so they also don't check IO_NODELOCKED. Thus in the above, the FAPPEND bit is usually clear so the test doesn't work (the cases where FAPPEND is set where it should be clear, and where ZFS_APPENDONLY is also set, are rare since they only occur for in-kernel writes of things like core dumps, and you have other problems if you have many append-only files being written to for things like core dumps). My previous mail was incorrect about this point, and understated the ways in which the comment doesn't match the code -- apart from FAPPEND not being the append-flag, the comment combined with the reported behaviour and mu confusion about the equality of the flags helped me misread the IO_APPEND test backwards. There is similar confusion and possibly bugs for IO_UNIT. Now all callers seem to set it, and most VOP_WRITE() functions can't work right without it. E.g., they all need to back out of short writes to satisfy the implementation of sys_generic.c:write(); ffs_write() only backs out ionly if IO_UNIT is set; it is always set for userland writes so there is no problem with write(), but why not remove it as a flag and always do atomic writes to simplify things? Kernel writers are even less prepared than userland writers to recover from short writes. > CURRENT and STABLE-8 seem to be affected to. The following patch seems to fix it (at least Michi's test case works fine with it): > > ---- > diff -ru ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > --- ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-05-19 08:49:52.000000000 +0200 > +++ ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2010-09-23 23:24:43.549846948 +0200 > @@ -709,7 +709,7 @@ > */ > pflags = zp->z_phys->zp_flags; > if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || > - ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && > + ((pflags & ZFS_APPENDONLY) && !(ioflag & IO_APPEND) && > (uio->uio_loffset < zp->z_phys->zp_size))) { > ZFS_EXIT(zfsvfs); > return (EPERM); Now I think the not-just-a-spelling error was the only major bug, and this fixes it. There is another minor bug/inconsistency with ffs: in the non-IO_APPEND case, ffs requires the offset to == the file size, while the above allows it to be >= the file size. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 03:51:06 2010 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 596EF1065672 for ; Fri, 24 Sep 2010 03:51:06 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E35BC8FC1C for ; Fri, 24 Sep 2010 03:51:05 +0000 (UTC) Received: by fxm9 with SMTP id 9so1933523fxm.13 for ; Thu, 23 Sep 2010 20:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:user-agent :date:message-id:mime-version:content-type; bh=WNNtzBfwu6vaRWbXwXwWU51gFTIuC7aYHzwq2/GS4kE=; b=r4/Ma7EWVFYEc2ecCsWq7O9mlITmXIlAyL+5+Xbc34mBOgy9cvNAOsPs/dD1cW+6ON V1HYOlc5JLQuIqww6yWtKjWqG0Xv1mObRE3+UhEesNTLAW8hVSdzSg7FerszVn5ehvFn RVU+KV7UtnK+vIwF2C2G3LnlJ5/YEX5JU7H+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:user-agent:date:message-id:mime-version :content-type; b=uw7IF1j8vn25WGb+RcoTu1DfVxP59M5pNuaKP3OUWwAI8KgOlNpcYgvSPa8AtrCCYk wZommv2xvoRu2Bh2jwitDjC9i+cwCi4bZGppnlBEJY7ybTUACyEOx+EHaxuw1oLH87Kc 1cDeU6kc/H70hfON1XGzgwsAphDcuKRFY2OwM= Received: by 10.223.114.19 with SMTP id c19mr2943430faq.29.1285300264506; Thu, 23 Sep 2010 20:51:04 -0700 (PDT) Received: from localhost ([95.69.171.82]) by mx.google.com with ESMTPS id a6sm742210faa.20.2010.09.23.20.51.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Sep 2010 20:51:03 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs@freebsd.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) Date: Fri, 24 Sep 2010 06:51:02 +0300 Message-ID: <86mxr7x0ih.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: hastd: memory leaks if fork() fails 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, 24 Sep 2010 03:51:06 -0000 --=-=-= Hi, Although it is rather unlikely situation but anyway :-) If fork() fails in hook_execv() hastd leaks some bytes referred by hp. See the attached patch. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=hooks.c.patch Index: sbin/hastd/hooks.c =================================================================== --- sbin/hastd/hooks.c (revision 213027) +++ sbin/hastd/hooks.c (working copy) @@ -388,6 +388,7 @@ hook_execv(const char *path, va_list ap) switch (pid) { case -1: /* Error. */ pjdlog_errno(LOG_ERR, "Unable to fork to execute %s", path); + hook_free(hp); return; case 0: /* Child. */ descriptors(); --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 04:23:17 2010 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 343211065672 for ; Fri, 24 Sep 2010 04:23:17 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E41C88FC15 for ; Fri, 24 Sep 2010 04:23:16 +0000 (UTC) Received: by qyk7 with SMTP id 7so383318qyk.13 for ; Thu, 23 Sep 2010 21:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Ssga0H6bLi6QvAAhj5TfR+n2Q7IFiFhv8Gt5SG4Bxcw=; b=rF8wO9+PeMyW+ypMdwCSBLyCvHq63c08d5wnG+xro0z85P96wMKhjv9ke2K8Ulp46A ehiwezFVfti1FkH/lSFFX2AVCrK9XEJ1RfX6VBMCkIXSjHSSUg3/MiclY7HI1vDBSFYp rmgm7eTuGLBfcUKifxPqIIaUUrYh2pzeYs+pI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bRaNsJstsLIh0FgQzPpVcJaY6YUSir/W04JPtOK4NIqxH1k6jwvbfIEfNwrgfHo0jB ZCl3K9tOHGOkN4K5hyqbmvAXhtcgBj2tiNFkZuJZOuZLOMPv225sDj5z+/m1dvOIWj/z wrVXnLEGXjsPHeHoZWVNzfhOX5b2BYlczYnFg= MIME-Version: 1.0 Received: by 10.224.29.1 with SMTP id o1mr2034697qac.77.1285300615714; Thu, 23 Sep 2010 20:56:55 -0700 (PDT) Received: by 10.229.17.213 with HTTP; Thu, 23 Sep 2010 20:56:55 -0700 (PDT) Date: Thu, 23 Sep 2010 22:56:55 -0500 Message-ID: From: "Sam Fourman Jr." To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: NFSRoot pxe available disk space 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, 24 Sep 2010 04:23:17 -0000 I am running FreeBSD 9 amd64 via pxe NFSRoot I get a negative value for my available space on / my FreeBSD NFS server is also running FreeBSD 9 built from todays SVN sources this did not happen in FreeBSD 8.1 Sam# uname -a FreeBSD Sam.PuffyBSD.Com 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Thu Sep 23 18:24:25 CDT 2010 root@FNFS.PuffyBSD.Com:/usr/obj/usr/src/sys/WORKSTATION amd64 Sam# df -h Filesystem Size Used Avail Capacity Mounted on 192.168.8.10:/Network/pxe/FreeBSD_AMD64_CURRENT -807G 28G -834G -3% / devfs 1.0K 1.0K 0B 100% /dev tmpfs 218M 4.0K 218M 0% /tmp linprocfs 4.0K 4.0K 0B 100% /compat/linux/proc 192.168.8.10:/Network/distfiles 1.2T 26G 1.2T 2% /usr/ports/distfiles 192.168.8.10:/Network/tv 1.5T 373G 1.2T 24% /Network/tv 192.168.8.10:/Network/iso 1.5T 277G 1.2T 19% /Network/iso 192.168.8.10:/Network/wow 1.2T 35G 1.2T 3% /Network/wow 192.168.8.10:/Network/music 1.3T 106G 1.2T 8% /Network/music 192.168.8.10:/Network/public 1.3T 148G 1.2T 11% /Network/public 192.168.8.10:/Network/pxe/FreeBSD_i386_8_1 1.2T 4.4G 1.2T 0% /compat/FreeBSD-i386 192.168.8.10:/Network/home/sfourman 1.2T 33G 1.2T 3% /usr/home/sfourman -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 07:05:20 2010 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 4EE0E1065673 for ; Fri, 24 Sep 2010 07:05:20 +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 9F2288FC0A for ; Fri, 24 Sep 2010 07:05:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o8O75Fru071564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Sep 2010 10:05:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o8O75F2N038023; Fri, 24 Sep 2010 10:05:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o8O75Fns038022; Fri, 24 Sep 2010 10:05:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Sep 2010 10:05:15 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20100924070515.GD34228@deviant.kiev.zoral.com.ua> References: <201009231938.09548.cal@linu.gs> <20100924083610.B714@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: <20100924083610.B714@delplex.bde.org> 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=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs Subject: Re: Strange behaviour with sappend flag set 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, 24 Sep 2010 07:05:20 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 24, 2010 at 10:42:54AM +1000, Bruce Evans wrote: > ffs_write() is also missing the check for read-only mounts. This is subtle. > I think the fs cannot be mounted read-only if ffs_write() is reached -- > even if the file was opened for writing at a time when the mount was > read-write, the file must have been dowgraded to unwriteable of the mount > was successfully downgraded to read-only (takes a forced unmount which > tends to break applications but shouldn't break the file system). The files open for write are effectively closed on rw->ro downgrade. Technically, the vnodes are reclaimed at the time of remount, and still open file descriptors return appropriate deadfs errors on i/o ops, typically ENXIO or EIO. There is a known brokeness with remounts, where the writeable shared mappings of the vnodes are not accounted for the write count of vnode. I have lingering patch for the issue that is not committed for some reasons. --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkycTaoACgkQC3+MBN1Mb4j9rQCbB20GSAE77o7dqqRThCT8B5FA bs4An312pcGy9dGFHTT8iB5CE5s7xAwP =EXZ3 -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 12:28:46 2010 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 89B26106566C for ; Fri, 24 Sep 2010 12:28:46 +0000 (UTC) (envelope-from dean@fragfest.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 20AE88FC0C for ; Fri, 24 Sep 2010 12:28:45 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8OANZf3025529 for ; Fri, 24 Sep 2010 20:23:35 +1000 Received: from [172.29.0.132] (c122-106-145-234.carlnfd1.nsw.optusnet.com.au [122.106.145.234]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8OANWWj025685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Sep 2010 20:23:32 +1000 Message-ID: <4C9C7C32.3070909@fragfest.com.au> Date: Fri, 24 Sep 2010 20:23:46 +1000 From: Dean Hamstead User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100917 Icedove/3.0.8 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: growfs on a large disk 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, 24 Sep 2010 12:28:46 -0000 Evening, Im trying to growfs a very large filesystem and not having a lot of luck. To give some background, im running the filesystem on a raid array running on an areca raid card. I have an existing filesytem which was formatting /dev/da0 and mounting it. (I understand that this is the preferred alternative to the deprecated 'dangerously dedicated' mode). I have expanded the disk array and the volume at the raid card level. Then rebooted my machine. It was 4x2tb, and is now 5x2tb. Expanding on areca is non-destructive. Here is the current filesystem size when mounted, da0 is the ----- [root@batou /home/dean]# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad4a 496M 280M 176M 61% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad4e 496M 155M 301M 34% /tmp /dev/ad4f 68G 8.0G 54G 13% /usr /dev/ad4d 1.9G 529M 1.2G 30% /var /dev/da1 4.4T 4.4T 28G 99% /volumes/store2 /dev/da0 5.3T 3.9T 1.4T 74% /volumes/store1 ----- From dmesg you can see that freebsd knows its now bigger (7.6 rather than 5.3tb) ----- da0 at arcmsr0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da0: Command Queueing enabled da0: 7629394MB (15624998912 512 byte sectors: 255H 63S/T 972611C) da1 at arcmsr0 bus 0 scbus0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da1: Command Queueing enabled da1: 4768371MB (9765624320 512 byte sectors: 255H 63S/T 607881C) SMP: AP CPU #1 Launched! ----- if we consult diskinfo, it agrees ----- [root@batou /home/dean]# diskinfo -v /dev/da0 /dev/da0 512 # sectorsize 7999999442944 # mediasize in bytes (7.3T) 15624998912 # mediasize in sectors 0 # stripesize 0 # stripeoffset 972611 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. 0000001379342420 # Disk ident. ----- fdisk shows us... ----- [root@batou /home/dean]# fdisk /dev/da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=972611 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=972611 heads=255 sectors/track=63 (16065 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 2740094532 (1337936 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 578/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: ----- now if i unmount /dev/da0 and run growfs /dev/da0 i get the following ----- [root@batou /home/dean]# growfs /dev/da0 growfs: we are not growing (2929687296->685024256) ----- with lots of googling, i have found that there is much talk in various freebsd forums about the need to use disklabel. however it seems unable to fathom such a large disk... ----- [root@batou /home/dean]# disklabel /dev/da0 disklabel: disks with more than 2^32-1 sectors are not supported ---- freebsd version is 8.0 64bit ----- [root@batou /home/dean]# uname -a FreeBSD batou.fragfest.net.au 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Jan 24 17:13:52 EST 2010 dean@batou.fragfest.net.au:/usr/obj/usr/src/sys/GENERIC amd64 ----- hopefully i am doing something wrong, or there is a patch set for growfs? Dean From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 15:46:17 2010 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 317E5106566B for ; Fri, 24 Sep 2010 15:46:17 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id CCB6B8FC24 for ; Fri, 24 Sep 2010 15:46:16 +0000 (UTC) Received: from [77.109.131.203] (port=62859 helo=dynip67.office.hostpoint.internal) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OzATP-000CoA-26; Fri, 24 Sep 2010 17:46:07 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <20100924122839.P842@delplex.bde.org> Date: Fri, 24 Sep 2010 17:46:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C64D46D-1B34-46E7-A736-52199050B5F5@hostpoint.ch> References: <201009231938.09548.cal@linu.gs> <66757A1E-E445-4AAD-8F57-382D85BFD579@hostpoint.ch> <20100924122839.P842@delplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs Subject: Re: Strange behaviour with sappend flag set 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, 24 Sep 2010 15:46:17 -0000 On 24.09.2010, at 05:16, Bruce Evans wrote: > On Fri, 24 Sep 2010, Markus Gebert wrote: >=20 >> On 23.09.2010, at 19:38, Michael Naef wrote: >>=20 >>> If I open (2) a file with O_APPEND the fd position pointer is set >>> to the start of the file. When I then write to an fd on a ufs FS in >>> FB6.4, it is automatically moved to the end and the bytes are >>> appended. No problems appear with write to the sappend-flages file. >>>=20 >>> However if I do the same on FB8.1/ZFS, the write fails as "not >>> permitted". >>=20 >> To me, it seems that the zfs_write() VOP incorrectly uses FAPPEND = instead of IO_APPEND when checking the ioflag argument to see if the = current write is an appending one, here: >>=20 >> ---- >> /* >> * If immutable or not appending then return EPERM >> */ >> pflags =3D zp->z_phys->zp_flags; >> if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || >> ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && >> (uio->uio_loffset < zp->z_phys->zp_size))) { >> ZFS_EXIT(zfsvfs); >> return (EPERM); >> } >> ---- >>=20 >> The function comment only mentions IO_APPEND and even later on in = zfs_write() IO_APPEND is used to check wether the offset should be = changed to EOF, so FAPPEND really seems to wrong in the above permission = check. >=20 > Oops, the file[descriptor] append flags aren't all the same like I = said in > a previous reply. FAPPEND is identical with O_APPEND and is 8, but = IO_APPEND > is 2. Here zfs is testing IO_NODELOCKED =3D 8. Yes, I checked that before posting and forgot to mention it, sorry for = that, could have saved you some time :-). Then again if it had been a = "spelling-only bug", my patch wouldn't have changed any behaviour, but = instead it did make Michi's test case work properly. > The use of IO_NODELOCKED is confusing and slightly broken. It is only > a flag for vn_rdwr() and a couple of other in-kernel i/o functions. > These start with the vnode locked and set IO_NODELOCKED to tell = vn_rdwr() > not to lock again. Userland writes call vn_rdwr() without the vnode > locked and keep IO_NODELOCKED clear to tell vn_rdwr() to lock the > vnode. vn_rdwr() doesn't set it so it is garbage after that -- it = remains > consistent with the vnode lock state for in-kernel writes, but for = userland > writes it is inconsistent with the vnode lock state below the level of > vn_rdwr(). VOP_WRITE() is called from places other than vn_rdwr(), = and > most or all of these places also fail to set IO_NODELOCKED. They also > mostly or always know that they are for in-kernel writes, so they also > don't check IO_NODELOCKED. >=20 > Thus in the above, the FAPPEND bit is usually clear so the test = doesn't > work (the cases where FAPPEND is set where it should be clear, and > where ZFS_APPENDONLY is also set, are rare since they only occur for > in-kernel writes of things like core dumps, and you have other = problems > if you have many append-only files being written to for things like > core dumps). My previous mail was incorrect about this point, and > understated the ways in which the comment doesn't match the code -- > apart from FAPPEND not being the append-flag, the comment combined > with the reported behaviour and mu confusion about the equality of the > flags helped me misread the IO_APPEND test backwards. Makes sense. This explains why the test case failed so realiably = although zfs_write() checked the wrong bit. > There is similar confusion and possibly bugs for IO_UNIT. Now all > callers seem to set it, and most VOP_WRITE() functions can't work = right > without it. E.g., they all need to back out of short writes to = satisfy > the implementation of sys_generic.c:write(); ffs_write() only backs > out ionly if IO_UNIT is set; it is always set for userland writes so > there is no problem with write(), but why not remove it as a flag and > always do atomic writes to simplify things? Kernel writers are even > less prepared than userland writers to recover from short writes. >=20 >> CURRENT and STABLE-8 seem to be affected to. The following patch = seems to fix it (at least Michi's test case works fine with it): >>=20 >> ---- >> diff -ru = ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c >> --- ../src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = 2010-05-19 08:49:52.000000000 +0200 >> +++ ./sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c = 2010-09-23 23:24:43.549846948 +0200 >> @@ -709,7 +709,7 @@ >> */ >> pflags =3D zp->z_phys->zp_flags; >> if ((pflags & (ZFS_IMMUTABLE | ZFS_READONLY)) || >> - ((pflags & ZFS_APPENDONLY) && !(ioflag & FAPPEND) && >> + ((pflags & ZFS_APPENDONLY) && !(ioflag & IO_APPEND) && >> (uio->uio_loffset < zp->z_phys->zp_size))) { >> ZFS_EXIT(zfsvfs); >> return (EPERM); >=20 > Now I think the not-just-a-spelling error was the only major bug, and = this > fixes it. Ok. Anyone going to commit the patch? > There is another minor bug/inconsistency with ffs: in the = non-IO_APPEND > case, ffs requires the offset to =3D=3D the file size, while the above > allows it to be >=3D the file size. I assume you're talking about the "file has appending-only flag set but = IO_APPEND is not set" case (I didn't look at the ufs code). The lseek(2) man page says: ---- The lseek() system call allows the file offset to be set beyond the = end of the existing end-of-file of the file. If data is later written = at this point, subsequent reads of the data in the gap return bytes of = zeros (until data is actually written into the gap). ---- Don't know VFS well enough to tell, but why would appending something = with a gap/hole (of zeroes) before it not be considered appending (in = the append-only file flag sense)? Unless I missed something (like the = offset being modified somewhere else in the kernel before the VOP call), = depending on how one answers this question, either UFS or ZFS is right, = it seems. Markus From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 17:06:59 2010 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 0CDB7106564A for ; Fri, 24 Sep 2010 17:06:59 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C3BF58FC0C for ; Fri, 24 Sep 2010 17:06:58 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 08BF0295; Fri, 24 Sep 2010 13:06:58 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 24 Sep 2010 13:06:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:to:subject:date:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; s=smtpout; bh=t8kHC6zgCan6+UKl8phHlvwaDmE=; b=rouSNTB/DNcO7FGkUOzo0a+UmZsJe1Gvr+uSCabA3//OElRV7O9RSxwoYATNYiCvzzBVQqdhWRK4stKXFxEBZahQxLwDvQB0jL6XUXllB2ZDaUNsM5gUBrnNubi8u8q+yp4pg6dQGGPUfUwewRsI9G3lDDclKiTrFzwDcRs+j4w= X-Sasl-enc: MhYX0a80k5o7BOXogD7joENabPLXa8MEjMByVtXdGVzs 1285348016 Received: from tcbug.ixsystems.com (74-34-16-134.dr01.rsmt.mn.frontiernet.net [74.34.16.134]) by mail.messagingengine.com (Postfix) with ESMTPSA id C6C4E5E0F56; Fri, 24 Sep 2010 13:06:56 -0400 (EDT) From: Josh Paetzel To: freebsd-fs@freebsd.org Date: Fri, 24 Sep 2010 12:06:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.4.5; amd64; ; ) References: <4C9C7C32.3070909@fragfest.com.au> In-Reply-To: <4C9C7C32.3070909@fragfest.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15124792.1rSBoADPcJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201009241206.53828.josh@tcbug.org> Cc: Subject: Re: growfs on a large disk 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, 24 Sep 2010 17:06:59 -0000 --nextPart15124792.1rSBoADPcJ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Friday, September 24, 2010 05:23:46 am Dean Hamstead wrote: > Evening, >=20 > Im trying to growfs a very large filesystem and not having a lot of luck. >=20 > To give some background, im running the filesystem on a raid array > running on an areca raid card. I have an existing filesytem which was > formatting /dev/da0 and mounting it. (I understand that this is the > preferred alternative to the deprecated 'dangerously dedicated' mode). >=20 > I have expanded the disk array and the volume at the raid card level. > Then rebooted my machine. It was 4x2tb, and is now 5x2tb. Expanding on > areca is non-destructive. >=20 > Here is the current filesystem size when mounted, da0 is the >=20 > ----- >=20 > [root@batou /home/dean]# df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/ad4a 496M 280M 176M 61% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/ad4e 496M 155M 301M 34% /tmp > /dev/ad4f 68G 8.0G 54G 13% /usr > /dev/ad4d 1.9G 529M 1.2G 30% /var > /dev/da1 4.4T 4.4T 28G 99% /volumes/store2 > /dev/da0 5.3T 3.9T 1.4T 74% /volumes/store1 >=20 > ----- >=20 > From dmesg you can see that freebsd knows its now bigger (7.6 rather > than 5.3tb) >=20 > ----- >=20 > da0 at arcmsr0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) > da0: Command Queueing enabled > da0: 7629394MB (15624998912 512 byte sectors: 255H 63S/T 972611C) > da1 at arcmsr0 bus 0 scbus0 target 0 lun 1 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) > da1: Command Queueing enabled > da1: 4768371MB (9765624320 512 byte sectors: 255H 63S/T 607881C) > SMP: AP CPU #1 Launched! >=20 > ----- >=20 > if we consult diskinfo, it agrees >=20 > ----- >=20 > [root@batou /home/dean]# diskinfo -v /dev/da0 > /dev/da0 > 512 # sectorsize > 7999999442944 # mediasize in bytes (7.3T) > 15624998912 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 972611 # Cylinders according to firmware. > 255 # Heads according to firmware. > 63 # Sectors according to firmware. > 0000001379342420 # Disk ident. >=20 >=20 > ----- >=20 > fdisk shows us... >=20 > ----- >=20 > [root@batou /home/dean]# fdisk /dev/da0 > ******* Working on device /dev/da0 ******* > parameters extracted from in-core disklabel are: > cylinders=3D972611 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=3D972611 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > fdisk: invalid fdisk partition table found > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 2740094532 (1337936 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 578/ head 254/ sector 63 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > >=20 > ----- >=20 > now if i unmount /dev/da0 and run growfs /dev/da0 i get the following >=20 > ----- >=20 > [root@batou /home/dean]# growfs /dev/da0 > growfs: we are not growing (2929687296->685024256) >=20 >=20 > ----- >=20 > with lots of googling, i have found that there is much talk in various > freebsd forums about the need to use disklabel. however it seems unable > to fathom such a large disk... >=20 > ----- >=20 > [root@batou /home/dean]# disklabel /dev/da0 > disklabel: disks with more than 2^32-1 sectors are not supported >=20 >=20 > ---- >=20 > freebsd version is 8.0 64bit >=20 > ----- >=20 > [root@batou /home/dean]# uname -a > FreeBSD batou.fragfest.net.au 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Jan > 24 17:13:52 EST 2010 > dean@batou.fragfest.net.au:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > ----- >=20 > hopefully i am doing something wrong, or there is a patch set for growfs? >=20 >=20 >=20 > Dean I've run growfs on raw partitions, it's the easiest way to use growfs, as y= ou=20 don't need to worrk about expanding partitions or slices. Sadly the last time I ran it was expanding a RAID array of 4 320 gig disks= =20 from RAID 10 to RAID 5, so from ~ 640 gigs to 960 gigs. Not sure if you are running into a growfs limitation, you're certainly runn= ing=20 into the limits of UFS with those sizes. Have you considered ZFS? At this point you can't put a bsdlabel on, as your filesystem probably=20 encroaches on the area the label would need anyways. Similarly the fdisk=20 output is fairly meaningless, as you aren't using a fdisk partition. To=20 verify ls /dev/da0* should only show /dev/da0, if it shows slices that woul= d=20 be bad. The man page for growfs mentions that some free space is needed in the firs= t=20 cylinder group to resize. Perhaps that is the problem you are running in t= o. =2D-=20 Thanks, Josh Paetzel --nextPart15124792.1rSBoADPcJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAABAgAGBQJMnNqtAAoJEKFq1/n1feG2eKoIAIeA9C8SNghbumk28lWSv5Th IJ7p1KcSW9mNjmOXiEZIXcs3bnNKM/326S57y2mo+aWV+4j1iPeTS+3eOtYNpOcF 2vFdNgfa0RKjDxGPckm8vX1oT6p3cfEIAX5nps+MqmMHKxpraxv+rESbRrWZuuj/ cETJyKThK/1wGSwFK70/b1guIJdhO9gHlyPofHXc+/Y+4CpnxFCPruIouy5ltH3q D+B5U2n9f73ZJgNitJcUKzqQDlOJCf7CqDyEQ6gNZmBeEk4rqvgWKYldi3hCWEEo J33TL2QJ7D75sbKT6zX/PkzYZ02D2II52naes6dASwddSm83a+l0lH9GMpbAI+A= =lObd -----END PGP SIGNATURE----- --nextPart15124792.1rSBoADPcJ-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 19:10:12 2010 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 A566610656A4 for ; Fri, 24 Sep 2010 19:10:12 +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 941668FC26 for ; Fri, 24 Sep 2010 19:10:12 +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 o8OJAC9T072580 for ; Fri, 24 Sep 2010 19:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OJACbO072574; Fri, 24 Sep 2010 19:10:12 GMT (envelope-from gnats) Date: Fri, 24 Sep 2010 19:10:12 GMT Message-Id: <201009241910.o8OJACbO072574@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/107692: 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: Fri, 24 Sep 2010 19:10:12 -0000 The following reply was made to PR bin/107692; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/107692: commit references a PR Date: Fri, 24 Sep 2010 19:09:02 +0000 (UTC) Author: mckusick Date: Fri Sep 24 19:08:56 2010 New Revision: 213119 URL: http://svn.freebsd.org/changeset/base/213119 Log: Reported problem: Large (60GB) filesystems created using "newfs -U -O 1 -b 65536 -f 8192" show incorrect results from "df" for free and used space when mounted immediately after creation. fsck on the new filesystem (before ever mounting it once) gives a "SUMMARY INFORMATION BAD" error in phase 5. This error hasn't occurred in any runs of fsck immediately after "newfs -U -b 65536 -f 8192" (leaving out the "-O 1" option). Solution: The default UFS1 superblock is located at offset 8K in the filesystem partition; the default UFS2 superblock is located at offset 64K in the filesystem partition. For UFS1 filesystems with a blocksize of 64K, the first alternate superblock resides at 64K which is the the location used for the default UFS2 superblock. By default, the system first checks for a valid superblock at the default location for a UFS2 filoesystem. For a UFS1 filesystem with a blocksize of 64K, there is a valid UFS1 superblock at this location. Thus, even though it is expected to be a backup superblock, the system will use it as its default superblock. So, we have to ensure that all the statistcs on usage are correct in this first alternate superblock as it is the superblock that will actually be used. While tracking down this problem, another limitation of UFS1 became evident. For UFS1, the number of inodes per cylinder group is stored in an int16_t. Thus the maximum number of inodes per cylinder group is limited to 2^15 - 1. This limit can easily be exceeded for block sizes of 32K and above. Thus when building UFS1 filesystems, newfs must limit the number of inodes per cylinder group to 2^15 - 1. Reported by: Guy Helmer Followup by: Bruce Cran PR: 107692 MFC after: 4 weeks Modified: head/sbin/newfs/mkfs.c Modified: head/sbin/newfs/mkfs.c ============================================================================== --- head/sbin/newfs/mkfs.c Fri Sep 24 19:07:14 2010 (r213118) +++ head/sbin/newfs/mkfs.c Fri Sep 24 19:08:56 2010 (r213119) @@ -376,16 +376,20 @@ restart: * Start packing more blocks into the cylinder group until * it cannot grow any larger, the number of cylinder groups * drops below MINCYLGRPS, or we reach the size requested. + * For UFS1 inodes per cylinder group are stored in an int16_t + * so fs_ipg is limited to 2^15 - 1. */ for ( ; sblock.fs_fpg < maxblkspercg; sblock.fs_fpg += sblock.fs_frag) { sblock.fs_ipg = roundup(howmany(sblock.fs_fpg, fragsperinode), INOPB(&sblock)); - if (sblock.fs_size / sblock.fs_fpg < MINCYLGRPS) - break; - if (CGSIZE(&sblock) < (unsigned long)sblock.fs_bsize) - continue; - if (CGSIZE(&sblock) == (unsigned long)sblock.fs_bsize) - break; + if (Oflag > 1 || (Oflag == 1 && sblock.fs_ipg <= 0x7fff)) { + if (sblock.fs_size / sblock.fs_fpg < MINCYLGRPS) + break; + if (CGSIZE(&sblock) < (unsigned long)sblock.fs_bsize) + continue; + if (CGSIZE(&sblock) == (unsigned long)sblock.fs_bsize) + break; + } sblock.fs_fpg -= sblock.fs_frag; sblock.fs_ipg = roundup(howmany(sblock.fs_fpg, fragsperinode), INOPB(&sblock)); @@ -584,8 +588,20 @@ restart: printf("** Exiting on Xflag 3\n"); exit(0); } - if (!Nflag) + if (!Nflag) { do_sbwrite(&disk); + /* + * For UFS1 filesystems with a blocksize of 64K, the first + * alternate superblock resides at the location used for + * the default UFS2 superblock. As there is a valid + * superblock at this location, the boot code will use + * it as its first choice. Thus we have to ensure that + * all of its statistcs on usage are correct. + */ + if (Oflag == 1 && sblock.fs_bsize == 65536) + wtfs(fsbtodb(&sblock, cgsblock(&sblock, 0)), + sblock.fs_bsize, (char *)&sblock); + } for (i = 0; i < sblock.fs_cssize; i += sblock.fs_bsize) wtfs(fsbtodb(&sblock, sblock.fs_csaddr + numfrags(&sblock, i)), sblock.fs_cssize - i < sblock.fs_bsize ? _______________________________________________ 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 Fri Sep 24 19:27:26 2010 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 47D081065673; Fri, 24 Sep 2010 19:27:26 +0000 (UTC) (envelope-from mckusick@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 382CE8FC19; Fri, 24 Sep 2010 19:27:26 +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 o8OJRQFd092309; Fri, 24 Sep 2010 19:27:26 GMT (envelope-from mckusick@freefall.freebsd.org) Received: (from mckusick@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OJRPKM092305; Fri, 24 Sep 2010 19:27:25 GMT (envelope-from mckusick) Date: Fri, 24 Sep 2010 19:27:25 GMT Message-Id: <201009241927.o8OJRPKM092305@freefall.freebsd.org> To: ghelmer@palisadesys.com, mckusick@FreeBSD.org, freebsd-fs@FreeBSD.org, mckusick@FreeBSD.org From: mckusick@FreeBSD.org Cc: Subject: Re: bin/107692: newfs(8): newfs -O 1 doesn't create consistent filesystems 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, 24 Sep 2010 19:27:26 -0000 Synopsis: newfs(8): newfs -O 1 doesn't create consistent filesystems State-Changed-From-To: open->patched State-Changed-By: mckusick State-Changed-When: Fri Sep 24 19:25:32 UTC 2010 State-Changed-Why: I am taking responsibility for this bug. A fix has been applied to head. If no problems arise it will be MFC'ed to 7-stable and 8-stable in 4 weeks time. Responsible-Changed-From-To: freebsd-fs->mckusick Responsible-Changed-By: mckusick Responsible-Changed-When: Fri Sep 24 19:25:32 UTC 2010 Responsible-Changed-Why: I am taking responsibility for this bug. A fix has been applied to head. If no problems arise it will be MFC'ed to 7-stable and 8-stable in 4 weeks time. http://www.freebsd.org/cgi/query-pr.cgi?pr=107692 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:48:09 2010 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 76EF0106564A; Fri, 24 Sep 2010 20:48:09 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5248FC1A; Fri, 24 Sep 2010 20:48:09 +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 o8OKm9bw075981; Fri, 24 Sep 2010 20:48:09 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKm91C075977; Fri, 24 Sep 2010 20:48:09 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:48:09 GMT Message-Id: <201009242048.o8OKm91C075977@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/87966: [patch] newfs(8): introduce -A flag for newfs to enable ACLs 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, 24 Sep 2010 20:48:09 -0000 Synopsis: [patch] newfs(8): introduce -A flag for newfs to enable ACLs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:47:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=87966 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:48:44 2010 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 BBFF210656C4; Fri, 24 Sep 2010 20:48:44 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 85CF18FC1E; Fri, 24 Sep 2010 20:48:44 +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 o8OKmifm076032; Fri, 24 Sep 2010 20:48:44 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKmiN6076028; Fri, 24 Sep 2010 20:48:44 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:48:44 GMT Message-Id: <201009242048.o8OKmiN6076028@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/97498: [request] newfs(8) has no option to clear the first 128 sectors 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, 24 Sep 2010 20:48:44 -0000 Synopsis: [request] newfs(8) has no option to clear the first 128 sectors Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:48:25 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=97498 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:49:28 2010 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 DEB99106566B; Fri, 24 Sep 2010 20:49:28 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7B6B8FC1B; Fri, 24 Sep 2010 20:49:28 +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 o8OKnSIq076079; Fri, 24 Sep 2010 20:49:28 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKnSs8076075; Fri, 24 Sep 2010 20:49:28 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:49:28 GMT Message-Id: <201009242049.o8OKnSs8076075@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/70600: fsck(8) throws files away when it can't grow lost+found 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, 24 Sep 2010 20:49:29 -0000 Synopsis: fsck(8) throws files away when it can't grow lost+found Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:49:10 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=70600 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:50:15 2010 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 DE1CC1065674; Fri, 24 Sep 2010 20:50:15 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B515B8FC1E; Fri, 24 Sep 2010 20:50:15 +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 o8OKoFQs077414; Fri, 24 Sep 2010 20:50:15 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKoFpp077409; Fri, 24 Sep 2010 20:50:15 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:50:15 GMT Message-Id: <201009242050.o8OKoFpp077409@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/85494: fsck_ffs: unchecked use of cg_inosused macro etc. 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, 24 Sep 2010 20:50:16 -0000 Synopsis: fsck_ffs: unchecked use of cg_inosused macro etc. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:49:57 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=85494 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:50:59 2010 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 0860D106566B; Fri, 24 Sep 2010 20:50:59 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D2D7F8FC1A; Fri, 24 Sep 2010 20:50:58 +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 o8OKowVx083898; Fri, 24 Sep 2010 20:50:58 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKowh3083886; Fri, 24 Sep 2010 20:50:58 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:50:58 GMT Message-Id: <201009242050.o8OKowh3083886@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/94810: fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up 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, 24 Sep 2010 20:50:59 -0000 Synopsis: fsck(8) incorrectly reports 'file system marked clean' when lost+found fills up Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:50:39 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=94810 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:51:41 2010 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 92D851065695; Fri, 24 Sep 2010 20:51:41 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69A328FC1D; Fri, 24 Sep 2010 20:51:41 +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 o8OKpf7n085364; Fri, 24 Sep 2010 20:51:41 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKpfGD085360; Fri, 24 Sep 2010 20:51:41 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:51:41 GMT Message-Id: <201009242051.o8OKpfGD085360@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/127270: fsck_msdosfs(8) may crash if BytesPerSec is zero 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, 24 Sep 2010 20:51:41 -0000 Synopsis: fsck_msdosfs(8) may crash if BytesPerSec is zero Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:51:15 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127270 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:52:37 2010 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 2CBD11065675; Fri, 24 Sep 2010 20:52:37 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 033A28FC0A; Fri, 24 Sep 2010 20:52:37 +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 o8OKqa1N085459; Fri, 24 Sep 2010 20:52:36 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKqaEk085455; Fri, 24 Sep 2010 20:52:36 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:52:36 GMT Message-Id: <201009242052.o8OKqaEk085455@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/27687: fsck(8) wrapper is not properly passing options to fsck_ 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, 24 Sep 2010 20:52:37 -0000 Synopsis: fsck(8) wrapper is not properly passing options to fsck_ Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:52:17 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=27687 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:55:40 2010 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 F3042106566B; Fri, 24 Sep 2010 20:55:39 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA0888FC1D; Fri, 24 Sep 2010 20:55:39 +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 o8OKtd4o085551; Fri, 24 Sep 2010 20:55:39 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKtdVM085547; Fri, 24 Sep 2010 20:55:39 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:55:39 GMT Message-Id: <201009242055.o8OKtdVM085547@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/94635: snapinfo(8)/libufs only works for disk-backed filesystems 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, 24 Sep 2010 20:55:40 -0000 Synopsis: snapinfo(8)/libufs only works for disk-backed filesystems Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:53:37 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). It looks like this issue has been fixed on 7.x and 8.x. Should the fix be merged to 6.x or can this PR be closed? http://www.freebsd.org/cgi/query-pr.cgi?pr=94635 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:56:42 2010 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 628DF1065674; Fri, 24 Sep 2010 20:56:42 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 396598FC1E; Fri, 24 Sep 2010 20:56: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 o8OKughq085607; Fri, 24 Sep 2010 20:56:42 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKugHk085603; Fri, 24 Sep 2010 20:56:42 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:56:42 GMT Message-Id: <201009242056.o8OKugHk085603@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/88555: [panic] ffs_blkfree: freeing free frag on AMD 64 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, 24 Sep 2010 20:56:42 -0000 Synopsis: [panic] ffs_blkfree: freeing free frag on AMD 64 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:56:19 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=88555 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:57:21 2010 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 C40B2106564A; Fri, 24 Sep 2010 20:57:21 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3778FC08; Fri, 24 Sep 2010 20:57:21 +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 o8OKvL4o085674; Fri, 24 Sep 2010 20:57:21 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKvLZv085670; Fri, 24 Sep 2010 20:57:21 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:57:21 GMT Message-Id: <201009242057.o8OKvLZv085670@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/138662: [panic] ffs_blkfree: freeing free block 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, 24 Sep 2010 20:57:21 -0000 Synopsis: [panic] ffs_blkfree: freeing free block Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:56:57 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138662 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:58:46 2010 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 B0153106566B; Fri, 24 Sep 2010 20:58:46 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86C1D8FC1B; Fri, 24 Sep 2010 20:58:46 +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 o8OKwkUj085760; Fri, 24 Sep 2010 20:58:46 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKwktW085756; Fri, 24 Sep 2010 20:58:46 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:58:46 GMT Message-Id: <201009242058.o8OKwktW085756@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/135667: [lor] LORs causing ufs filesystem corruption on XEN DomU system 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, 24 Sep 2010 20:58:46 -0000 Synopsis: [lor] LORs causing ufs filesystem corruption on XEN DomU system Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:58:27 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135667 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 20:59:48 2010 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 D7D371065672; Fri, 24 Sep 2010 20:59:48 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AEA088FC15; Fri, 24 Sep 2010 20:59:48 +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 o8OKxm3c085832; Fri, 24 Sep 2010 20:59:48 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8OKxm9d085828; Fri, 24 Sep 2010 20:59:48 GMT (envelope-from brucec) Date: Fri, 24 Sep 2010 20:59:48 GMT Message-Id: <201009242059.o8OKxm9d085828@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/74779: Background-fsck checks one filesystem twice and omits another 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, 24 Sep 2010 20:59:48 -0000 Synopsis: Background-fsck checks one filesystem twice and omits another Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:59:29 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=74779 From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 21:12:07 2010 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 2438F106564A for ; Fri, 24 Sep 2010 21:12:07 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id A769E8FC14 for ; Fri, 24 Sep 2010 21:12:06 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8OLC3dK028281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Sep 2010 07:12:04 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o8OLC1FU021848; Sat, 25 Sep 2010 07:12:01 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o8OLC0QD021847; Sat, 25 Sep 2010 07:12:00 +1000 (EST) (envelope-from peter) Date: Sat, 25 Sep 2010 07:12:00 +1000 From: Peter Jeremy To: Zaphod Beeblebrox Message-ID: <20100924211200.GA49476@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs Subject: Re: Oracle to deny deduplication? 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, 24 Sep 2010 21:12:07 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Sep-22 00:26:20 -0400, Zaphod Beeblebrox wrote: >On Tue, Sep 21, 2010 at 3:21 PM, Bob Friesenhahn > wrote: >> On Tue, 21 Sep 2010, Zaphod Beeblebrox wrote: >>> >>> Shortly thereafter I found a nice table (here: >>> http://docs.sun.com/app/docs/doc/819-5461/appendixa-1?a=3Dview ) >>> >>> ... now notice that the official Oracle table lists version 21 of >>> zpool as "Reserved" ... this worries me. =A0Is the solution to the >>> lawsuit against Sun by NetApp (that Oracle settled) that Oracle burys >>> deduplication? =A0This could be bad for people who unbury it. > >Even if you are correct, I'm still quite wary of Oracle's support of >ZFS. Oracle is not known as a "nice" entity. Agreed, but in this case, I also suspect that it's more of a technical issue than a legal issue. >But how would that work --- if you update the pool to 23 (22 or 23 is >the latest listed there?) then a filesystem with dedup would be read >... but you might not be able to set the attribute? Seems odd. It depends exactly what Oracle have done to the code. About the only way to get a definitive answer would be to create a v22 or v23 pool with dedup enabled and then attempt to import the pool on a S10U9 system. > The >ZFS implementation of dedup seems so "sensible" ... Maybe, but if you read some of the ZFS lists, you'll quickly find that lots of people ran into problems with it. Probably the biggest issue is the massive amount of cache you need with it (either RAM or a really fast L2ARC) - quite a few people got burnt creating dedup- enabled pools with snapshots that they then couldn't destroy in a realistic time. And my feeling was that there seemed to be a higher- than-usual level of other issues that people were reporting with dedup. As a SOHO user, I don't believe I'll be able to justify the cache costs associated with dedup, though I can see the benefits in some environments. Hopefully, the problems will be able to resolved and dedup will be "officially" available at some point in the future. --=20 Peter Jeremy --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkydFCAACgkQ/opHv/APuIeqowCfeENwvWQWMefOVhA3LA+XiiUP 8PMAn2PW+VakkNVv2Y0VgyadoljKDCF/ =msUp -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 24 21:21:56 2010 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 345D8106566B for ; Fri, 24 Sep 2010 21:21:56 +0000 (UTC) (envelope-from rick@rix.kiwi-computer.com) Received: from rix.kiwi-computer.com (66-191-70-202.static.stcd.mn.charter.com [66.191.70.202]) by mx1.freebsd.org (Postfix) with SMTP id DED4B8FC0C for ; Fri, 24 Sep 2010 21:21:55 +0000 (UTC) Received: (qmail 860 invoked by uid 2000); 24 Sep 2010 21:21:54 -0000 Date: Fri, 24 Sep 2010 16:21:54 -0500 From: "Rick C. Petty" To: Josh Paetzel , Dean Hamstead Message-ID: <20100924212154.GA263@rix.kiwi-computer.com> References: <4C9C7C32.3070909@fragfest.com.au> <201009241206.53828.josh@tcbug.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009241206.53828.josh@tcbug.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: growfs on a large disk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 21:21:56 -0000 > On Friday, September 24, 2010 05:23:46 am Dean Hamstead wrote: > > > > To give some background, im running the filesystem on a raid array > > running on an areca raid card. I have an existing filesytem which was > > formatting /dev/da0 and mounting it. (I understand that this is the > > preferred alternative to the deprecated 'dangerously dedicated' mode). I thought using the whole device *was* the "dangerously dedicated" mode, since there is no partition table on the disk this way. http://www.freebsd.org/doc/en/books/faq/disks.html#DANGEROUSLY-DEDICATED > > fdisk shows us... This is meaningless if you're using dangerously-dedicated disks. > > now if i unmount /dev/da0 and run growfs /dev/da0 i get the following > > > > [root@batou /home/dean]# growfs /dev/da0 > > growfs: we are not growing (2929687296->685024256) Looks like an integer maybe wrapped around somewhere? I can't tell for sure. > > with lots of googling, i have found that there is much talk in various > > freebsd forums about the need to use disklabel. however it seems unable > > to fathom such a large disk... If you're already using the device in dangerously-dedicated mode, you may not be able to disklabel it. Besides, you should use GPT instead. #see gpart(8) > > [root@batou /home/dean]# disklabel /dev/da0 > > disklabel: disks with more than 2^32-1 sectors are not supported This is true, which is why I'm surprised anyone recommended disklabel. And "disklabel" was deprecated in favor of "bsdlabel". > > hopefully i am doing something wrong, or there is a patch set for growfs? I'm not sure growfs is your problem. Are you using UFS1 or UFS2? What did you specify as the fragment size when creating the file system? You can find this out by doing: ffsinfo -l 1 /dev/da0 | egrep '(fsize|magic)' On Fri, Sep 24, 2010 at 12:06:45PM -0500, Josh Paetzel wrote: > Not sure if you are running into a growfs limitation, you're certainly running > into the limits of UFS with those sizes. Have you considered ZFS? You must be talking about UFS1, because UFS2 can support devices in the zettabytes (billions of terabytes). #see http://en.wikipedia.org/wiki/UFS2 > The man page for growfs mentions that some free space is needed in the first > cylinder group to resize. Perhaps that is the problem you are running in to. The OP's best option is to dump/restore the filesystem, thereby correcting the "dangerously-dedicated" problem as well as use a partitioning scheme invented this millenium (GPT). -- Rick C. Petty From owner-freebsd-fs@FreeBSD.ORG Sat Sep 25 03:13:06 2010 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 06668106566B; Sat, 25 Sep 2010 03:13:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0868FC15; Sat, 25 Sep 2010 03:13:04 +0000 (UTC) Received: from c122-107-116-249.carlnfd1.nsw.optusnet.com.au (c122-107-116-249.carlnfd1.nsw.optusnet.com.au [122.107.116.249]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8P3Cln3032042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Sep 2010 13:13:03 +1000 Date: Sat, 25 Sep 2010 13:12:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: brucec@freebsd.org In-Reply-To: <201009242052.o8OKqaEk085455@freefall.freebsd.org> Message-ID: <20100925122853.W839@delplex.bde.org> References: <201009242052.o8OKqaEk085455@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/27687: fsck(8) wrapper is not properly passing options to fsck_ 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, 25 Sep 2010 03:13:06 -0000 On Fri, 24 Sep 2010 brucec@freebsd.org wrote: > Synopsis: fsck(8) wrapper is not properly passing options to fsck_ > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > Responsible-Changed-By: brucec > Responsible-Changed-When: Fri Sep 24 20:52:17 UTC 2010 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=27687 In fact, the description of the problem already shows that it isn't a problem: % >Description: % % If one boots single user and then does % fsck -b 32 /foo % fsck reports: % fsck: illegal option -- b % Usage: fsck [-BFdpvlyn] [-T fstype:fsoptions] [-t fstype] [special|node]... % one must use fsck_ffs directly even though fsck should have every % thing it needs from /etc/fstab to DTRT. As fsck reports, it has a -T option for passing options. -Tufs:-b32 seems to work right. The man page says more about this, but doesn't say what happens with multiple -T or -t options. I think they are concatenated at the fsck level, with the order preserved, and then filtered when passed. So "-T ufs:-b16,-y -Tmsdosfs:-n -Tufs:-b32,-n" passes "-b16 -y -b32 -n" to fsck_ffs and "-n" to fsck_msdosfs. The effect of multiple options is also undocumented in fsck_ffs. In practice, the last one usually has precedence, but "-b16 -b32 -b64" causes fsck_ffs to print that it uses 3 alternates (sic) although it actually only uses 1 alternative (sic) (the last one). Multiple alternatives are especially useless and dangerous for -b (especially with multiple special files), but I used them in these examples and testing because they are good for generating messages for both errors and success. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Sep 25 04:48:38 2010 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 2AC251065673 for ; Sat, 25 Sep 2010 04:48:38 +0000 (UTC) (envelope-from dean@fragfest.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id A0BA88FC1C for ; Sat, 25 Sep 2010 04:48:37 +0000 (UTC) Received: from [172.29.0.132] (c122-106-145-234.carlnfd1.nsw.optusnet.com.au [122.106.145.234]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o8P4mXWV009975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Sep 2010 14:48:35 +1000 Message-ID: <4C9D7F38.1020106@fragfest.com.au> Date: Sat, 25 Sep 2010 14:48:56 +1000 From: Dean Hamstead User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100917 Icedove/3.0.8 MIME-Version: 1.0 To: Josh Paetzel References: <4C9C7C32.3070909@fragfest.com.au> <201009241206.53828.josh@tcbug.org> In-Reply-To: <201009241206.53828.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: growfs on a large disk 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, 25 Sep 2010 04:48:38 -0000 > I've run growfs on raw partitions, it's the easiest way to use growfs, as you > don't need to worrk about expanding partitions or slices. :) > Not sure if you are running into a growfs limitation, you're certainly running > into the limits of UFS with those sizes. Have you considered ZFS? Ive used ZFS in the past, but without going off topic, i have found it wanting. And at this stage, i dont have a large number of disks (or tape) to shift the data off and reformat. > At this point you can't put a bsdlabel on, as your filesystem probably > encroaches on the area the label would need anyways. Similarly the fdisk > output is fairly meaningless, as you aren't using a fdisk partition. To > verify ls /dev/da0* should only show /dev/da0, if it shows slices that would > be bad. > > The man page for growfs mentions that some free space is needed in the first > cylinder group to resize. Perhaps that is the problem you are running in to. Could well be. The man page didnt provide me with the insights i needed, hence consulting this list. The error message that growfs gives isnt as helpful as it could be so im about to dive through the source and see what causes this message to appear. Is there a way to free space in that cylinder group? Dean From owner-freebsd-fs@FreeBSD.ORG Sat Sep 25 15:19:30 2010 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 13F88106566B for ; Sat, 25 Sep 2010 15:19:30 +0000 (UTC) (envelope-from quazi@bk.ru) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.176.87]) by mx1.freebsd.org (Postfix) with ESMTP id A11588FC15 for ; Sat, 25 Sep 2010 15:19:29 +0000 (UTC) Received: from f209.mail.ru (f209.mail.ru [217.69.128.147]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id E115D29F4D74 for ; Sat, 25 Sep 2010 12:59:48 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:Date:Mime-Version:Subject:To:From; bh=55fOMaz1S1vRZldX6CX4j24CyLR39CH0T+D7Y9Xivzg=; b=p2IrPuqd1dVfW1VSogJfckYgMkvRppch8yPUcv+Wp0UTh8z1TEcFAI0EAhwEa8af7YQr6COunN01djRZK9mVfL3/zGpfAsGXL0pzh06OJIlP++b+lqZbHwCS9aaxRMg1; Received: from mail by f209.mail.ru with local id 1OzQbi-0003qf-00 for freebsd-fs@freebsd.org; Sat, 25 Sep 2010 12:59:46 +0400 Received: from [93.85.196.91] by koi.mail.ru with HTTP; Sat, 25 Sep 2010 12:59:46 +0400 From: Ruslan QuAzI To: freebsd-fs@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 192.168.0.1 via proxy [93.85.196.91] Date: Sat, 25 Sep 2010 12:59:46 +0400 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Subject: UFS SU+J X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruslan QuAzI List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 15:19:30 -0000 For a long time it is audible nothing about a subj. Does anybody plans to port UFS SU+J to FreeBSD 8? From owner-freebsd-fs@FreeBSD.ORG Sat Sep 25 15:32:48 2010 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 13DA2106566B for ; Sat, 25 Sep 2010 15:32:48 +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 C810B8FC08 for ; Sat, 25 Sep 2010 15:32:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4975:8ad9:4ce3:7a75] (unknown [IPv6:2001:7b8:3a7:0:4975:8ad9:4ce3:7a75]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 98ECD5C43; Sat, 25 Sep 2010 17:32:46 +0200 (CEST) Message-ID: <4C9E1623.4080600@FreeBSD.org> Date: Sat, 25 Sep 2010 17:32:51 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100910 Lanikai/3.1.4pre MIME-Version: 1.0 To: Ruslan QuAzI References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: UFS SU+J 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, 25 Sep 2010 15:32:48 -0000 On 2010-09-25 10:59, Ruslan QuAzI wrote: > For a long time it is audible nothing about a subj. Does anybody plans to port UFS SU+J to FreeBSD 8? See here (although it has not been updated for two months now): http://svn.freebsd.org/viewvc/base/projects/suj/8/