Date: Thu, 20 Oct 2016 16:18:31 +0200 From: "Dr. Nikolaus Klepp" <dr.klepp@gmx.at> To: freebsd-stable@freebsd.org Subject: Re: zfs, a directory that used to hold lot of files and listing pause Message-ID: <201610201618.31186.dr.klepp@gmx.at> In-Reply-To: <4d9269af-ed64-bb73-eb7f-98a3f5ffd5a2@norma.perm.ru> References: <4d9269af-ed64-bb73-eb7f-98a3f5ffd5a2@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Donnerstag, 20. Oktober 2016 schrieb Eugene M. Zheganin: > Hi. > > I have FreeBSD 10.2-STABLE r289293 (but I have observed this situation > on different releases) and a zfs. I also have one directory that used to > have a lot of (tens of thousands) files. I surely takes a lot of time to > get a listing of it. But now I have 2 files and a couple of dozens > directories in it (I sorted files into directories). Surprisingly, > there's still a lag between "ls" and an output: > > > ===Cut=== > > # /usr/bin/time -h ls > .recycle 2016-01 2016-04 2016-07 2016-10 > sort-files.sh > 2014 2016-02 2016-05 2016-08 ktrace.out > sort-months.sh > 2015 2016-03 2016-06 2016-09 old > sounds > 5.75s real 0.00s user 0.02s sys > > ===Cut=== > > > I've seen this situation before, on other servers, so it's not the first > time I encounter this. However, it's not 100% reproducible (I mean, if I > fill the directory with dozens of thousands of files, I will not > certainly get this lag after the deletion). > > Has anyone seen this and does anyone know how to resolve this ? It's not > critical issue, but it makes thing uncomfortable here. One method I'm > aware of: you can move the contents of this directory to some other > place, then delete it and create again. But it's kind of a nasty workaround. Hi! I've the same issue, but only if the ZFS resides on a LSI MegaRaid and one RAID0 for each disk. Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201610201618.31186.dr.klepp>