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. ****************************************************
