Date: Fri, 23 Aug 2002 23:05:36 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: keramida@FreeBSD.ORG Cc: cptacek@sitaranetworks.com, zopewiz@yahoo.com, freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <200208240605.g7O65awr041961@gw.catspoiler.org> In-Reply-To: <20020823212631.GA64644@hades.hell.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Aug, Giorgos Keramidas wrote: > The following postings describe the problems Carlos Carnero is having > with Squid causing space optimizations to be always turned on, without > his /var filesystem being too full. Those of you who are confident > about your ffs/ufs understanding correct me if I'm wrong in my > comments below, but I think I've found why this happens. Any > suggestions to avoid excessive fragmentation and avoid triggering > this? After reading what happens, I'd be indebted if you helped a bit :) I ran into similar problems in the past when I ran a Usenet server. Space optimization is most painful when a file slowly grows over time because the fragments have to be relocated every time they outgrow the available space at their current location. Because Usenet news articles are written in one shot and don't grow, space optimization doesn't cost all that much performance, so I just used tunefs to force the filesystem to always run in space optimization mode. The potential extra seek for the fragments isn't likely to matter much because even the full blocks are unlikely to all be stored sequentially in a well used Usenet spool filesystem that is run anywhere near full. Squid should show similar behaviour, so you might try the same workaround. On the other hand, if you are willing to throw some disk space at the problem to avoid any performance penalty, you could create the filesystem with the fragment size set the same as the block size. I suspect that setting the block and fragment sizes closer together than the default 8:1 ratio would help with the problem without as much cost in terms of wasted space as compared to setting them to the same size. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208240605.g7O65awr041961>