Keith Freedman wrote: > Also, I'd remove your read-ahead, write-behind, and io-cache, and > test again, then add back only one at a time, then 2 at a time, then > all 3 and see what your results are. > Personally, I dont trust using them with AFR.. it's probably safe, > but I have fears that the write-behind will capture data which is > written later while it's busy being changed on another > server. Read-ahead might be ok in AFR, but even still. you risk > pre-fetching data that changes a second later so you're out of > date... if I'm wrong I'm sure one of the devs will chime in. I can confirm that under 1.3, using the write-behind and read-ahead caches in an AFR environment, especially if you're dealing with lots of changes to many small files, can result in a total nightmare. We've seen files appear to be empty, files with out-dated content, and files with the content of /other/ files in them. When we disabled translators, all of these problems ceased to occur. Unfortunately, removing performance translators has the side effect of (you guessed it) hurting performance. Even though we no longer have occasionally inconsistant data, we also took a severe performance hit for the rest of the Gluster-hosted files which, normally, worked without a hitch. Mr. Avati has suggested that under 1.4 this would no longer be the case, as writes are now atomic. We're actually going ahead with the upgrade to 1.4 today - hopefully we'll be able to re-enable the translators... -- Daniel Maher <dma+gluster AT witbe DOT net>
