From owner-freebsd-questions@freebsd.org Sun Jul 1 22:49:14 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 039F4FE430C for ; Sun, 1 Jul 2018 22:49:14 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F3018224E for ; Sun, 1 Jul 2018 22:49:12 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.97.38]) by mrelayeu.kundenserver.de (mreue002 [212.227.15.167]) with ESMTPA (Nemesis) id 0MA0ZU-1fOnfJ1ysi-00B839; Mon, 02 Jul 2018 00:36:13 +0200 Date: Mon, 2 Jul 2018 00:36:13 +0200 From: Polytropon To: Paul Schmehl Cc: FreeBSD Questions Subject: Re: Problem deleting files Message-Id: <20180702003613.6addab07.freebsd@edvax.de> In-Reply-To: References: <85B4CFC22AC0CA70B917D42D@Pauls-MacBook-Pro.local> <20180701223144.d331ae10.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:W9qYmgw/XRgb9nV8Fn0kY7K4P93QXXVIoBzDvl6sbv2XvWm6sLt D1AkXf6ihiaj+bXmLa7U9Hwbv54ncFMunHBp8knnPSMMHQIY80EdV5Sn8QDa1lOaA4cnU3Y +6i7juvwCZQH+8U0ZJ9X7Kg0M/dDXgEv2MhljlCZkL35wrST0EHJZjkaPryfF/rJJhmvWQd KzlE89+0hRJ8PUYQ6CMEQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:sXdDeGL5Qqc=:5WJANGlCR9gSjIQSUyooPC jQR0wgpapQvO9sJMu6RRGthtdErecT+Q0YdpFafBhaBfgoQSgyUFDUwSW8lnryBlC/ZCU0AxL ZFalnxaJxOZ6Sg3sYY3NHko9zmfT34tuEkJWXr7gOAbvy2eODQyVKiAMxTbeQ4tRIKTc4aoMc WnaqvaYYlAvy+sjvKGFVAhvhiB3ms7CP8/9L1T3ZIoP9+DZt56egEjRlkWV5cajlopSNVVUD+ 7yMqbv+B9lyUZRX2erI/WTPLEzZjF7SDKr74XFdf6umTOYfB2u8z5gPBBh1SQz2L2NBCmq02U OaIOdNExxNltWF3z7oEIY5j8iPq511SQzrUFglSdjFlXS0Iy9ngaOCtpCZiHHc1YzLcmv4+z2 beQcJN+ZvZ4mppIu4IIQdOdYsSFQzqLBVXLPXd2BxEQ+23QA6xAL9oosr7EGNSz4+6e3q4a0k IxW2adXs8K/mhK41rb/9wM4KG4KiJFsqjdYd9+IQ36UyC/QpKX5IHSmr9bKJPFNmCsgZHXYcF 4YoNQl+d4JkohPorubH97mWeU5DaPfD8FxSexPFlwZWVKgeKKbFeqZJlSO0bi03lp0uyuTHZZ KsBCQBt/xPD8J9aju5STtiG8o3hWTkGrqEjGaz2e3yz/qmffjnKO8zXSkFhZ3SEB5nn12L3hk h0KWA8ceQvUkHM6Vq9TPWZ2JwsY/Di7mojYtDdLSqgp2Lcs5Wjfdhc4kbTKR8XLaZbbxX+/hB xgpgNczgtaF8n0nu X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 22:49:14 -0000 On Sun, 01 Jul 2018 17:24:56 -0500, Paul Schmehl wrote: > --On July 1, 2018 at 10:31:44 PM +0200 Polytropon wrote: > > > On Sun, 01 Jul 2018 14:13:30 -0500, Paul Schmehl wrote: > >> I have a problem with a directory full of files that I can't seem to > >> delete. [...] > >> If I try to delete that specific filename, it seems to work. (Running rm > >> twice returns no such file the second time.) Yet the file count remains > >> the same. > > > > Is this on UFS or ZFS? > > > > If UFS, unmount the partition and perform a "fsck -f" for > > that partition. In worst case, do it twice. > > > > The problem is, I'm working remotely on a production server. Unmounting > /var would bring a lot of things to a screeching halt, wouldn't it? Okay, so the problem is on /var... yes, that is problematic as many programs expect /var (and its subtrees) to be available for reading and writing during normal operation. However, you can still run "fsck -f /var" on a mounted filesystem for diagnostic purposes (NO WRITE). This will at least tell you if there is a problem with filesystem integrity. For such a test, disk activity should be as low as possible. > The process that Yasuhiro suggested is working. It's just taking an > interminably long period of time. I'm down to just over 4 million files > now. I'm going to let it run overnight and see where we're at tomorrow. When you use a program that calls unlink(), and you have certain sync operations in there, a delay is caused due to the many layers that require the "command - delete - sync - confirm" kind of operations, from the top level of virtual filesystem down to the disk device driver. But as you see the number of files decreasing, everything should be fine. So no need to dirty old "clri". ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...