sudo mount /tmp mount: tmpfs : No space left on device $uname -a FreeBSD eris.apache.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0 r219046: Sat Feb 26 00:50:03 UTC 2011 root@loki.apache.org:/usr/obj/usr/src/sys/GENERIC amd64 from top: Mem: 592M Active, 1162M Inact, 21G Wired, 236M Cache, 2465M Buf, 758M Free Swap: 8317M Total, 59M Used, 8258M Free $cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw,noatime 1 1 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 tmpfs /tmp tmpfs rw 2 0 nfs:/usr/src /usr/src nfs ro,tcp,intr,rdirplus,soft,wsize=32768,rsize=32768,nolockd,noauto 0 0 nfs:/usr/obj /usr/obj nfs ro,tcp,intr,rdirplus,soft,wsize=32768,rsize=32768,nolockd,noauto 0 0 nfs:/usr/ports /usr/ports nfs ro,tcp,intr,rdirplus,soft,wsize=32768,rsize=32768,nolockd,noauto 0 0 $df -h Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0s1a 668G 299G 316G 49% / devfs 1.0K 1.0K 0B 100% /dev tank/x1 1.0T 681G 369G 65% /x1 $zpool status pool: tank state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 mfid2 ONLINE 0 0 0 mfid3 ONLINE 0 0 0 mfid4 ONLINE 0 0 0 mfid5 ONLINE 0 0 0 cache da1 ONLINE 0 0 0 da0 ONLINE 0 0 0 errors: No known data errors Fix: more info on request
On Wed, 9 Mar 2011 14:51:48 GMT "Philip M. Gollucci" <pgollucci@FreeBSD.org> wrote: > $zpool status > pool: tank > state: ONLINE ZFS and tmpfs don't work well together, because zfs takes all the memory and doesn't leave any for tmpfs. It's essentially the same problem, I think, as http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=e4ae9c32983000ef651e38edbba1?bug_id=6804661 . -- Bruce Cran
Maybe but its never once happened since zfs hit the tree in 7.0 through 8.1. I have litterally hundreds of boxes without this issue. and at least 2 8.2+ boxes that have it. Also it was just rebooted for the upgrade so 'possibly' had lots of free 'solaris' kernel memory free. On 03/09/11 15:43, Bruce Cran wrote: > On Wed, 9 Mar 2011 14:51:48 GMT > "Philip M. Gollucci" <pgollucci@FreeBSD.org> wrote: > >> $zpool status >> pool: tank >> state: ONLINE > > ZFS and tmpfs don't work well together, because zfs takes all the > memory and doesn't leave any for tmpfs. It's essentially the same > problem, I think, as > http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=e4ae9c32983000ef651e38edbba1?bug_id=6804661 . > -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
/boot/loader.conf ipmi_load="YES" kern.maxswzone=67108864 geom_mirror_load="YES" accf_http_load="YES" accf_data_load="YES" -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Could you test the patch. It changes the way tmpfs grows, sets filesystem default size to half of RAM by default. Tmpfs no longer depends on inactive/wired memory stats, but checks if swap is nearly full. I've added vfs.tmpfs.swap_reserved sysctl to limit tmpfs growth. Bottom line is, that you should specify meaningful filesystem size to prevent resource exhaustion. In my tests system didn't panic nor invoked OOM killer while consuming nearly all available ram and swap. Patch: http://marc.info/?l=freebsd-fs&m=129735686129438&w=2 It also handles test case described in OpenSolaris bug report for me: http://marc.info/?l=freebsd-fs&m=129747362722933&w=2 Thanks, Gleb.
I/we would be glad to test it; however, we'll have to schedule since the computers in question are both front facing ASF services. On 03/10/11 12:53, Gleb Kurtsou wrote: > Could you test the patch. It changes the way tmpfs grows, sets > filesystem default size to half of RAM by default. Tmpfs no longer > depends on inactive/wired memory stats, but checks if swap is nearly > full. I've added vfs.tmpfs.swap_reserved sysctl to limit tmpfs growth. > > Bottom line is, that you should specify meaningful filesystem size to > prevent resource exhaustion. > > In my tests system didn't panic nor invoked OOM killer while consuming > nearly all available ram and swap. > > Patch: > http://marc.info/?l=freebsd-fs&m=129735686129438&w=2 > > It also handles test case described in OpenSolaris bug report for me: > http://marc.info/?l=freebsd-fs&m=129747362722933&w=2 > > Thanks, > Gleb. > -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
State Changed From-To: open->feedback Do you still see the problem after r227802?
State Changed From-To: feedback->closed Feedback timeout. yes, we still see it. Its present on 9.0-RELEASE
State Changed From-To: closed->open re-open
It seems that r227802 hasn't been MFCd to stable/9. Can you test with the head version or apply r227802 to stable/9? -- Jaakko
On 04/01/12 00:37, Jaakko Heinonen wrote: > > It seems that r227802 hasn't been MFCd to stable/9. Can you test with > the head version or apply r227802 to stable/9? I've committed a MFC of r227802. This was rejected for stable/9 because it was too late for 9.0-RELEASE but I should have merged it right after 9.0-RELEASE (which I forgot). We have been using this change in production for quite a while now. Cheers, -- Xin LI <delphij@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die
Hi, A Debian GNU/kFreeBSD (9.0-RELEASE) user also experienced this issue, has tried the patch from with r227802, and believes it fixed the problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666747#59 The original FreeBSD PR claims the issue was found in 8-STABLE, since 8.2. Will this fix be committed to 8-STABLE sometime? Thanks, Regards, -- Steven Chamberlain steven@pyro.eu.org
State Changed From-To: open->patched Fixed in head (r227802) and stable/9 (r233769).
The revision was MFCed back to stable/8 in r234513 and is available in 8.4.0 . - http://svnweb.freebsd.org/base?view=revision&revision=234513 - http://svnweb.freebsd.org/base/release/8.4.0/sys/fs/tmpfs/tmpfs.h