Replication DiskLess

Hi,

I have a strange and undocumented state for my replication :
Protocol type: Synchronous
Connection: Connected
Source info:
Logical volume: lv0003
Consistency: Diskless
Destination info:
Logical volume:lv0003
Consistency:Consistent
IP address: 192.168.0.2

Image : http://imageshack.us/photo/my-images/823/diskless.jpg/

http://imageshack.us/photo/my-images/823/diskless.jpg/

From DRBD documentation :

Diskless. No local block device has been assigned to the DRBD driver. This may mean that the resource has never attached to its backing device, that it has been manually detached using drbdadm detach, or that it automatically detached after a lower-level I/O error.

Im worry about this...

Any help ?

What can i do ?

Thanks

nsc

Send in the log file from the source server, you could have some array issues for that logical volume. Check the RAID controller logs to see the health state of the array.

Failed. Transient state following an I/O failure report by the local block device. Next state: Diskless.

Thanks Tom, i have no error in Areca management.
i'm creating a support ticket right now.

We are looking at them now, there is some drop packets on eth1 and there is a MTU/Jumbo frame miss match value MTU:1500 / 9000 for your bond 1. You also need to update both of your DSS systems to the latest version, you have very old version.

Now from the logs it shows the lv0003 not online but only active ( lv+b+lv0003 vg+vg00 -wi-a- 1000.00G). So "-wi-a" should look like "-wi-ao" the "a" means active and the "o" means online. Try to stop and restart the LUN from the Target.


Version: 6.0up55.8101.5087

eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.

bond1 Link encap:Ethernet HWaddr 02:54:48:5C:5F:7F
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:9000 Metric:1
RX packets:29394787420 errors:811 dropped:0 overruns:0 frame:811
TX packets:38990567435 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:67970103894290 (61.8 TiB) TX bytes:258399518745771 (235.0 TiB)

eth0 Link encap:Ethernet HWaddr 02:54:48:5C:5F:7F
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:251

eth1 Link encap:Ethernet HWaddr 02:54:48:5C:5F:7F
UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1
RX packets:29394787420 errors:811 dropped:0 overruns:0 frame:811
TX packets:38990567435 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:67970103894290 (61.8 TiB) TX bytes:258399518745771 (235.0 TiB)
Interrupt:250 Base address:0x8000

Hi To-M,

For MTU, i can't change it. When Bond is up, with the console management i can only change the MTU for Bond not the MTU for each attached NIC :

http://img810.imageshack.us/img810/2701/bondmtu.png

For my LUN, everything look OK :

http://img51.imageshack.us/img51/3735/lunx.png

So i just stop / start the replication task :

http://imageshack.us/photo/my-images...plication.png/

For Update, i knew that i have an older version but after 6 months without any errors or problems, i'm not a big FAN of updating something working ;-)

We'll see affter the end of replication.

Quote:

---

Originally Posted by nsc

For MTU, i can't change it. When Bond is up, with the console management i can only change the MTU for Bond not the MTU for each attached NIC :

---

So you created the Bond without setting both of the NICs to Jumbo frame value - then you will have to schedule some down time then to break the bond and set the other NIC to the proper Jumbo frame and re-create the bond.

Thanks for the info about MTU on Bond.

After the restart of replication task, the lv0003 goes down and nothing working anymore.
I have to hard reset my two ESX Host after a proper restart for OpenE.

But the data stored n VMDK from LV003 are corrupted :(

I think the hard reset was too hard...

Did you checked your RAID Controller health, also your RAID Array (storage disks) health?

hey guys i am here and i want to know much more about DSS.

(Advertising link deleted by Open-E team).

You can get the manual from our website at:
http://www.open-e.com/service-and-su...loads/manuals/

Or contact us as mentioned in the "contact us" menu in our website.

Hi,
we have exactly the same problem (but we are not bonding and our mtu is set properly). After some network errors and dropped packages we have the state consistent/diskless on three LV as can be seen here:
http://imageshack.us/photo/my-images/42/diskless.png/
There were no errors from the Raid-controller.
How can we come back to a consistent/consistent state?
I have also opened a ticket for this: 1031171

The system start to be in Diskless when there are mostly an I/O errors, so the system try to protect your data by going to diskless mode, as keep reading/writing while there are I/O errors that could lead to lose some data.

In such case, the best to do is to check the RAID controller and storage disks health.

Hi,
we don`t have any disk errors logged by the raid-controller but we had some network problems. My question is how I can come back to an consistent/consistent state and how I can update now. The primary system has 6 LVs, the secondary too. On each LV is a replication task(primary is source, secondary is target). On the primary system 5/6 LVs are in the state diskless/consistent. So my first question is: does that mean, that the storage for these LVs is actually accesed on the secondary system via the replication interface?

The last of the LVs is in the state consistent/consistent. So how should I update the system and come to an consistent/consitent state? Should I shut down the primary and use the secondary as main storage (as it has all LVs in a consistent state) while updating the primary and afterwards, when both are in a consistent state again, switch all back?
Or should I shutdown the secondary (on which in my opinion the storage is accesed), update it and start the replication from an (diskless) primary again?