2015-02-21 My dad's computer had two old hard disks. Both of them showed problems already. I wasn't worried too much, as they formed a RAID1. If one broke down, then I could care for the situation, so I thought. But as the system slowed down more and more (presumely because of failed disk accesses and retries or sector reloca- tions) I decided to exchange the disks now. I removed the two old disks one by one and put new (still old, but not that old and not as broken) disks in, always resyncing the RAID1. I even put one spare disk in, for faster replacement, in case one of the new (old) disks starts to show errors soon. Everything was dead easy, at least so it seemed: # mdadm /dev/md0 -f /dev/sda1 -r /dev/sda1 # mdadm /dev/md0 -a /dev/sdc1 Wait for the resync and do the same for the sdb to sdd exchange. Then wait for the second resync and add the spare disk. The problem was, that one of the new disks had been part of an array in former times. This screwed things up. I wasn't able to add the partition, because it regarded as being too small -- it was not, but had been in the old array, before it was resized. Also, the array wouldn't reassemble automatically. Eventually, I managed to get it fixed by overwriting the start of the disk (super-block or something like that). I ran this command for some time, then killed it: dd if=/dev/null of=/dev/sdc Afterwards I partitioned the disk anew: sfdisk -d /dev/sda | sfdisk /dev/sdc And could add it to the array. :-) Here is a part of my shell session, when I struggled with the problem. It shows nicely that the command line interface of mdadm(8) is badly designed. There is no single concept behind the placement and order of devices, mode-options, normal options. Some modes are explicit, others are implicit ... A large mess it is: # mdadm /dev/md0 -U super-minor -a /dev/sdc1 mdadm: -U does not set the mode, and so cannot be the first option. # mdadm /dev/md0 --manage -U super-minor -a /dev/sdc1 mdadm--update in Manage mode only allowed with --re-add. # mdadm /dev/md0 --manage -U super-minor --re-add /dev/sdc1 mdadm--update in Manage mode only allowed with --re-add. # mdadm /dev/md0 --manage -U super-minor --re-add mdadm--update in Manage mode only allowed with --re-add. # mdadm --manage -U super-minor --re-add /dev/sdc1 mdadm--update in Manage mode only allowed with --re-add. # mdadm --manage --re-add -U super-minor /dev/sdc1 mdadm: only 'devicesize' can be updated with --re-add # mdadm --manage --re-add -U devicesize /dev/sdc1 mdadm: /dev/sdc1 does not appear to be an md device Ju visited me and told me about One-time Pads. I haven't head about it before. He said that it would be cool to use OTPs. If it were between just two persons and if they would meet in person at least once a year, then they could exchange fresh generated pads. We would just need some integration into messaging software. We thought that it would be most simple for chat clients, but I might write some scripts for mmh as well. ;-) It had become late while we were talking about that stuff: ``... it wouldn't be that difficult to implement an OTP, would it? No, just a few lines in C ... we could write it right now, within half an hour.'' We both remembered a great programming session two or more years ago, when, being at exactly the same point, we just started to hack it. We made the same decision today: [0] This is a sample session: $ dd bs=1 count=1024 key $ echo welt | ./otp key 6 | ./otp key 6 | od -c 11 11 0000000 w e l t \n 0000005 The let's-make-the-program-as-short-as-possible session later that night was pretty funny, but be broke the code at some point ... possibly it was when we started with all those defines. ;-) Maybe I'll come back to that task, some day. [0] http://marmaro.de/prog/various/otp/otp.c http://marmaro.de/lue/ markus schnalke