Date: Mon, 5 Sep 2016 20:30:19 +0200 From: Ben RUBSON <ben.rubson@gmail.com> To: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: [ZFS] refquota is very slow ! Message-ID: <67B3E11E-22B7-4719-A7AF-B8479D35A6D2@gmail.com> In-Reply-To: <f5969fc9-44e2-a8a0-1a7f-9475e65ab93a@internetx.com> References: <D559DE69-A535-427C-A401-1458C2AA8C31@gmail.com> <1472914773423.63807@kuleuven.be> <0E828163-AEAB-4C8C-BFCF-93D42B3DB3B6@gmail.com> <1524067530.1937.a66cb17f-9141-4bef-b758-5bb129d16681.open-xchange@ox.internetx.com> <EDDE17FC-1B3A-4912-B93C-08E18433A4C9@gmail.com> <f5969fc9-44e2-a8a0-1a7f-9475e65ab93a@internetx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, I want to dedicate my ARC & L2ARC to my data pool (which anyway = suffers from the same bug...). I followed your advices and created a whole new SSD test pool, let all = options by default, and added lz4 compression. I then create 20.000.000 empty files in this test pool. Then : # zfs set quota=3D7.5G refquota=3Dnone test/test # dd if=3D/dev/random of=3D/test/test/bf dd: bf: Disc quota exceeded 1047553+0 records in 1047552+0 records out 536346624 bytes transferred in 16.769513 secs (31983434 bytes/sec) # rm /test/test/bf # zfs set quota=3Dnone refquota=3D7.5G test/test # dd if=3D/dev/random of=3D/test/test/bf dd: bf: Disc quota exceeded 1047520+0 records in 1047519+0 records out 536329728 bytes transferred in 215.986582 secs (2483162 bytes/sec) # rm /test/test/bf Additional tests give the same results. 6MB before the limit, write IOs are done very slowly and it takes = minutes to fulfil these remaining MB. How many files in the pool you performed this test in Juergen ? Ben > On 05 Sep 2016, at 10:04, InterNetX - Juergen Gotteswinter = <juergen.gotteswinter@internetx.com> wrote: >=20 > any special reason for disabling secondarycache and limiting the > primarycache to metadata? does it change something when you revert it = to > default? >=20 > compression -> lz4, even if its not compressable, it wont hurt >=20 > you probably got several smaller performance issues which end up in = this > mess all together. >=20 > Am 04.09.2016 um 17:16 schrieb Ben RUBSON: >> Same kind of results with a single local (SSD) disk based pool, = refquota takes much more time than quota around the limit. >>=20 >> Here is the output for this single disk based pool : >> zfs get all : http://pastebin.com/raw/TScgy0ps >> zdb : http://pastebin.com/raw/BxmQ4xNx >> zpool get all : http://pastebin.com/raw/XugMbydy >>=20 >> Thank you ! >>=20 >> Ben >>=20 >>=20 >>> On 04 Sep 2016, at 13:42, InterNetX - Juergen Gotteswinter = <juergen.gotteswinter@internetx.com> wrote: >>>=20 >>> Did you try the same in a single local disk based pool? And pls post = output of >>> zfs get all, zdb & zpool get all >>>=20 >>>=20 >>>> Ben RUBSON <ben.rubson@gmail.com> hat am 4. September 2016 um 11:28 >>>> geschrieben: >>>>=20 >>>>=20 >>>> Juergen & Bram, >>>>=20 >>>> Thank you for your feedback. >>>>=20 >>>> I then investigated further and think I found the root cause. >>>>=20 >>>> No issue with refquota in my zroot pool containing (in this = example) 300.000 >>>> inodes used. >>>>=20 >>>> However, refquota is terribly slow in my data pool containing = around >>>> 12.000.000 inodes used. >>>>=20 >>>> I then created 12.000.000 empty file in my zroot pool, in a test = dataset. >>>> I put a refquota on this dataset and created a dd file to fulfil = empty space. >>>> And around the limit, it began to stall... >>>> I then created an empty dataset in the same pool, refquota is even = slow in >>>> this dataset having no inode used. >>>> The root cause seems then to be the total number of inodes used in = the pool... >>>>=20 >>>> Some numbers : >>>> Time to fulfil 512MB with quota : 17s >>>> Time to fulfil 512MB with refquota : 3m35s >>>>=20 >>>> Very strange. >>>>=20 >>>> Do you experience the same thing ? >>>>=20 >>>> Thank you again, >>>>=20 >>>> Ben >>>>=20 >>>>> On 03 Sep 2016, at 16:59, Bram Vandoren = <bram.vandoren@kuleuven.be> wrote: >>>>>=20 >>>>> I encountered the same problem over NFS. I didn't manage to = reproduce it not >>>>> using NFS. I think the userquota property works without any = problem though. >>>>>=20 >>>>> Cheers, >>>>> Bram. >>>>=20 >>>>> On 03 Sep 2016, at 12:26, InterNetX - Juergen Gotteswinter >>>>> <juergen.gotteswinter@internetx.com> wrote: >>>>>=20 >>>>> cant confirm this, works like a charm without difference to normal = quota >>>>> setting
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67B3E11E-22B7-4719-A7AF-B8479D35A6D2>