Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Our internal 3ware RAID did something bad and the logs starting filling with scary errors: Jul 31 03:10:15 [kernel] [1745925.523238] PCI-DMA: Out of IOMMU space for 16384 bytes at device 0000:03:01.0 Jul 31 03:10:15 [kernel] [1745925.524623] SCSI error : <0 0 0 0> return code = 0x70000 Jul 31 03:10:15 [kernel] [1745925.524626] end_request: I/O error, dev sda, sector 47586099 (I have changed the IOMMU allocation from 32 MB to 512 MB to address the issue, I hope) One of the affected partitions is under drbd, but the rest is the root. Something somewhere made the root partition read-only. And it did so to the drbd partition too, but oddly nobody seems to be complaining they can't access the database on it. When I switched to the secondary, I can see it got all the write I/O, thanks to drbd and protocol C, but then I got to wondering what about read I/O. It can't logically be reading from the primary because the data there is no longer up to date, and I found this explanation in a previous mailing list message: > > And finally, does "DiskLessClient" really means "there is no local >> device to write to" ? Is that true for primary and secondary ? > >Yes. It means all actually IO goes via the peer; not only writes, but >also reads. So if I understand this correctly: 1) drbd is a true mirrored RAID for both writing AND reading. 2) I don't want to necessarily configure the OS or drbd to automatically kill the primary should the RAID start to fail. drbd will just use the secondary so long as the primary's OS and network are intact. This fantastic feature ought to be noted in the documentation a bit more explicitly. I previously thought of drbd only in terms of the primary's failing globally requiring heartbeat intervention to produce a failover. keywords: diskless disk less DiskLessClient ServerForDLess detach panic halt parity busfree RAID 1 failure misbehave misbehaving haywire psycho acting weird -- Maurice Volaski, mvolaski at aecom.yu.edu Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University