> I have lot of crash from drain.
> If we drain two nodes at same time, how make sure data wont get
> replicated to either of them.
>
> So can we drain them in RDONLY mode ?
>
I think these days dpm automatically sets a filesystem to RDONLY when
you try to set it draining (which has bitten me before after I forgot to
reset the state of a filesystem after a partial drain). So yes, you can
(only) drain in RDONLY mode.
Of course this can lead to a lot of juggling due to the confusion the
RDONLY state causes to free space calculations in DPM.
Cheers,
Matt
> On Wed, Dec 16, 2015 at 1:08 PM, Matt Doidge <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> I've not had as many woes with draining as Govind up in Lancaster,
> but it is slow.
>
> We don't do anything exciting - we run a dpm-drain with 4 threads in
> a screen session within a "while true; do" loop. A typical 36TB
> server takes the better part of a fortnight, and we try not to do
> more then two at a time to avoid overloading the system (also it
> makes juggling the various spaces easier).
>
> One thing I did noticed when I started this last batch of drains is
> that I had neglected putting the newest disk pools in the oldest
> disk pool's shift.conf, which caused some errors.
>
> My apologies for likely teaching you all how to suck eggs here!
>
> Cheers,
> Matt
>
>
>
>
> On 16/12/15 10:52, George, Simon wrote:
>
> Hi,
>
> as you already know from some questions Govind posted, we are
> trying to
> drain some storage nodes.
>
> I'd like to give you the bigger picture and ask for advice on
> the best
> approach.
>
> We have to decommission 14 old storage nodes to make rack space
> for new
> equipment.
>
> They run SL5 with DPM 1.8.8.4.
>
> There are two time scales:
>
> 1) We need them all decommissioned by the start of March 2016.
>
> 2) We also need one available asap to test an idea we have to
> reuse them.
>
> With the draining problems so far I am concerned about 1, let
> alone 2.
>
> If we don't succeed the choice will be between losing the data, and
> accepting new hardware (i.e. paying) without racking it up and
> turning
> it on, neither of which are satisfactory options to me.
>
>
> So I would like to ask if you have any advice on the best
> strategy to
> get this going smoothly and quickly.
>
> Thanks,
>
> Simon
>
>
|