Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Florian!
On Tue, Dec 9, 2008 at 7:54 AM, Florian Haas <florian.haas at linbit.com> wrote:
> Carlos,
>
> you really want to check out the "DRBD fundamentals" chapter in the
> User's Guide, specifically the section about resource roles at
> http://www.drbd.org/users-guide/s-resource-roles.html.
>
Thanks for pointing the guide, but i already have some knowledge about
using DRBD. In fact, we've using it for several years! Currently we
have 20 servers using it. It has always been straight and simple. But
this one is somewhat different. I'll try to reproduce here what's
going on:
chi02b:/dev/dados # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb at dale, 2006-10-25 18:17:21
0: cs:StandAlone st:Secondary/Unknown ld:Inconsistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
chi02b:/dev/dados # drbdsetup /dev/drbd0 primary --do-what-I-say
ioctl(,SET_STATE,) failed: Input/output error
Local replica is inconsistent (--do-what-I-say ?)
chi02b:/dev/dados # rcdrbd stop
Stopping all DRBD resourcesERROR: Module drbd is in use
.
chi02b:/dev/dados # rmmod drbd
ERROR: Module drbd is in use
chi02b:/dev/dados # cat /proc/drbd
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2572 build by lmb at dale, 2006-10-25 18:17:21
0: cs:Unconfigured
chi02b:/dev/dados # lsmod | grep drbd
drbd 218984 1
chi02b:/dev/dados # grep disk /etc/drbd.conf
disk {
disk /dev/mapper/dados-shared;
meta-disk internal;
disk /dev/mapper/dados-shared;
meta-disk internal;
chi02b:/dev/dados # ls -la /dev/mapper/dados-shared
brw------- 1 root root 253, 15 Dec 6 16:26 /dev/mapper/dados-shared
chi02b:/dev/dados # mkfs.ext3 /dev/mapper/dados-shared
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
655360 inodes, 1310720 blocks
65536 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
chi02b:/dev/dados # mount /dev/mapper/dados-shared /mnt
(reverse-i-search)`d': mount /dev/mapper/dados-shared /mnt
chi02b:/dev/dados # dd if=/dev/zero of=/mnt/test bs=1k count=5000000
5000000+0 records in
5000000+0 records out
5120000000 bytes (5.1 GB) copied, 148.21 seconds, 34.5 MB/s
chi02b:/dev/dados # ls -la /mnt/test
-rw-r--r-- 1 root root 5120000000 Dec 9 09:10 /mnt/test
chi02b:/dev/dados # df -h | grep shared
/dev/mapper/dados-shared
chi02b:/dev/dados # df -h | grep -A 1 shared
/dev/mapper/dados-shared
5.0G 5.0G 0 100% /mnt
chi02b:/dev/dados # rm /mnt/test
chi02b:/dev/dados # umount /mnt
chi02b:/dev/dados # drbdadm primary all
ioctl(,SET_STATE,) failed: No such device or address
Device not configured
Command 'drbdsetup /dev/drbd0 primary' terminated with exit code 20
drbdsetup exited with code 20
chi02b:/dev/dados # rcdrbd start
Starting DRBD resources: [ d0 ioctl(,SET_DISK_CONFIG,) failed:
Device or resource busy
cmd /sbin/drbdsetup /dev/drbd0 disk /dev/mapper/dados-shared internal
-1 --on-io-error=panic failed!
chi02b:/dev/dados # rcdrbd stop
Stopping all DRBD resourcesERROR: Module drbd is in use
.
So, at this point, i have some questions:
1. if the backend storage is OK, i can write to it, why drbd is
complaining about "device busy"?
2. Why the drbd module cannot be unloaded, since there isn't resources
being used?
3. Is there any way to discover what is using the drbd module,
preventing it from being rmmoded?
> Also, please be advised that DRBD 0.7 is unsupported as of Nov 30. So
> you do want to upgrade to at least the 8.0 branch, although even in 8.0
> the same fundamental principles (which you need to read up on) still
> apply. :-)
>
Sure, we have to plan this, but i need to Novell to push them to SLES,
so we got their support (although i've never used it).
Thanks,
--
Carlos Eduardo Pedroza Santiviago -- http://softwarelivre.net