Date: Sun, 2 Jan 2011 15:50:18 +0000 From: miyamoto moesasji <miyamoto.31b@gmail.com> To: Ronald Klop <ronald-freebsd8@klop.yi.org> Cc: freebsd-stable@freebsd.org Subject: Re: tmpfs runs out of space on 8.2pre-release, zfs related? Message-ID: <AANLkTi=ff-eEwAtjODaiv1KCYdZa-gVX=g%2BO9-AnXzyt@mail.gmail.com> In-Reply-To: <op.voos6qwa8527sy@pinky> References: <AANLkTikeN1BqoYwtvSzUaXek5F8VMU9X=BssOLkFFMkx@mail.gmail.com> <op.voos6qwa8527sy@pinky>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 2, 2011 at 3:26 PM, Ronald Klop <ronald-freebsd8@klop.yi.org> w= rote: > On Sun, 02 Jan 2011 09:41:04 +0100, miyamoto moesasji > <miyamoto.31b@gmail.com> wrote: > >> miyamoto moesasji <miyamoto.31b <at> gmail.com> writes: >> >>> >>> In setting up tmpfs (so not tmpmfs) on a machine that is using >>> zfs(v15, zfs v4) on 8.2prerelease I run out of space on the tmpfs when >>> copying a file of ~4.6 GB file from the zfs-filesystem to the memory >>> disk. This machine has 8GB of memory backed by swap on the harddisk, >>> so I expected the file to copy to memory without problems. >>> >> >> ....this is in fact worse than I first thought. After leaving the >> machine running overnight the tmpfs is reduced to a size of 4K, which >> shows that tmpfs is in fact >> completely unusable for me. See the output of df: >> --- >> hge@PulsarX4:~/ > df -hi /tmp >> Filesystem =A0 =A0Size =A0 =A0Used =A0 Avail Capacity iused ifree %iused= =A0Mounted on >> tmpfs =A0 =A0 =A0 =A0 4.0K =A0 =A04.0K =A0 =A0 =A00B =A0 100% =A0 =A0 = =A018 =A0 =A0 0 =A0100% =A0 /tmp >> --- >> >> Relevant zfs-stats info: >> --- >> System Memory Statistics: >> =A0 =A0 =A0 =A0Physical Memory: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A08161.74M >> =A0 =A0 =A0 =A0Kernel Memory: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A04117.40M >> =A0 =A0 =A0 =A0DATA: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 99.29% =A04088.07M >> =A0 =A0 =A0 =A0TEXT: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 0.71% =A0 29.33M >> >> ARC Size: >> =A0 =A0 =A0 =A0Current Size (arcsize): =A0 =A0 =A0 =A0 63.58% =A04370.60= M >> =A0 =A0 =A0 =A0Target Size (Adaptive, c): =A0 =A0 =A0100.00% 6874.44M >> =A0 =A0 =A0 =A0Min Size (Hard Limit, c_min): =A0 12.50% =A0859.31M >> =A0 =A0 =A0 =A0Max Size (High Water, c_max): =A0 ~8:1 =A0 =A06874.44M >> --- >> >> I'm not sure what triggered this further reduction in size; but the >> above 4K size is probably important to show how dramatic this goes >> wrong. > > Is it possible that some program is filling a file (on your tmpfs) which = is > deleted? > You will not see it with df or ls, but it still takes space on the fs, un= til > the application closes the file. > > Ronald. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I'm pretty sure that this is not the case as the problem shows up immediately upon a clean reboot (and /tmp is normally pretty empty with just 22k in use at the moment with the older tmpmfs (determined with du -xh /tmp as root) ) Note that the key problem was given in the first post. There I posted that the tmpfs has 8.2GB available immediately after a reboot, yet it is impossible to copy a 4.6GB file to tmpfs from a zfs-drive even though the machine has 8GB of memory backed with swap. My feeling is that somehow the zfs file cache, which is also in memory is causing this, which is consistent with the solaris bugreport I linked to, see: http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=3De4ae9c3298= 3000ef651e38edbba1?bug_id=3D6804661
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=ff-eEwAtjODaiv1KCYdZa-gVX=g%2BO9-AnXzyt>