Date: Sat, 09 Jan 2010 18:39:23 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: ZFS performance degradation over time Message-ID: <hiaf0b$8me$1@ger.gmane.org> In-Reply-To: <4B47DC94.7020202@modulus.org> References: <7346c5c61001030842r7dc76199y51e4c1c90a3eea6e@mail.gmail.com> <hi2nsf$do5$1@ger.gmane.org> <7346c5c61001080831w375d158fu5b1996ee58cb0f8d@mail.gmail.com> <hi8kbh$fj2$1@ger.gmane.org> <4B47DC94.7020202@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Snow wrote: > Ivan Voras wrote: >> It is true that ZFS in theory doesn't do very well with random writes >> of any kind - the kind that torrent clients do should actually be the >> worst case for ZFS, *but*, this very much depends on the actual workload. > > > ZFS has aggressive read-ahead for sequential read-aheads, so its worth > noting that the performance problem can be mitigated by having lots of > RAM free for read-ahead, as well as multiple vdevs in the zpool (so that > it can be seeking all disks at once) Yes and no. Read ahead will not help performance when the data is so fragmented that the disk is seek-bound. No matter how much of the file you can get in RAM, it still needs to be fetched from the drive platters. (Except if it's smart enough to read sequential chunks from the raw storage even though they are logically not located nearly, and in case of torrents, probably belong to different files, which I very much doubt it does).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hiaf0b$8me$1>