From owner-freebsd-fs@FreeBSD.ORG Wed Jan 25 11:44:05 2012 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 456F91065672 for ; Wed, 25 Jan 2012 11:44:05 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id E11BD8FC08 for ; Wed, 25 Jan 2012 11:44:04 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MHrNV-1RmRIs17Wv-003eHr; Wed, 25 Jan 2012 12:44:03 +0100 Message-ID: <4F1FEB02.2080202@brockmann-consult.de> Date: Wed, 25 Jan 2012 12:44:02 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <201110091940.p99JeJIc095036@freefall.freebsd.org> <20120125084040.GA2831@e4310> <4F1FD252.4090403@brockmann-consult.de> <4F1FDDF8.6020300@my.gd> In-Reply-To: <4F1FDDF8.6020300@my.gd> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:/MYWRueUK41lDlmFlIfQMWmns2oedtYgb1adplQprjb mrsGXZKHDkQVkYgc6p6CevK8a31pApTDktc1ADIy4Lf//iv14b 82raD1Ggdk+qX/5zM4dy+9rWpC72/ds/lGvnlAI1q72zZ+d3/H Rp7ZiocfQUsIBz+Ptvx+xuG2AxzO4iQ6YHJlHN1VpG1lPE6/Qw 2/stspSijbcgPK9DPuWHpUHAMyTB9tG/hmHuF1HIuVuDNPde1J OoVMM/RkuvNFEhjOTJbotfEwXjSEOqgvLpMM+ZQIGk9hm7yM67 2hx4Fx//qQOaV6fOIL5s6Nian5hm8/t8TjTUike0DwHjnHiRK2 AR2z3pD7vrQmj+64OTwgaFvTZH4sTCXjaOER+YBGg Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 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, 25 Jan 2012 11:44:05 -0000 When I built mine, my goal was to be able to rebuild the same thing I tested later on a different machine, so I used a specific date in my supfile: *default date=2011.09.27.00.00.00 But you can also do: # uname -a FreeBSD bcnas1.bc.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Sep 29 15:06:03 CEST 2011 root@bcnas1.bc.local:/usr/obj/usr/src/sys/GENERIC amd64 Which as you can see, tells you a time somewhere around the csup'd version (Sept 27), but it is actually the build time (probably 'make buildkernel'). I am not sure what it would say for something you get from an iso (would it be a week after the release tag the day it was built, or the tag date, etc.). But if you install a snapshot, such as the 8.2-STABLE-201105 iso you can find on ftp, it says 8.2-STABLE-201105 instead of 8.2-STABLE. Peter On 01/25/2012 11:48 AM, Damien Fleuriot wrote: > Hijacking thread quickly. > > How do you guys usually check your build/csup date on -stable and such ? > > I guess I'd go with the latest kernel build date, but there may be > better ways. > > > On 1/25/12 10:58 AM, Peter Maloney wrote: >> When was your 8.2-STABLE built / csup'd? >> >> Peter >> >> >> On 01/25/2012 09:40 AM, Michel Le Cocq wrote: >>> Hi every body, I upgrade my Freebsd 8.2-STABLE i386 to 9.0 i386. >>> Intel(R) Atom(TM) CPU D510 @ 1.66GHz >>> real memory = 4294967296 (4096 MB) >>> avail memory = 3127390208 (2982 MB) >>> >>> I'm on a ZFS Root file systeme on 2 USB drive and 6 sata drive for >>> data. >>> >>> # zpool list >>> NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT >>> data 931G 254G 677G 27% 1.00x ONLINE - >>> stock 74.5G 12.4G 62.1G 16% 1.00x ONLINE - >>> tank 696G 574G 122G 82% 1.00x ONLINE - >>> zroot 3.66G 2.49G 1.17G 67% 1.00x ONLINE - >>> >>> Before upgrade, I must use some mana things in my /boot/loader.conf >>> >>> vm.kmem_size="330M" >>> vm.kmem_size_max="330M" >>> vfs.zfs.arc_max="40M" >>> vfs.zfs.vdev.cache.size="5M" >>> >>> With this config my server was not so stable. >>> >>> Some days it work perfectly, some others it freeze with kmem_malloc >>> kmem_map too small. >>> Without this mana it freeze really often. >>> >>> The thing which make me upgrade is that after one of this crash after >>> reboot it won't mount my data pool which was at 99% of his CAP. The >>> only way I find to boot is to disconnect the pools drive and export >>> it. >>> >>> Now I'm on exactly the same host after upgrade to 9.0 and it seems to >>> work really really better (3 days up with out any trouble). >>> >>> -- >>> M >>> >>> Garrett Cooper a écrit: >>>> The following reply was made to PR kern/146528; it has been noted by GNATS. >>>> >>>> From: Garrett Cooper >>>> To: bug-followup@FreeBSD.org, EdwinGuy@GMail.com >>>> Cc: >>>> Subject: Re: kern/146528: [zfs] Severe memory leak in ZFS on i386 >>>> Date: Sun, 9 Oct 2011 12:34:00 -0700 >>>> >>>> Could you please try upgrading to 8.2-STABLE or 9.0 and see if the >>>> issue persists with ZFS v28? >>>> -Garrett >>>> _______________________________________________ >>>> freebsd-fs@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de --------------------------------------------