Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tuesday 02 August 2005 22:31, logch_l at wldelft.nl wrote:
> >> -----------------
> >> resource drbd0 {
> >> protocol C;
> >
> > Depending on your requirements regarding the data safety you could try
> > to use protocol A or B, we are using B and are quite pleased.
>
> Thanks for the suggestions.
>
> about nfsd) I can't export async because we need the most gracefull
> fail-over ; there are always HPC clients writing..
Hmm pity, we began using drbd last summer and were forced after some nasty
kernel bugs to switch from 2.6. to 2.4., in the mean time there's at least a
workaround for this bug and we can using 2.6. again. Without the async nfsd
export option we probably would have been forced to disable drbd, since it
was with 2.4. by far too slow (around 11-14MB/s to the drbd device with 2.4.,
but 40-60MB/s with 2.6.). However, drbd is mostly used for the home
directory, which we mostly use for our source code, papers and other relative
small data (program i/o is stored to other non-failover devices). With 2.4.
the latency for nfs+sync+drbd was so high, that compiling our programs became
dramatically slower and would have been the main reason to disable drbd,
using the async option, the latency went back almost to the sync+2.6. numbers
on the clients.
>
> drbd protocol) I was wondering about using protocol B after some googling
> but couldnt get someone to confirm it does reduce latency. Regarding
Well, I really admit that the async option did the biggest part, but switching
from protocol C to B and later to A had a noticable effect, at least with
2.4. on our systems.
> safety, our drbd cluster nodes never go down at exactly the same moment
> (the only situation in which a drbd 'write' can get lost using proto B).
>
> Q1: How does using B make a difference?
I'm afraid you will have to test this yourself, I guess it strongly depends
from system to system.
> Q2: Can one change to protocol B on-the-fly using 'drbdadm adjust'?
No clue, maybe the linbit people (Lars?) know?
>
> drbd hot area) Currently we use 521 al-extents for a 1.4 TB device. How
> much difference does it make when we increase this number? (nr of writes
> vs. size of al-extents) And also can this be changed on-the-fly?
Also no idea.
I guess that for your problem NFSv3 (and v2, of course) are not the best
option. Personally I have yet no experience with NFSv4, but from
specifications, especially regarding similar client side cache as AFS has,
its probably much more suited for your situation. Pity thats still under
heavy development, however, I will test it in the near future, since we in
principle need its much better security possibilities.
Another option for you would be to use highly experimental cachefs, which is
IMHO in -mm and there are even more experimental nfs-patches for it.
Though, probably none of those experimental things is really ready for your
and our usage...
Cheers,
Bernd
--
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert at pci.uni-heidelberg.de