Hi Eliezer, it depends. The problem is not the NAS/SAN per se, but the disk access patterns. Squid's disk access pattern, regardless the technology, is always randomly-timed 4kb writes (in case of Rock, they are sequential, in *ufs scattered). If the NAS/SAN uses a write-back policy, it is possible that by the time it decides to flush to disk, squid has written to a full stripe and everyone will be happy (except for RAID5 or 10); this is relatively likely in case of Rock, unlikely in case of *ufs. But every time a write is not stripe-aligned, the NAS/SAN will have to read and write N stripes (N >= 2 depending on the type of RAID). This is a bit suboptimal for the NAS/SAN in case of Rock, but it will likely hurt the SAN/NAS performance in case of *ufs. In case the SAN/NAS policy is not write-back but write-through, any option (including rock) will adversely affect the SAN/NAS performance. On Thu, Jun 25, 2015 at 2:09 PM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > Hello list, > > I was wondering if someone has ever tried to use a SAN\NAS as the cache > backend? > Since rock cache type\dir changed the file handling way from "lots of files > db" into a single(and one more) cache db There is surly a way to benefit > from nas and SAN. > > If someone have used san(ISCSI) or nas(NFS) for any of the cahed dirs type I > would like to run some tests and you can help me not repeat old tests > resolts. > > Thanks, > Eliezer > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users -- Francesco _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
