Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Jeff Buck a écrit :
>How long can you sustain that for? In our testing, it seemed that we
>could get it to work quickly for a bit, but then for anything extended
>it would hit a brick wall at a certain point. I think the brick wall was
>right around the al-extents line IIRC. The real problem was with how
>hard it hit that brick wall.. The server would become completely
>unresponsive for 10-30 seconds at a time, and this condition would
>continue off and on until the massive IO operation was complete. The
>funny thing was, that the time it took to complete the massive IO
>operation would end up being almost exactly the same as whatever our
>sync speed after an invallidate was.
>
>Depending on your usage patterns, this may not matter at all, but we
>were putting together a file server for power users, and we can't count
>on a users never copying a 2-4 gig file to the server.
>
>With our Areca controller and the same hard drives, we cannot find a
>brick wall to run into. We have filled the entire device at full speed,
>and the system never became unresponsive.
>
>If your al-extents is set to 257 then try copying a 2 or 3 gig file to
>the device and time it. You might also want to check for temporary hangs
>on the machine while you do it.
>
>I don't mean to say the 3ware cards are horrible... We have and use a
>number of them still, but we just couldn't punish the 3ware the way we
>were hoping to for this particular server. Our server for our backups is
>pretty mission critical and still uses a 3ware card. It seems to work
>like a champ on that machine.
>
>On Tue, 2005-08-16 at 20:34 -0400, Yves Trudeau wrote:
>
>
>>Hi,
>> I just want to clarify a few thing I have read in the archive of
>>this mailing list about 3Ware Raid cards. We have a bunch of these
>>cards and we used them with DRBD. It it true that the sync process when
>>we "invalidate" one end is very slow. With our setup, we get ~6 Mo/s.
>>But once "Consistent", we can write on the drbd partition at more than
>>30 Mo/s which is quite good.
>>
>>Yves
>>
>>
>>
>
>
>
Hi,
what you say is exact during the sync operation. During that phase,
I can literaly freeze the server for a long time (up to 15 minutes) just
buy copying a large file (> 5 GB). I this is cause by the dirty write
cache of Linux which defaults to 30% of physical RAM (in ou case
4GB*30%). But once in "consistent" state, everything seems to be
normal, replication is almost as fast as transfering a file from the
network. It seems to me that DRBD/3Ware is slow when DRBD has to read
the data on the disk before transfering it to the other node. If the
data just comes through DRBD and then sent to the local et remote drive,
performance is OK.
Yves
--
Yves Trudeau, Ph. D., MCSE, OCP
Analyste Senior
Révolution Linux
819-780-8955 poste *104
Toutes les opinions et les prises de position exprimées dans ce courriel
sont celles de son auteur et ne répresentent pas nécessairement celles
de Révolution Linux
Any views and opinions expressed in this email are solely those of the
author and do not necessarily represent those of Revolution Linux