that's a pretty huge cache, have you considered using 8*9gb disks
instead of 4*18? what sort of request throughput/latency are you
aiming for? as the number of requests grows, disk seek times are
a very real problem.
> One of my partners thinks that we should use reiserfs on all the server (the
> partitions of the Linux distro, and the cache partitions), and I found out
> that reiserfs has had lots of bugs, and is marked as experimental in kernel
well, lots of bugs in reiserfs have been fixed.. obviously there are
more bugs to come (as always), but on the whole a lot of people are very
happy with it. there certainly haven't been many posts of reiserfs
corruption lately at all on linux-kernel.
> 2.4.4. Not to mention that the people of RH discourage there users from using
> it.
they do?
> So what I want is to know which is the status of this 3 journaling FS. Which
> is the one we should look for?
xfs, while wonderful, probably isn't what you're looking for. AFAIK it
is intended more for very very very large files.
> I think that the data lose is not significant in a proxy cache, if the FS is
> really fast, as is said reiserfs is.
data loss is always significant. consider the case where you are forced
to rebuild the filesystem squid's cache directories reside on...
admittedly it is an extreme case, but it is a possibility all the same.
reiserfs is supposed to be very good with lots of small files, which is
the typical case for a squid cache. however there's no substitute for
actual testing. benchmark your squid server (use polygraph, from the
squid website) with each fs, and remember to test each of squid's
cache_dir options (diskd, aufs, coffs, ufs).
also appropriate could be ext2 with daniel phillips' directory indexing
patches.
test. test. test. good luck.
j.
-- "Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/