Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2005-04-19 19:22:29 +0800 \ David Huang: > >> What if i stop the DRBD service, mount the LV to do some modification > > or add more files on the filesystem and restart the DRBD? > > do I need to extend the lv size again?? > > >this does not make any sense. > > >it seems to me that your understanding > >of what drbd does for you is wrong. > > >what exactly do you think drbd is? > >(please answer this, so we can correct you) > > DRBD provides block-level, live replication of data, isn't it? yes. > >what do you mean by > >"do some modification or add more files on the filesystem"? > > >why do you think you'd need to mount the LV to modify some files? > >(mounting, even accessing the lower level device is a big no-no!) > > what you mean is that I shouldn't stop DRBD anytime if possible? If you access (that is, modify) the physical device, without going through drbd, drbd does not know. So it can not resync (replicate), because it can not know what to sync. > the reason I am thinking to stop DRBD service is because I like to do > scheduling replication. Because there are numbers of LV(15~20) on my > system, i was assuming that if all of the LV do the replication at the > same time, there will be performance issue. It's why I was thinking to > run DRBD only in the off-peak time. So it is no longer "live". If you don't want live replication, then why drbd? You are aware that you lose redundancy? If you wanted to do that, you are aware that you should still go through the drbd device, NOT the lower level device? See the comment above. Maybe drbd is just not the right tool for the job? Try scheduled rsyncs, or similar. > Is there any testing report about using large number of DRBD devices > at the same time? throughput does NOT depend on number of devices. as you say, it is live replication. so if there are no requests, there is nothing to replicate. if there are many requests, all go through the network and the peer storage as well as the local storage. this is independend of number of devices. but yes, if your usage pattern already pushes local storage limits, the additional latency and/or network bandwidth may be a problem. what peek demands do you expect? what makes you think drbd could not cope? have you any benchmarks yourself? Lars Ellenberg -- please use the "List-Reply" function of your email client.