Re: [squid-users] Opinions sought on best storage type for FreeBSD

Adrian Chadd disse na ultima mensagem:
> On Sat, Aug 11, 2007, Michel Santos wrote:
>
>> I must admit I can't talk in there because I never could test it really
>> but I do not convinve myself easy by reading papers.
>
> Good! Thats why you take the papers and try to duplicate/build from them
> to convince yourself. Google for "UCFS web cache", should bring out one
> of the papers in question. 2 to 3 times the small object performance is
> what people are seeing in COSS under certain circumstances as it
> eliminates
> the multiple seeks required in the worst cases for "normal" UNIX
> filesystems.
> It also reduces write overhead and fragmentation issues by writing in
> larger chunks. Issuing a 512 byte write vs a 16k write to the same sector
> of disk is pretty much an equivalent operation in terms of time taken.
>
> The stuff to do, basically, involves:
>
> * planning out better object memory cache management;
> * sorting out a smarter method of writing stuff to disk - ie, exploit
> locality;

> * don't write everything cachable to disk! only write stuff that has
> a good chance of being read again;

there is a "good chance" beeing hit by a car when sleeping in the middle
of a highway as well there is a chance not beeing hit at all :)

well that was my knowledge about chances but here are not so many options,
or you are a hell of forseer or you create an algorithm, kind of inverting
the usage of the actual or other cache policies applying them before
caching the objects instead of controlling the replacement and aging

> * do your IO ops in larger chunks than 512 bytes - I think the sweet
> spot from my own semi-scientific tests is ~64k but what I needed to
> do is try to detect the physical geometry of the disk and make sure
> my write sizes match physical sector sizes (ie, so my X kbyte writes
> aren't kicking off a seek to an adjacent sector, and another rotation
> to reposition the head where it needs to be.)
> * handle larger objects / partial object replies better

well, the theory behind coss is quiet clear

>
> I think I've said most/all of that before. We've identified what needs
> doing - what we lack is people to do it and/or to fund it. In fact,
> I'd be happy to do all the work as long as I had money available once
> it was done (so I'm not paid for the "hope" that the work is done.)
> Trouble is, we're coders, not sales/marketing people, and sometimes
> I think thats sorely what the Squid project needs to get itself back
> into the full swing of things.
>

not sure, squid is long time on top now and probably there is no other
interesting project because caching is not so hot anymore, bandwidth is
cheap in comparism to 10 years ago and the heck today is PtP so I mean,
probably hard to find a sponsor with good money. The most wanted feature
is proxying and acl but not cache so I guess even if there are ever geeks
like us which simply like the challenge to get a bit more out of it most
people do not know what this is about and do not feel nor see the
difference between ufs and coss or whatever. To be realistic I understand
that nobody cares about diskd as nobody cares really about coss because it
would be only for you or for me and some more and so Henrik works on aufs
because he likes it but at the end it is also only for him and some
others. And this sum of some do not have money to spend it into
coss/aufs/diskd. And probably it is not worth it when the principal users
have a 8Mb/s adsl for 40 bucks why they should spend money on squid's fs
development?

Michel
...

****************************************************
Datacenter Matik http://datacenter.matik.com.br
E-Mail e Data Hosting Service para Profissionais.
****************************************************
Received on Sat Aug 11 2007 - 11:48:12 MDT