Disk mirroring as described in IOS XR Fundamentals:
"At the time of writing this book, disk mirroring is supported only between disk0: and disk1: on both CRS-1 and c12000 platforms. Disk mirroring works by replicating critical data from the primary boot device onto another storage device on the same RP. This other storage device can be referred to as a
mirrored disk or simply as a secondary device. If the primary boot device fails, applications continue to be serviced transparently by the secondary device, thereby avoiding a switchover to the standby RP. The failed primary storage device can be replaced or repaired without disruption of service."
By now, disk mirroring is also supported on ASR9000 platform:
Sam and Xander have commented that disk mirroring on ASR9000 doesn't make much sense as the disk themselves are not field replaceable.
For example: if RSP0/disk0 goes faulty, RSP0/disk1 takes over and a RSP switchover was prevented. Nonetheless, we will have to replace RSP0/disk0 eventually, so all we did with disk mirroring is postpone the maintenance action. Or am I missing something?
What about the CRS platform? Is the situation there the same or are disks field repleacable?
Thank you and kind regards,
the usb disks are soldered on the board, they are not components that we can take out from the RP.
if the disk fails, an RMA is necessary (board replacement), due to the high density of components on a board it is becoming harder and harder to manually/field replace parts unfortunately.
the disk mirroring was something historically inherited hence it being there, but realistically it doesnt make much sense anymore today.
to maintain similarity between devices, disk partitioning was done, but having a disk0 and disk1 on the same phy chip doing mirroring makes no sense :)
Thank you for your prompt answer.
Can the documentation be updated to reflect the information you provided?
Kind regards, Karlo.
yeah let me work on that karlo.
this above won't suffice?
What kind of disk error actually triggers disk mirroring, ie. RSP selecting disk1 over disk0? A file read error, file system error, somekind of device issue?
it is more like data back up karlo.
the problem is if you dont break the mirror you can't boot from disk1. there is little benefit to use that redundancy of disk0/disk1 if they are the same chip, like what i said earlier, its historic.
I recommend to cut loose that mirroring, so you can use disk0 and disk1 independently so you have more room for more images.
I understand your viewpoint if there's a physical error on the chip itself.
What about this scenario:
For eg. if there's a file system error (not a physical error, so no chip replacement needed) on disk0, RSP can use disk1 while we format disk0, so FS (FAT16) is OK again.
Steps would be something like:
mirror pause [location node-id]
show mirror [location node-id]
format disk0 partition [location node-id]
show media [location node-id]
mirror resume [location node-id]
show mirror [location node-id]
Or am I missing something here?
karlo, somewhat of an academic discussion this... usb disks dont mark bad sectors like old harddisks used to. you either use that bit position and if it is broken it can't be skipped or anything.
but hey I am not here to tell you whether or not you should use mirroring, I am just saying that knowing how this works and is implemented I cant think of any realistic benefit.
thank you for opening this interesting discussion.
I see that in RSP440 disk mirroring is almost useless being the two devices not accessible without removing the entire RSP but Cisco documentation reports
"After disk mirroring is configured, if there is a fault on the primary boot drive or it cannot be accessed for any reason, control is automatically transferred to the secondary storage device"
Hence I thought that in case of an unwanted or uncontrolled reboot mirroring still gave some little benefit if disk0 was gone and new RSP had not been still replaced.
The fact that one has to break mirroring in order to be able to boot from disk1 makes mirroring entirely useless. Would Cisco documentation be clearer in the next future about this point?
little bit of a historic statement marco from the time that the devices were truly separate. technically this statement is correct, but both disks being on the same phy chip negates the point somewhat in that statement.
We've got a similar thread for ASR9k with redundant RSPs