Date: Fri, 21 Oct 2016 15:23:00 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-stable@freebsd.org Subject: Re: zfs, a directory that used to hold lot of files and listing pause Message-ID: <944c8d53-7ec9-c825-03ab-daf947ef8d8e@FreeBSD.org> In-Reply-To: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk> References: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1k7eXcaHHQgGSMuASwShd5ht61m3ojDjj Content-Type: multipart/mixed; boundary="vNT5fHR2R6t5k0S1i1iPOSXAMhw7ebq3T"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-stable@freebsd.org Message-ID: <944c8d53-7ec9-c825-03ab-daf947ef8d8e@FreeBSD.org> Subject: Re: zfs, a directory that used to hold lot of files and listing pause References: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk> In-Reply-To: <E1bxZE4-0003ja-7Y@dilbert.ingresso.co.uk> --vNT5fHR2R6t5k0S1i1iPOSXAMhw7ebq3T Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016/10/21 13:47, Pete French wrote: >> In bad case metadata of every file will be placed in random place of d= isk. >> ls need access to metadata of every file before start of output listin= g. >=20 > Umm, are we not talkong abut an issue where the directoyr no longer con= tains > any files. It used to have lots, now it has none. >=20 >> I.e. in bad case you will be need tens of thousands seeks over disk >> capable only 72 seeks per seconds. >=20 > Why does it need to seek all over the disc if there are no files (and h= ence > no metadata surely) ? >=20 > I am not bothered if a hufge directoyr takes a while to list, > thats something I am happy to deal with. What I dont like is > when it is back down to zero that it still takes a long time > to list. That doesnt make much sense. Interesting. Is this somehow related to the old Unixy thing with directories, where the directory node would grow in size as you created more and more files or sub-directories (as you might expect), but it wouldn't shrink immediately if you simply deleted many files -- it would only shrink later when you next created a new file in that directory. This was a performance feature IIRC -- it avoided shrinking and re-growing directory nodes in quick succession for what was apparently a fairly common usage pattern of clearing out a directory and then refilling it. Can't see how that would apply to ZFS though, as the CoW nature means there should be no benefit to not immediately adjusting the size of the directory node to fit the amount of contents. Cheers, Matthew --vNT5fHR2R6t5k0S1i1iPOSXAMhw7ebq3T-- --1k7eXcaHHQgGSMuASwShd5ht61m3ojDjj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJYCiTLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTni2IP/3Zdgpe492bmoD1Kv3SneXEH PG5SBXSWae610nTRWMglM299xkvmqLFZZYaEEu+0aEsPuqsvFxYnuXKZYojlwqQ0 coKH2PrHIUVEMkJtTvfpS2/kZc6mWClZerby/VTrPNh5Axdav82zL0ZizaYnNOyL ID6ZYb3wewu77q31R6dUTAkdZTD/vu4rV/LCcT5yxli4874X5qLadcjXry9jiBBa ecCC8ahrzymkPJywR9J9khKMLZpWtKrqXwVTIfRYAw+oCfHE78Uw/QN8M4uMuflo u6fEQHhTgGrLPohznmtWWLNM1yfjum8jebnPpzrtLqkItE8hGkqpq/xUgUQB6Mj5 lqMi8iBx1X0FPxMy19N3VUxrDTI3BXjhflrFU7EEPvducprhCVgCgriit9lG/fXT irhMWPexwO1mFMl2rDy82NBJTFQPRefusPidnTc4tTdR/e2oF/42RuzrNYocs9cf yHJQJn1Y4omFg35sWCuZ7cTc6j66rRolVa6ezVjyUWelQ9+lRURGx6pRaqc/BdsM FgJr075Na3E/tyAWFrdFoym3TZYEbWB89QjZVj4pE7EVVip1etDCwXNxvW7Em+El Sr3gJ1Ya1Z2VMui9YtgOjt7VaEkdji53UNCMu1ja8OiCIeAfukz8eTMA9VOS+Ty7 JBiHjsXM1SikdTpyorjA =9mah -----END PGP SIGNATURE----- --1k7eXcaHHQgGSMuASwShd5ht61m3ojDjj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?944c8d53-7ec9-c825-03ab-daf947ef8d8e>