[DRBD-user] Resizing Issues

Jürgen Scholz juergen at kernkraft400.com
Sat Jun 14 15:55:44 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hi!

Sorry for not replying to the list; I wasn't able to properly handle  
my mail program.

> Further testing today reinforces this. We also tried resizing the  
> underlying RAID array, but again, the extra size was not seen until  
> processes were restarted.
That is because the kernel expects that the programs with a write lock  
on a blockdevice will write to it. - So the logical structure cannot  
be changed or otherwise it would be possible that data gets corrupt.
With "/etc/init.d/drbd stop" modifying the structure of the drbd  
blockdevice is possible.

> I didn't try that LRS tool you mentioned since it doesn't seem to  
> take block level image backups. That's what we'll need for  
> performance.
LRS does exactly that. It creates images of blockdevices. With two  
exceptions: It knows about the internal structure of ext3 and  
reiserfs. With these both not the whole blockdevice is copied but only  
the sectors actually containing valuable data. Free space is not  
stored. This makes backup/restore faster and does not take up more  
space than necessary.

eg: I have a few workstations with fairly big (standard sized)  
harddisks with one boot and one data paritition. For usability reasons  
the data partition is ext3 with 20-30 gigabyte space. Even when all  
relevant data is stored in the local network it's handy to have a /tmp  
with a few gigabytes free space. - The Kubuntu installes takes around  
2G of space. This 2G of relevant data gets copied or restored by LRS  
in under 10 minutes over fast ethernet. -> It saturates the network ->  
Fast

There is an VMware image available for evaluation. I strongly  
encourage you to try it!

Goodbye!
juergen



More information about the drbd-user mailing list