From owner-freebsd-questions@FreeBSD.ORG Tue Oct 2 06:13:12 2007 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 7240A16A417 for ; Tue, 2 Oct 2007 06:13:12 +0000 (UTC) (envelope-from d.hill@yournetplus.com) Received: from duane.dbq.yournetplus.com (duane.dbq.yournetplus.com [65.124.230.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2080113C494 for ; Tue, 2 Oct 2007 06:13:12 +0000 (UTC) (envelope-from d.hill@yournetplus.com) Received: from [192.168.1.10] (unknown [192.168.1.1]) by duane.dbq.yournetplus.com (Postfix) with ESMTP id 8AA7A6D44B; Tue, 2 Oct 2007 06:13:11 +0000 (UTC) Date: Tue, 2 Oct 2007 06:13:11 +0000 (UTC) From: Duane Hill X-X-Sender: d.hill@duane.dbq.yournetplus.com To: Zbigniew Szalbot In-Reply-To: <94136a2c0710012303w48e7297dof1b42952e7048a34@mail.gmail.com> Message-ID: <20071002060929.D57920@duane.dbq.yournetplus.com> References: <94136a2c0710012212x506ebc0ajf76ef69ec2f36720@mail.gmail.com> <20071002051809.R57595@duane.dbq.yournetplus.com> <94136a2c0710012223q64102a41y93f3f983fcfc0137@mail.gmail.com> <20071002052548.S57595@duane.dbq.yournetplus.com> <94136a2c0710012236t28b43fc8ud92df49abf0e61d1@mail.gmail.com> <20071002054749.W57595@duane.dbq.yournetplus.com> <94136a2c0710012303w48e7297dof1b42952e7048a34@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-questions@freebsd.org Subject: Re: determining the space used in / partition 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, 02 Oct 2007 06:13:12 -0000 On Tue, 2 Oct 2007 at 08:03 +0200, zszalbot@gmail.com confabulated: > 2007/10/2, Duane Hill : >> On Tue, 2 Oct 2007 at 07:36 +0200, zszalbot@gmail.com confabulated: >> >>> 2007/10/2, Duane Hill : >>>> On Tue, 2 Oct 2007 at 07:23 +0200, zszalbot@gmail.com confabulated: >>>> >>>>> Hello again, >>>>> >>>>>>> Through df I realized my / partiotion is out of space: >>>>>>> Filesystem 1K-blocks Used Avail Capacity Mounted on >>>>>>> /dev/ad0s1a 198126 196070 -13794 108% / >>>>>>> devfs 1 1 0 100% /dev >>>>>>> /dev/ad0s1e 44511308 4217762 36732642 10% /usr >>>>>>> /dev/ad0s1d 30462636 3210580 24815046 11% /var >>>>>>> devfs 1 1 0 100% /var/named/dev >>>>>>> /dev/da0s1c 75685352 34308200 35322324 49% /mnt/usbck >>>>>>> >>>>>>> How can I determine what occupies the space in it? That is, it is not >>>>>>> big as you can see. So I issued: >>>>>>> du -hs / >>>>>>> but it was taking ages (I am not sure but maybe du -hs counts all >>>>>>> directories on the HD? >>>>>>> >>>>>>> Anyway, I do not really know where to look what has eaten the / space. >>>>>>> Were it for /usr or /var, it would be obvious to me where to look for >>>>>>> information. >>>>>>> >>>>>>> Many thanks! >>>>>> >>>>>> I don't see you have defined a /tmp partition. Perhaps /tmp is taking up >>>>>> all the space. Try: >>>>>> >>>>>> du -h /tmp >>>>>> >>>>>> and see how much /tmp is taking up. >>>>> du -hs /tmp >>>>> 1.4M /tmp >>>>> >>>>> du -hs / >>>>> 40GB >>>>> >>>>> One thing that comes to my mind. Each Sunday I have a script which >>>>> makes a full dump of the HD to a back-up USB drive. Last weekend >>>>> someone cleaining the computer room, must have accidentally powered >>>>> off the USB drive. As a result, the dump has not been completed >>>>> because the USB drive was not mounted at that time. I use cron for >>>>> this task. Does it matter could have caused this? >>>> >>>> If the '-L' switch is used (telling dump it is dumping a live file system) >>>> it will first dump everything into a .snap directory before performing the >>>> dump. What does: >>>> >>>> du -hs /.snap >>>> >>>> give for a result? >>> Thank you Duane! Yes, I do use the L switch. >>> Unfortunately, >>> du -hs /.snap >>> 2.0K /.snap >>> >>> Hah - mystery cleared! >>> I know what happened but you put me on the right track. >>> >>> For the record. During the backup, the file system is dumped to a dir >>> on a USB drive called backup. Now, since the drive was unavailable, >>> the dump utility created /backup dir and populated it with >>> lists-var-l0-2007-09-30.dump.bz2 (dumping var) but of course it died >>> as there was not enough space on the / to do it. I mean this is what I >>> make of this. >>> >>> So after deleting /backup I get: >>> df >>> Filesystem 1K-blocks Used Avail Capacity Mounted on >>> /dev/ad0s1a 198126 74084 108192 41% / >>> devfs 1 1 0 100% /dev >>> /dev/ad0s1e 44511308 4217760 36732644 10% /usr >>> /dev/ad0s1d 30462636 3210650 24814976 11% /var >>> devfs 1 1 0 100% /var/named/dev >>> /dev/da0s1c 75685352 34308200 35322324 49% /mnt/usbck >> >> I'm still learning about all the little details about the workings of >> dump myself. It would seem to me, you are dumping to /backup which is the >> mount point for the USB device. Would that hold true? > > I dump to /mnt/usbck/backup. Since backup dir was not present, the > script created it under / Thanks. I couldn't find anything in the man page that explained what would happen if the mount point for the dump was inaccessible at dump time. To me, it is still an assumption. ------ _|_ (_| |