Date: Mon, 2 Jul 2018 00:36:13 +0200 From: Polytropon <freebsd@edvax.de> To: Paul Schmehl <paul.schmehl@gmail.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Problem deleting files Message-ID: <20180702003613.6addab07.freebsd@edvax.de> In-Reply-To: <D5D87E9B8DAF0105AF7025D5@Pauls-MacBook-Pro.local> References: <85B4CFC22AC0CA70B917D42D@Pauls-MacBook-Pro.local> <20180701223144.d331ae10.freebsd@edvax.de> <D5D87E9B8DAF0105AF7025D5@Pauls-MacBook-Pro.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 01 Jul 2018 17:24:56 -0500, Paul Schmehl wrote: > --On July 1, 2018 at 10:31:44 PM +0200 Polytropon <freebsd@edvax.de> 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180702003613.6addab07.freebsd>