Date: Tue, 15 Feb 2022 18:19:53 -1000 From: "parv/freebsd" <parv.0zero9+freebsd@gmail.com> To: Frank Leonhardt <freebsd-doc@fjl.co.uk> Cc: freebsd-questions@freebsd.org Subject: Re: general zfs/zvol question Message-ID: <CABObuOrh7OPo6wh82MaRMo1vk4a814R1oM7brRSCj3eKqv7N7g@mail.gmail.com> In-Reply-To: <caf988bb-fd35-228f-7ba8-cc78039584e7@fjl.co.uk> References: <YgMiqoFU5SapPf17@cloud9.zyxst.net> <caf988bb-fd35-228f-7ba8-cc78039584e7@fjl.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000acce5305d81af83a Content-Type: text/plain; charset="UTF-8" On Tue, Feb 15, 2022 at 1:25 AM Frank Leonhardt wrote: ... > The > main problem is the extreme fragmentation caused by copy-on-write. If > your data largely static (user files) it's not a big deal. If it's a > database, with millions of random access writes to the same file, that > file's going to be spread all over the zpool and there is nothing you > can do to stop it. I thought (someone else mentioned it) that fragmentation is not of contents of files but of available free space on a ZFS pool.? - parv > If you're using SSDs or 128Gb of cache you may not > notice the difference in access times, but by this stage you're not > comparing like for like. > > Operating systems like Windoze are always making small writes to disks > and IME end up fragmented in the same way a database would. > ... --000000000000acce5305d81af83a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace">On Tue, Feb 15, 2022 at 1:25 AM Frank Leonhardt wrote:<= /div><div class=3D"gmail_default" style=3D"font-family:monospace">...<br></= div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"><span class=3D"gmail_default" style=3D"font-family:monospace"><= /span><span class=3D"gmail_default" style=3D"font-family:monospace"></span>= The <br> main problem is the extreme fragmentation caused by copy-on-write. If <br> your data largely static (user files) it's not a big deal. If it's = a <br> database, with millions of random access writes to the same file, that <br> file's going to be spread all over the zpool and there is nothing you <= br> can do to stop it.</blockquote><div><br></div><div><div style=3D"font-famil= y:monospace" class=3D"gmail_default">I thought (someone else mentioned it) = that fragmentation is not of contents</div><div style=3D"font-family:monosp= ace" class=3D"gmail_default">of files but of available free space on a ZFS = pool.?<br></div><br></div><div><br></div><div><div style=3D"font-family:mon= ospace" class=3D"gmail_default">- parv</div><br></div><div>=C2=A0</div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex">If you're using SSDs or 1= 28Gb of cache you may not <br> notice the difference in access times, but by this stage you're not <br= > comparing like for like.<br> <br> Operating systems like Windoze are always making small writes to disks <br> and IME end up fragmented in the same way a database would.<br></blockquote= ><div><span class=3D"gmail_default" style=3D"font-family:monospace">...</sp= an></div><div><span class=3D"gmail_default" style=3D"font-family:monospace"= ><br></span></div></div></div> --000000000000acce5305d81af83a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABObuOrh7OPo6wh82MaRMo1vk4a814R1oM7brRSCj3eKqv7N7g>