On Fri, Jul 14 2017, Wols Lists wrote: > On 13/07/17 23:46, Istvan Gabor wrote: >> On Wed, 12 Jul 2017 17:05:17 +0300, Andrei Borzenkov wrote: >>> On Wed, Jul 12, 2017 at 4:49 PM, Wols Lists <antlists@xxxxxxxxxxxxxxx> >>> wrote: >>>> >>>> But I suspect that going back into 12.2, and shrinking the filesystem >>>> (MAKE SURE you shrink the md device, not the sd device) >>> >>> Quite the opposite. Attempting to shrink filesystem that is already >>> effectively corrupted is potentially dangerous. So the right thing >>> here is to stop md, backup superblocks (in case they will be >> >> I am puzzled. Do I need to backup the raid superblock or the device >> superblocks or all? You cannot have too many backups. >> How do I backup the superblock? I googled but only mdadm --dump=/some/directory list of devices. >> find how to recover from superblock backup. >> > The best bet is to ask the linux-raid list what to do. > > For the raid list, this is the array I mentioned where the filesystem, > and the partitions the raid was on, were the same size. To the byte? I really like to see the output of commands that report sizes, rather than have someone claim "were the same size". It isn't that I don't trust you. I just don't trust humans in general (myself included). NeilBrown > > So we have a v1.0 mirror where the filesystem on the mirror uses up ALL > the space on the md device, not just the free space that it's supposed > to use, with all the issues that brings like filling up the filesystem > will overwrite the superblock. > > So what's the best way to recover? Will just shrinking the filesystem > bring everything back the way it should be, or are we better just > mounting the original filesystem from one disk as if it weren't a > mirror, and then recreating the mirror on the other disk, copying the > data, and then adding the first disk back in to put everything back the > way it should have been? > > Cheers, > Wol > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature