From owner-freebsd-questions@FreeBSD.ORG Tue Jun 21 23:05:13 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CC091065705 for ; Tue, 21 Jun 2011 23:05:13 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id E8F8F8FC15 for ; Tue, 21 Jun 2011 23:05:12 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id p5LN56M9051629 for freebsd-questions@freebsd.org; Tue, 21 Jun 2011 18:05:06 -0500 (CDT) Date: Tue, 21 Jun 2011 18:05:06 -0500 (CDT) From: Robert Bonomi Message-Id: <201106212305.p5LN56M9051629@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: <4E00DD44.1070706@gmx.de> Subject: Re: (no subject) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 23:05:14 -0000 "Those who think they know it all are really annoying to those of us who do." > Date: Tue, 21 Jun 2011 20:04:52 +0200 > From: Lokadamus > > Your folder tmp is an own partition with just 1GB size. FALSE TO FACT. You can run df(1), giving it _any_ fileneme -- whether OR NOT it is a directory -- and it will report the statistics for the underlying filesystem. Proof: %df -H /COPYRIGHT Filesystem Size Used Avail Capacity Mounted on /dev/idad0s1a 65M 35M 24M 59% / %ls -l /COPYRIGHT -r--r--r-- 1 root wheel 6197 May 1 2009 COPYRIGHT For this user, /tmp is part of the / filesystem, as is CLEARLY shown by the 'Mounted on' field in the df output, below. The filesystem on 'ard0s1a', =mounted=as='/'=, _is_ roughly 1 gig in size. The filesystem "overhead" -- primarily the space reserved for (assuming a UFS filesystem) the FIXED SIZE (and pre-allocated) 'inode table', the 'backup superblocks', and the cylinder-group metadata -- accounts for the filesysem 'size' of 989M. Of that 989M, 8% has been set 'reserved' for superuser-only use. Programs running, with the EUID of 0 (the superuser), were creating the problematic /tmp files, thus the negative 'Avail' number, and the 'used' space being shown as over 100% in the 'Capacity' column. > Mon Jun 20 11:41:58 2011 849M /tmp > Mon Jun 20 11:42:01 2011 > Filesystem Size Used Avail Capacity Mounted on >/dev/amrd0s1a 989M 987M -76M 108% / > > When a partition is over 100% its use backup place for defect sektors. A > partition is/was created with 110% and 10% are for defect sectors. FALSE TO FACT. When 'spare' sectors are allocated for potential defective sector substitution, they are _not_ included in the available space/capacity of a filesystem. With most _modern_ disks, bad-sector substitution is handled by the _disk_hardware_itself_, *invisibly* to the host computer hardware, *or* operating system. *IF* spare sectors are allocated the O/S for bad-sector management, this is done by the 'low level format' utiltity, before any sort of filesystem, _if_any_, is created. i.e. there =will= be spares, for bad-sector substitution, even on the portion of a disk used as a 'swap' partition, despite there being no filesystem there. The 'reserved' space, "traditionally" the last 10% -- although in this case of the OP's drive it was _8%_ -- of the filesystem capacity, is set for the _exclusive use_ of the superuser, for regular filesystem activity (to wit, writing files to it). The reasn for this 'reserved space' is so that a 'regular user' with runaway disk usage, will _not_ be able to cause _system_ processes to fail for lack of disk space. In the OP's case, it _was_ a' superuser process' that was writeing to /tmp, so that process failed _only_ when the space on the filesystem was _TOTALLY_ exhausted, instead of when usage reached '100%' of the file system space available to 'regular users'.