From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 10:00:10 2009 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 91820106564A for ; Mon, 9 Mar 2009 10:00:10 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD088FC0A for ; Mon, 9 Mar 2009 10:00:09 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LgcHI-0000GZ-VH for freebsd-fs@freebsd.org; Mon, 09 Mar 2009 10:00:09 +0000 Received: from whiteroom.bfh.ch ([147.87.102.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Mar 2009 10:00:08 +0000 Received: from ktk by whiteroom.bfh.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Mar 2009 10:00:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Adrian Gschwend Date: Mon, 09 Mar 2009 10:59:59 +0100 Organization: netlabs.org Lines: 28 Message-ID: References: <660f28ee8aa9c3a76b7d736e5ae3c229.squirrel@mail.netlabs.org> <20090224150217.GA15114@carrot> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: whiteroom.bfh.ch User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) In-Reply-To: <20090224150217.GA15114@carrot> Sender: news Subject: Re: kernel panic while writing to a ZFS volume on iSCSI LUN 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, 09 Mar 2009 10:00:11 -0000 Ulf Lilleengen wrote: > This is a problem with ZFS due to exhaustion of the kernel memory address > space (ZFS is quite hungry for memory). This can be solved by finely tuning > the different limits specified here: > > http://wiki.freebsd.org/ZFSTuningGuide > > You might have to do some try and fail to get it to work, but my experience > is that the problems is usually solveable if you invest enough time in the > tuning. thanks looks like I found the correct settings for the moment. Performance is pretty bad though but at least it doesn't crash anymore :) cu Adrian -- Adrian Gschwend @ netlabs.org ktk [a t] netlabs.org ------- Open Source Project http://www.netlabs.org From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 15:14:03 2009 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 45C301065690 for ; Mon, 9 Mar 2009 15:14:03 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 05B1B8FC17 for ; Mon, 9 Mar 2009 15:14:03 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 197C213999E for ; Mon, 9 Mar 2009 17:14:01 +0200 (EET) Date: Mon, 9 Mar 2009 17:14:00 +0200 From: Jaakko Heinonen To: freebsd-fs@FreeBSD.org Message-ID: <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> References: <200902192210.n1JMAddn009074@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902192210.n1JMAddn009074@svn.freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: [patch] invalidate NFS attribute cache if setattr fails with ESTALE 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, 09 Mar 2009 15:14:03 -0000 Hi, Here is a patch which changes nfs_setattrrpc() to invalidate the NFS attribute cache in case the RPC failed with ESTALE. The issue was originally reported by Timo Sirainen in PR kern/123755: > NFS client: open() a file > NFS server: unlink() the file > NFS client: fchown() the file -> ESTALE (as expected) > NFS client: fstat() the file -> success (not expected) %%% Index: sys/nfsclient/nfs_vnops.c =================================================================== --- sys/nfsclient/nfs_vnops.c (revision 188842) +++ sys/nfsclient/nfs_vnops.c (working copy) @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct nfsm_loadattr(vp, NULL); m_freem(mrep); nfsmout: + /* Invalidate the attribute cache if the NFS file handle is stale. */ + if (error == ESTALE) + np->n_attrstamp = 0; + return (error); } %%% Could someone take a look if this could be committed? -- Jaakko From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 16:29:34 2009 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 8C37A106581D for ; Mon, 9 Mar 2009 16:29:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 44BC18FC18 for ; Mon, 9 Mar 2009 16:29:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n29GTWsk003911; Mon, 9 Mar 2009 12:29:33 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n29GYXQ01603; Mon, 9 Mar 2009 12:34:34 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 9 Mar 2009 12:34:33 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jaakko Heinonen In-Reply-To: <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> Message-ID: References: <200902192210.n1JMAddn009074@svn.freebsd.org> <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-fs@FreeBSD.org Subject: Re: [patch] invalidate NFS attribute cache if setattr fails with ESTALE 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, 09 Mar 2009 16:29:38 -0000 On Mon, 9 Mar 2009, Jaakko Heinonen wrote: > > Hi, > > Here is a patch which changes nfs_setattrrpc() to invalidate the NFS > attribute cache in case the RPC failed with ESTALE. > > The issue was originally reported by Timo Sirainen in PR kern/123755: > >> NFS client: open() a file >> NFS server: unlink() the file >> NFS client: fchown() the file -> ESTALE (as expected) >> NFS client: fstat() the file -> success (not expected) > > %%% > Index: sys/nfsclient/nfs_vnops.c > =================================================================== > --- sys/nfsclient/nfs_vnops.c (revision 188842) > +++ sys/nfsclient/nfs_vnops.c (working copy) > @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct > nfsm_loadattr(vp, NULL); > m_freem(mrep); > nfsmout: > + /* Invalidate the attribute cache if the NFS file handle is stale. */ > + if (error == ESTALE) > + np->n_attrstamp = 0; > + > return (error); > } > > %%% > > Could someone take a look if this could be committed? > I'm not a committer, but I think that it might be appropriate to invalidate the attribute cache for any ESTALE reply from a server. (Since ESTALE implies that the file no linger exists on the server, I can't think why the attribute cache should remain valid for anything.) There is already code in nfs_request() that purges the name cache for ESTALE and I think that invalidating the cache there too, might make sense? For example, a patch something like... *** nfs_krpc.c.sav Sun Mar 8 23:45:35 2009 --- nfs_krpc.c Sun Mar 8 23:47:12 2009 *************** *** 520,527 **** * If the File Handle was stale, invalidate the lookup * cache, just in case. */ ! if (error == ESTALE) cache_purge(vp); /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS --- 520,529 ---- * If the File Handle was stale, invalidate the lookup * cache, just in case. */ ! if (error == ESTALE) { cache_purge(vp); + VTONFS(vp)->n_attrstamp = 0; + } /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS *** nfs_socket.c.sav Mon Mar 9 00:11:51 2009 --- nfs_socket.c Mon Mar 9 00:12:32 2009 *************** *** 1363,1370 **** * If the File Handle was stale, invalidate the * lookup cache, just in case. */ ! if (error == ESTALE) cache_purge(vp); /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they --- 1363,1372 ---- * If the File Handle was stale, invalidate the * lookup cache, just in case. */ ! if (error == ESTALE) { cache_purge(vp); + VTONFS(vp)->n_attrstamp = 0; + } /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they rick From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 17:15:03 2009 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 D3C091065693 for ; Mon, 9 Mar 2009 17:15:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C03F28FC12 for ; Mon, 9 Mar 2009 17:15:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n29HF3nl045230 for ; Mon, 9 Mar 2009 17:15:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n29HF3W2045226 for freebsd-fs@FreeBSD.org; Mon, 9 Mar 2009 17:15:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Mar 2009 17:15:03 GMT Message-Id: <200903091715.n29HF3W2045226@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, 09 Mar 2009 17:15:04 -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/132337 fs [zfs] [panic] kernel panic in zfs_fuid_create_cred o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132145 fs [panic] File System Hard Crashes f kern/132068 fs [zfs] page fault when using ZFS over NFS on 7.1-RELEAS o kern/131995 fs [nfs] Failure to mount NFSv4 server 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/131086 fs [ext2fs] mkfs.ext2 creates rotten partition o kern/131084 fs [xfs] xfs destroys itself after copying data o kern/131081 fs [zfs] User cannot delete a file when a ZFS dataset is o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o bin/130105 fs [zfs] zfs send -R dumps core o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129174 fs [nfs] [zfs] [panic] NFS v3 Panic when under high load o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129084 fs [udf] [panic] [lor] udf panic: getblk: size(67584) > M f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/128633 fs [zfs] [lor] lock order reversal in zfs o kern/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad f kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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 f kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs] [panic] changing into .zfs dir from nfs client c f kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po 46 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 20:36:26 2009 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 BA5D01065673; Mon, 9 Mar 2009 20:36:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9018A8FC14; Mon, 9 Mar 2009 20:36:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n29KaQEX009752; Mon, 9 Mar 2009 20:36:26 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n29KaQSk009748; Mon, 9 Mar 2009 20:36:26 GMT (envelope-from gavin) Date: Mon, 9 Mar 2009 20:36:26 GMT Message-Id: <200903092036.n29KaQSk009748@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/132397: reboot causes filesystem corruption (failure to sync buffers/vnodes) 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, 09 Mar 2009 20:36:27 -0000 Old Synopsis: reboot causes filesystem corruption New Synopsis: reboot causes filesystem corruption (failure to sync buffers/vnodes) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: gavin Responsible-Changed-When: Mon Mar 9 20:29:53 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) who may be able to at least answer some of these questions. http://www.freebsd.org/cgi/query-pr.cgi?pr=132397 From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 11:49:40 2009 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464291065674 for ; Tue, 10 Mar 2009 11:49:40 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id C8F608FC1C for ; Tue, 10 Mar 2009 11:49:39 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 582B01C1533A; Tue, 10 Mar 2009 12:32:45 +0100 (CET) Received: from localhost (dynscan2.mnet-online.de [192.168.1.215]) by mail.m-online.net (Postfix) with ESMTP id E034C9015F; Tue, 10 Mar 2009 12:31:24 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.1.215]) (amavisd-new, port 10024) with ESMTP id I250jF3TIims; Tue, 10 Mar 2009 12:31:22 +0100 (CET) Received: from mail.reifenberger.com (ppp-93-104-117-41.dynamic.mnet-online.de [93.104.117.41]) by mail.mnet-online.de (Postfix) with ESMTP; Tue, 10 Mar 2009 12:31:22 +0100 (CET) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 91DD23F629; Tue, 10 Mar 2009 12:31:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 907B53F628; Tue, 10 Mar 2009 12:31:22 +0100 (CET) Date: Tue, 10 Mar 2009 12:31:22 +0100 (CET) From: Michael Reifenberger To: pjd@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: fs@freebsd.org Subject: speedup "zpool scrub" under current. 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, 10 Mar 2009 11:49:40 -0000 Hi, is there a way to speed up `zpool scrub` under current. It needs ages for scrubbing... It looks like: (ws3)(root) # zpool iostat 1 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- r 39,5G 95,5G 21 5 1,49M 22,4K r 39,5G 95,5G 106 56 13,0M 173K r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 19 23 1,92M 113K r 39,5G 95,5G 479 0 30,8M 0 r 39,5G 95,5G 204 112 11,7M 841K r 39,5G 95,5G 252 0 15,1M 0 r 39,5G 95,5G 108 62 5,58M 181K r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 r 39,5G 95,5G 0 0 0 0 ... Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-fs@FreeBSD.ORG Wed Mar 11 01:11:39 2009 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 997B2106566C for ; Wed, 11 Mar 2009 01:11:39 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 36C3A8FC15 for ; Wed, 11 Mar 2009 01:11:38 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fxm2 with SMTP id 2so1694229fxm.43 for ; Tue, 10 Mar 2009 18:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.207 with SMTP id l15mr6031900fao.2.1236732633850; Tue, 10 Mar 2009 17:50:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2009 02:50:33 +0200 Message-ID: From: Vlad GALU To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Fwd: Can't create files on sshfs mount 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, 11 Mar 2009 01:11:39 -0000 Hi, I'm trying my luck with the below issue. Sorry for the noise. ---------- Forwarded message ---------- From: Vlad GALU Date: Wed, Mar 11, 2009 at 2:41 AM Subject: Can't create files on sshfs mount To: fuse4bsd-devel@creo.hu Hi. I've just installed the latest FUSE/sshfs ports on my RELENG_7, and I mounted a remote directory. Creating directories on the remote volume succeeds, but issuing an open() with O_CREAT yields EBADF (which shouldn't really happen). open()ing already existing files also succeeds. Any ideas? -- ~/.signature: no such file or directory From owner-freebsd-fs@FreeBSD.ORG Wed Mar 11 16:10:03 2009 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 ED1BA106564A for ; Wed, 11 Mar 2009 16:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DAEEC8FC0A for ; Wed, 11 Mar 2009 16:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2BGA3tS056748 for ; Wed, 11 Mar 2009 16:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2BGA3V5056747; Wed, 11 Mar 2009 16:10:03 GMT (envelope-from gnats) Date: Wed, 11 Mar 2009 16:10:03 GMT Message-Id: <200903111610.n2BGA3V5056747@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Peter Keel Cc: Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Keel List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:10:04 -0000 The following reply was made to PR kern/131360; it has been noted by GNATS. From: Peter Keel To: bug-followup@FreeBSD.org, martin@email.aon.at Cc: Subject: kern/131360: [nfs] poor scaling behavior of the NFS server under load Date: Wed, 11 Mar 2009 17:03:36 +0100 Addendum: - Changing the scheduler yielded nothing, as you expected. - This was over TCP, we never used UDP. We mounted the systems with these options: rw,nfsv3,tcp,intr,nolockd,bg - The ethernet-device drivers are "em" on all machines. em0: Regards Peter -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier From owner-freebsd-fs@FreeBSD.ORG Wed Mar 11 22:15:27 2009 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 6DDCB10656C3 for ; Wed, 11 Mar 2009 22:15:27 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 3531D8FC12 for ; Wed, 11 Mar 2009 22:15:26 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id A686142D821; Wed, 11 Mar 2009 22:55:18 +0100 (CET) Date: Wed, 11 Mar 2009 22:55:18 +0100 From: Guido van Rooij To: freebsd-fs@freebsd.org Message-ID: <20090311215518.GA25410@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RFC: geli+gmirror problem + solution 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, 11 Mar 2009 22:15:27 -0000 We have a setup where we have two disks in a gmirror with GELI on top of it. We boot from it (using a small unencrypted USB stick). We this have the G_ELI_FLAG_BOOT set. Anyway, when rebooting, geli does not detach and this the gmirror is never destroyed resulting in a rebuild each time. I just commited a fix for this (set the G_ELI_FLAG_WO_DETACH in g_eli_taste(). However, this seems to break zfs as zfs might actually close the geli device and later opening it (but it is then no longer there). We must therefor make this configurable. I thus propose to be able to set the G_ELI_FLAG_WO_DETACH in the geli- metadata, just like the G_ELI_FLAG_BOOT flag. This would mean an extra option to geli init, say the -d flag. Any objections? -Guido From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 06:22:49 2009 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 F3081106564A; Thu, 12 Mar 2009 06:22:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C90778FC16; Thu, 12 Mar 2009 06:22:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2C6MmFa070014; Thu, 12 Mar 2009 06:22:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2C6MmRE070010; Thu, 12 Mar 2009 06:22:48 GMT (envelope-from linimon) Date: Thu, 12 Mar 2009 06:22:48 GMT Message-Id: <200903120622.n2C6MmRE070010@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/132551: [zfs] ZFS locks up on extattr_list_link syscall 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, 12 Mar 2009 06:22:49 -0000 Old Synopsis: ZFS locks up on extattr_list_link syscall New Synopsis: [zfs] ZFS locks up on extattr_list_link syscall Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 12 06:22:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132551 From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 13:58:39 2009 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 601761065676 for ; Thu, 12 Mar 2009 13:58:39 +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 2E9B58FC18 for ; Thu, 12 Mar 2009 13:58:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9F18B46B03; Thu, 12 Mar 2009 09:58:38 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2CDwVOF046493; Thu, 12 Mar 2009 09:58:32 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-fs@freebsd.org Date: Thu, 12 Mar 2009 08:37:07 -0400 User-Agent: KMail/1.9.7 References: <200902192210.n1JMAddn009074@svn.freebsd.org> <20090309151400.GA807@a91-153-125-115.elisa-laajakaista.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903120837.08170.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 12 Mar 2009 09:58:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9100/Thu Mar 12 05:07:56 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: [patch] invalidate NFS attribute cache if setattr fails with ESTALE 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, 12 Mar 2009 13:58:39 -0000 On Monday 09 March 2009 12:34:33 pm Rick Macklem wrote: > > On Mon, 9 Mar 2009, Jaakko Heinonen wrote: > > > > > Hi, > > > > Here is a patch which changes nfs_setattrrpc() to invalidate the NFS > > attribute cache in case the RPC failed with ESTALE. > > > > The issue was originally reported by Timo Sirainen in PR kern/123755: > > > >> NFS client: open() a file > >> NFS server: unlink() the file > >> NFS client: fchown() the file -> ESTALE (as expected) > >> NFS client: fstat() the file -> success (not expected) > > > > %%% > > Index: sys/nfsclient/nfs_vnops.c > > =================================================================== > > --- sys/nfsclient/nfs_vnops.c (revision 188842) > > +++ sys/nfsclient/nfs_vnops.c (working copy) > > @@ -838,6 +838,10 @@ nfs_setattrrpc(struct vnode *vp, struct > > nfsm_loadattr(vp, NULL); > > m_freem(mrep); > > nfsmout: > > + /* Invalidate the attribute cache if the NFS file handle is stale. */ > > + if (error == ESTALE) > > + np->n_attrstamp = 0; > > + > > return (error); > > } > > > > %%% > > > > Could someone take a look if this could be committed? > > > I'm not a committer, but I think that it might be appropriate to > invalidate the attribute cache for any ESTALE reply from a server. > (Since ESTALE implies that the file no linger exists on the server, > I can't think why the attribute cache should remain valid for anything.) > > There is already code in nfs_request() that purges the name cache for > ESTALE and I think that invalidating the cache there too, might make > sense? I think we should purge the access cache too? I just put this in my p4 branch yesterday (it also has a merge of your changes to expand the per-node access cache, so the access cache clearing is a bit larger than it would be otherwise): --- //depot/projects/smpng/sys/nfs4client/nfs4_socket.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfs4client/nfs4_socket.c 2009/03/11 22:15:03 @@ -259,7 +259,7 @@ ** lookup cache, just in case. **/ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); return (error); } --- //depot/projects/smpng/sys/nfsclient/nfs.h 2008/11/18 23:25:45 +++ //depot/user/jhb/lock/nfsclient/nfs.h 2009/03/11 22:15:03 @@ -319,6 +322,7 @@ #endif /* ! NFS4_USE_RPCCLNT */ #endif +void nfs_purgecache(struct vnode *); int nfs_vinvalbuf(struct vnode *, int, struct thread *, int); int nfs_readrpc(struct vnode *, struct uio *, struct ucred *); int nfs_writerpc(struct vnode *, struct uio *, struct ucred *, int *, --- //depot/projects/smpng/sys/nfsclient/nfs_krpc.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_krpc.c 2009/03/11 22:15:03 @@ -521,7 +521,7 @@ * cache, just in case. */ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); /* * Skip wcc data on NFS errors for now. NetApp filers * return corrupt postop attrs in the wcc data for NFS --- //depot/projects/smpng/sys/nfsclient/nfs_socket.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_socket.c 2009/03/11 22:15:03 @@ -1364,7 +1364,7 @@ * lookup cache, just in case. */ if (error == ESTALE) - cache_purge(vp); + nfs_purgecache(vp); /* * Skip wcc data on NFS errors for now. NetApp filers return corrupt * postop attrs in the wcc data for NFS err EROFS. Not sure if they --- //depot/projects/smpng/sys/nfsclient/nfs_subs.c 2008/11/03 21:11:59 +++ //depot/user/jhb/lock/nfsclient/nfs_subs.c 2009/03/11 22:15:03 @@ -826,6 +826,27 @@ return (0); } +/* + * Purge all cached information about an NFS vnode including name + * cache entries, the attribute cache, and the access cache. This is + * called when an NFS request for a node fails with a stale + * filehandle. + */ +void +nfs_purgecache(struct vnode *vp) +{ + struct nfsnode *np; + int i; + + np = VTONFS(vp); + cache_purge(vp); + mtx_lock(&np->n_mtx); + np->n_attrstamp = 0; + for (i = 0; i < NFS_ACCESSCACHESIZE; i++) + np->n_accesscache[i].stamp = 0; + mtx_unlock(&np->n_mtx); +} + static nfsuint64 nfs_nullcookie = { { 0, 0 } }; /* * This function finds the directory cookie that corresponds to the -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 19:58:38 2009 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 9BD3010656BF for ; Thu, 12 Mar 2009 19:58:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id C45988FC29 for ; Thu, 12 Mar 2009 19:58:37 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0C57145685; Thu, 12 Mar 2009 20:58:35 +0100 (CET) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 71B1745684; Thu, 12 Mar 2009 20:58:29 +0100 (CET) Date: Thu, 12 Mar 2009 20:59:05 +0100 From: Pawel Jakub Dawidek To: Guido van Rooij Message-ID: <20090312195904.GA1786@garage.freebsd.pl> References: <20090311215518.GA25410@gvr.gvr.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20090311215518.GA25410@gvr.gvr.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: RFC: geli+gmirror problem + solution 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, 12 Mar 2009 19:58:39 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 11, 2009 at 10:55:18PM +0100, Guido van Rooij wrote: > We have a setup where we have two disks in a gmirror with GELI on top > of it. We boot from it (using a small unencrypted USB stick). > We this have the G_ELI_FLAG_BOOT set. >=20 > Anyway, when rebooting, geli does not detach and this the gmirror is > never destroyed resulting in a rebuild each time. >=20 > I just commited a fix for this (set the G_ELI_FLAG_WO_DETACH in g_eli_tas= te(). > However, this seems to break zfs as zfs might actually close the geli dev= ice > and later opening it (but it is then no longer there). >=20 > We must therefor make this configurable. >=20 > I thus propose to be able to set the G_ELI_FLAG_WO_DETACH in the geli- > metadata, just like the G_ELI_FLAG_BOOT flag. This would mean an > extra option to geli init, say the -d flag. >=20 > Any objections? I'd suggest not to do it. Maybe you could implement detaching on reboot for geli providers? You can find example of how to do this in three last functions in sys/geom/mirror/g_mirror.c. Could you send me patches to review before committing? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJuWmIForvXbEpPzQRAt1hAJ9UW8NOv7XmqOYkEq+MSUxKE1npaQCfTvzA DpmexskXV1aX4s6W2EG5IDI= =HFd3 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 23:19:28 2009 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 560DF106566C for ; Thu, 12 Mar 2009 23:19:28 +0000 (UTC) (envelope-from ssrbarry@comcast.net) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9EA8FC1C for ; Thu, 12 Mar 2009 23:19:28 +0000 (UTC) (envelope-from ssrbarry@comcast.net) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id SHMX1b00R17UAYkAEP6KAP; Thu, 12 Mar 2009 23:06:19 +0000 Received: from sbputer2 ([75.72.75.15]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id SP6J1b00N0KnvYT8ZP6KmE; Thu, 12 Mar 2009 23:06:19 +0000 From: "Sean Barry" To: Date: Thu, 12 Mar 2009 18:06:24 -0500 Message-ID: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmjZynR0GIO5QDHRTiRCTX++V3Ecw== Content-Language: en-us Subject: UFS Configuration Question 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, 12 Mar 2009 23:19:28 -0000 Hello, Is it possible to configure the file system driver to Not record the time and date stamp metadata? I will be starting a personal project of setting up a NAS server using FreeNas. This will be a file storage and I do not have a need for extra metadata information. Thank you, Sean Barry From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 23:47:22 2009 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 CE0E8106566B for ; Thu, 12 Mar 2009 23:47:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5982A8FC12 for ; Thu, 12 Mar 2009 23:47:21 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n2CNlFxf011149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Mar 2009 00:47:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n2CNlBwR021236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 00:47:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n2CNlBnf072532; Fri, 13 Mar 2009 00:47:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n2CNlBLb072531; Fri, 13 Mar 2009 00:47:11 +0100 (CET) (envelope-from ticso) Date: Fri, 13 Mar 2009 00:47:11 +0100 From: Bernd Walter To: Sean Barry Message-ID: <20090312234710.GZ63112@cicely7.cicely.de> References: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ba01c9a367$2aa0a5a0$7fe1f0e0$@net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.134, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-fs@freebsd.org Subject: Re: UFS Configuration Question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 23:47:23 -0000 On Thu, Mar 12, 2009 at 06:06:24PM -0500, Sean Barry wrote: > Hello, > Is it possible to configure the file system driver to Not record the time > and date stamp metadata? > > I will be starting a personal project of setting up a NAS server using > FreeNas. This will be a file storage and I do not have a need for extra > metadata information. This is part of the inode, where file size and such is also noted. You don't win anything by not saveing modtime. However, you can mount using -noatime, so the the inode won't get updated on read access. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 18:09:38 2009 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 0395B106566B for ; Fri, 13 Mar 2009 18:09:38 +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 3EF368FC28 for ; Fri, 13 Mar 2009 18:09:36 +0000 (UTC) (envelope-from avg@freebsd.org) 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 TAA15114; Fri, 13 Mar 2009 19:57:40 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <49BA9E93.4060609@freebsd.org> Date: Fri, 13 Mar 2009 19:57:39 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org References: <4911C3E9.405@icyb.net.ua> <49198A1A.3080600@icyb.net.ua> <49227875.6090902@icyb.net.ua> <93FC5F5D-91CD-450B-B08D-5C5EC5A1C880@mac.com> <4922FB81.50608@icyb.net.ua> In-Reply-To: <4922FB81.50608@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? 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, 13 Mar 2009 18:09:38 -0000 Very belated but somebody reading archives might find this useful. Only today I discovered zdb command and its -C option: $ zdb -C tank version=6 name='tank' state=0 txg=1997530 pool_guid=15723282379537418671 hostid=714261228 hostname='' vdev_tree type='root' id=0 guid=15723282379537418671 children[0] type='disk' id=0 guid=1732303387090405178 path='/dev/ad6s2d' devid='ad:GEA534RF0TK35A' whole_disk=0 metaslab_array=14 metaslab_shift=32 ashift=9 asize=493659881472 DTL=182 on 18/11/2008 19:29 Andriy Gapon said the following: > I just remembered that I saved old zpool.cache file before "migrating" > the pool. > I looked at the diff of hexdumps and there are a number of differences, > it's hard to understand them because the file is binary (actually it > seems to contain serialized name-value pairs), but one difference is > prominent: > ... > 00000260 64 65 76 69 64 00 00 00 00 00 00 09 00 00 00 01 > |devid...........| > ... > -00000270 00 00 00 15 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > -00000280 54 4b 33 35 41 73 31 73 33 00 00 00 00 00 00 28 > |TK35As1s3......(| > ... > +00000270 00 00 00 11 61 64 3a 47 45 41 35 33 34 52 46 30 > |....ad:GEA534RF0| > +00000280 54 4b 33 35 41 00 00 00 00 00 00 28 00 00 00 28 > |TK35A......(...(| > ... > > It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new one > is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is ad6s2d. > > The new value is what is reported by diskinfo: > $ diskinfo -v ad6 > ad6 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2 > ad6s2 > ... > ad:GEA534RF0TK35A # Disk ident. > > $ diskinfo -v ad6s2d > ad6s2d > ... > ad:GEA534RF0TK35A # Disk ident. > > Hmm, "indent" is reported to be the same for all three entities. > > I don't remember what diskinfo reported with pre-gpart kernel, but I > suspect that it was something different. > Could anybody please check this? (on 7.X machine without GEOM_PART). > > I quickly glimpsed through sources and it seems that this comes from > DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that > geom_slice.c code has some special handling for that. > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 20:05:50 2009 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 D5883106564A; Fri, 13 Mar 2009 20:05:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9FB18FC16; Fri, 13 Mar 2009 20:05:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2DK5oUM043748; Fri, 13 Mar 2009 20:05:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2DK5oVn043744; Fri, 13 Mar 2009 20:05:50 GMT (envelope-from linimon) Date: Fri, 13 Mar 2009 20:05:50 GMT Message-Id: <200903132005.n2DK5oVn043744@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR 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, 13 Mar 2009 20:05:51 -0000 Old Synopsis: tmpfs-related panic while interrupting a port build on tmpfs WRKDIR New Synopsis: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 13 20:05:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132597 From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 21:30:13 2009 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 58BE7106566B for ; Fri, 13 Mar 2009 21:30:13 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-9.dsl.austtx.swbell.net [70.243.84.9]) by mx1.freebsd.org (Postfix) with ESMTP id 139F38FC08 for ; Fri, 13 Mar 2009 21:30:13 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n2DLTxld006975 for ; Fri, 13 Mar 2009 16:29:59 -0500 (CDT) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:content-type:content-transfer-encoding; b=p7IuEfNk7ZAW2YKchWDeC7+HbThn5gJIXLsSfT3zkt520yHMEsvVCut6q6/0n09Hv giqxDAKaHvg7N8uvq+V1t80WwZBZXLoRSOXf8nSrxijRYqo6LQtBv8+mZIcG4ExfTyq O0tjX5XcMmGoN3+1DgGFeGnkHT4FVe+Sdqrq1r8= Message-ID: <49BAD057.6060602@jrv.org> Date: Fri, 13 Mar 2009 16:29:59 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ZFS recv doesn't properly skip existing snapshots 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, 13 Mar 2009 21:30:13 -0000 /home/james# uname -a FreeBSD bigtex.housenet.jrv 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r189099: Fri Feb 27 07:09:47 CST 2009 james@bigtex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 "zfs recv" doesn't properly skip existing snapshots in a replication stream. I'm working on a way to keep a remote pool in sync with a local pool using zfs send/recv. It appears that "zfs recv" may not be atomic across the input stream but only within each individual filesystem. This means that the pool replication script must be prepared to handle the situation where a parent filesystem may have received a snapshot that a child did not. It appears "zfs recv" is supposed to simply skip any snapshot it already has, making me think that it should pick up at the next snapshot record in the input stream. But instead "zfs recv" appears to never get in sync with the input stream again and simple exits. Comments embedded with hashed below. /home/james# zfs create bigtex/foo /home/james# zfs create bigtex/foo/bar /home/james# zfs snapshot -r bigtex/foo@a /home/james# zfs snapshot -r bigtex/foo@b /home/james# zfs snapshot -r bigtex/foo@c /home/james# zfs snapshot -r bigtex/foo@d /home/james# zfs list -t snapshot ... bigtex/foo@a 0 - 18K - bigtex/foo@b 0 - 18K - bigtex/foo@c 0 - 18K - bigtex/foo@d 0 - 18K - bigtex/foo/bar@a 0 - 18K - bigtex/foo/bar@b 0 - 18K - bigtex/foo/bar@c 0 - 18K - bigtex/foo/bar@d 0 - 18K - # send initial data. Works as expected. /home/james# /root/zfs send -v -R bigtex/foo@b | /root/zfs recv -dv bigtmptex sending from @ to bigtex/foo@a receiving full stream of bigtex/foo@a into bigtmptex/foo@a sending from @a to bigtex/foo@b sending from @ to bigtex/foo/bar@a sending from @a to bigtex/foo/bar@b received 13.6KB stream in 1 seconds (13.6KB/sec) receiving incremental stream of bigtex/foo@b into bigtmptex/foo@b received 312B stream in 1 seconds (312B/sec) receiving full stream of bigtex/foo/bar@a into bigtmptex/foo/bar@a received 13.6KB stream in 1 seconds (13.6KB/sec) receiving incremental stream of bigtex/foo/bar@b into bigtmptex/foo/bar@b received 312B stream in 1 seconds (312B/sec) # send incremental update. Works as expected. /home/james# /root/zfs send -RvI @b bigtex/foo@d | /root/zfs recv -dvF bigtmptex sending from @b to bigtex/foo@c sending from @c to bigtex/foo@d sending from @b to bigtex/foo/bar@c sending from @c to bigtex/foo/bar@d receiving incremental stream of bigtex/foo@c into bigtmptex/foo@c received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo@d into bigtmptex/foo@d received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo/bar@c into bigtmptex/foo/bar@c received 312B stream in 1 seconds (312B/sec) receiving incremental stream of bigtex/foo/bar@d into bigtmptex/foo/bar@d received 312B stream in 1 seconds (312B/sec) # The results are correct. /home/james# zfs list -t snapshot ... bigtex/foo@a 0 - 18K - bigtex/foo@b 0 - 18K - bigtex/foo@c 0 - 18K - bigtex/foo@d 0 - 18K - bigtex/foo/bar@a 0 - 18K - bigtex/foo/bar@b 0 - 18K - bigtex/foo/bar@c 0 - 18K - bigtex/foo/bar@d 0 - 18K - bigtmptex/foo@a 0 - 18K - bigtmptex/foo@b 0 - 18K - bigtmptex/foo@c 0 - 18K - bigtmptex/foo@d 0 - 18K - bigtmptex/foo/bar@a 0 - 18K - bigtmptex/foo/bar@b 0 - 18K - bigtmptex/foo/bar@c 0 - 18K - bigtmptex/foo/bar@d 0 - 18K - # pretend that the incremental send/recv above was interrupted after bigtex/foo@d was received but before bigtex/foo/bar@d /home/james# zfs destroy bigtmptex/foo/bar@d # a clever script might realize that we need to start at @c because @d has not been received by some child filesystems. But zfs recv doesn't work right. /home/james# /root/zfs send -RvI @c bigtex/foo@d | /root/zfs recv -dvF bigtmptex sending from @c to bigtex/foo@d receiving incremental stream of bigtex/foo@d into bigtmptex/foo@d snap bigtmptex/foo@d already exists; ignoring sending from @c to bigtex/foo/bar@d warning: cannot send 'bigtex/foo/bar@d': Broken pipe /home/james# zfs list -t snapshot ... bigtmptex/foo@a 0 - 18K - bigtmptex/foo@b 0 - 18K - bigtmptex/foo@c 0 - 18K - bigtmptex/foo@d 0 - 18K - bigtmptex/foo/bar@a 0 - 18K - bigtmptex/foo/bar@b 0 - 18K - bigtmptex/foo/bar@c 0 - 18K - From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 04:50:04 2009 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 19594106564A for ; Sat, 14 Mar 2009 04:50: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 E16948FC13 for ; Sat, 14 Mar 2009 04:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2E4o3lT011997 for ; Sat, 14 Mar 2009 04:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2E4o3to011990; Sat, 14 Mar 2009 04:50:03 GMT (envelope-from gnats) Date: Sat, 14 Mar 2009 04:50:03 GMT Message-Id: <200903140450.n2E4o3to011990@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Yoshihiro Ota Cc: Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yoshihiro Ota List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 04:50:04 -0000 The following reply was made to PR kern/132597; it has been noted by GNATS. From: Yoshihiro Ota To: bug-followup@FreeBSD.org Cc: bf2006a@yahoo.com Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Date: Sat, 14 Mar 2009 00:42:58 -0400 Which ports were you compiling when panic happened? Hiro From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 10:48:20 2009 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 61A931065672 for ; Sat, 14 Mar 2009 10:48:20 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id F35B08FC0A for ; Sat, 14 Mar 2009 10:48:19 +0000 (UTC) (envelope-from pho@holm.cc) Received: (qmail 51926 invoked from network); 14 Mar 2009 10:21:37 -0000 Received: from 87.58.145.190 (HELO x2.osted.lan) (87.58.145.190) by relay02.pair.com with SMTP; 14 Mar 2009 10:21:37 -0000 X-pair-Authenticated: 87.58.145.190 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n2EALagr093674; Sat, 14 Mar 2009 11:21:36 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n2EALZFd093673; Sat, 14 Mar 2009 11:21:35 +0100 (CET) (envelope-from pho) Date: Sat, 14 Mar 2009 11:21:35 +0100 From: Peter Holm To: Yoshihiro Ota Message-ID: <20090314102135.GA93077@x2.osted.lan> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903140450.n2E4o3to011990@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, Attilio Rao Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR 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, 14 Mar 2009 10:48:20 -0000 On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > The following reply was made to PR kern/132597; it has been noted by GNATS. > > From: Yoshihiro Ota > To: bug-followup@FreeBSD.org > Cc: bf2006a@yahoo.com > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > interrupting a port build on tmpfs WRKDIR > Date: Sat, 14 Mar 2009 00:42:58 -0400 > > Which ports were you compiling when panic happened? > > Hiro The panic in this PR looks a lot like the one I reported to attilio@ http://people.freebsd.org/~pho/stress/log/attilio022.txt It was just regular FS load that provoked it. -- Peter From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 17:40:02 2009 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 9EB041065675 for ; Sat, 14 Mar 2009 17:40:02 +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 8BE988FC1C for ; Sat, 14 Mar 2009 17:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2EHe2oV049923 for ; Sat, 14 Mar 2009 17:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2EHe2GE049922; Sat, 14 Mar 2009 17:40:02 GMT (envelope-from gnats) Date: Sat, 14 Mar 2009 17:40:02 GMT Message-Id: <200903141740.n2EHe2GE049922@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: bf Cc: Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 17:40:02 -0000 The following reply was made to PR kern/132597; it has been noted by GNATS. From: bf To: Yoshihiro Ota Cc: bug-followup@FreeBSD.org Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR Date: Sat, 14 Mar 2009 10:31:07 -0700 (PDT) --- On Sat, 3/14/09, Yoshihiro Ota wrote: > From: Yoshihiro Ota > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR > To: bug-followup@FreeBSD.org > Cc: bf2006a@yahoo.com > Date: Saturday, March 14, 2009, 12:42 AM > Which ports were you compiling when panic happened? > > Hiro I see now that I confused your response with my other related PR, which I had just filed before I received your message. I had been building a number of ports, so I do not now recall which one it was, sorry. I will say that a panic of this kind, despite the other recent serious problems with tmpfs, is rare: I have only seen one such panic in about a year of heavy use of a tmpfs /tmp for building ports. That is why I didn't use a higher priority when filing the PR. Regards, b. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 20:32:23 2009 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 6DA9D1065670; Sat, 14 Mar 2009 20:32:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 0A5C98FC15; Sat, 14 Mar 2009 20:32:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LiaWp-0009xQ-K7; Sat, 14 Mar 2009 22:32:19 +0200 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 n2EKWFVd032537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2009 22:32:16 +0200 (EET) (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.3/8.14.3) with ESMTP id n2EKWF8R002381; Sat, 14 Mar 2009 22:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n2EKWFF2002380; Sat, 14 Mar 2009 22:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Mar 2009 22:32:15 +0200 From: Kostik Belousov To: Peter Holm Message-ID: <20090314203215.GA41617@deviant.kiev.zoral.com.ua> References: <200903140450.n2E4o3to011990@freefall.freebsd.org> <20090314102135.GA93077@x2.osted.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SBADSSFwlTeCdIwN" Content-Disposition: inline In-Reply-To: <20090314102135.GA93077@x2.osted.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LiaWp-0009xQ-K7 a5c5a32ba898bcf58347364e15fb6190 X-Terabit: YES Cc: Yoshihiro Ota , freebsd-fs@freebsd.org, Attilio Rao Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while interrupting a port build on tmpfs WRKDIR 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, 14 Mar 2009 20:32:23 -0000 --SBADSSFwlTeCdIwN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 14, 2009 at 11:21:35AM +0100, Peter Holm wrote: > On Sat, Mar 14, 2009 at 04:50:03AM +0000, Yoshihiro Ota wrote: > > The following reply was made to PR kern/132597; it has been noted by GN= ATS. > >=20 > > From: Yoshihiro Ota > > To: bug-followup@FreeBSD.org > > Cc: bf2006a@yahoo.com > > Subject: Re: kern/132597: [tmpfs] [panic] tmpfs-related panic while > > interrupting a port build on tmpfs WRKDIR > > Date: Sat, 14 Mar 2009 00:42:58 -0400 > >=20 > > Which ports were you compiling when panic happened? > > =20 > > Hiro >=20 > The panic in this PR looks a lot like the one I reported to attilio@ >=20 > http://people.freebsd.org/~pho/stress/log/attilio022.txt >=20 > It was just regular FS load that provoked it. It seems to be quite clean what is going on there. In fact, there are two issues: First is the usual problem of DOTDOT lookup that shall be fixed in style of vn_vget_ino() by busying mp before unlocking dvp. Second one is the reason for the panic. The tmpfs vnode is unlocked, and then corresponding tmpfs _node_ is passed to the tmpfs_alloc_vp(). Since the vnode may be reclaimed after the unlock, passed node might become freed. Then, the tmpfs_alloc_vp() would operate on the freed memory. --SBADSSFwlTeCdIwN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkm8FE4ACgkQC3+MBN1Mb4ibWgCfSRjRwMyPFQOYko+oOO/1Z5C0 N80AoNyatttOuDKTJJ4lkd2zqh+QdH5z =caAy -----END PGP SIGNATURE----- --SBADSSFwlTeCdIwN--