On 11/03/2015 07:45 AM, o1bigtenor wrote:
> Command (? for help): p
> Disk /dev/md0: 3907037184 sectors, 1.8 TiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 1EB47793-0CDF-4E16-AE84-33EC825AC448
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 3907037150
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 2014 sectors (1007.0 KiB)
>
> Number Start (sector) End (sector) Size Code Name
> 1 2048 3907037150 1.8 TiB 8300 Linux filesystem
>
> Command (? for help): w
>
> Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
> PARTITIONS!!
>
> Do you want to proceed? (Y/N): Y
> OK; writing new GUID partition table (GPT) to /dev/md0.
> The operation has completed successfully.
> root@debianbase:/# dmesg |tail
> [35958.237305] JBD2: Error -5 detected when updating journal
> superblock for sdh1-8.
> [35958.265302] sd 16:0:0:1: [sdh] Synchronize Cache(10) failed:
> Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
> [42828.763827] md: md0 stopped.
> [42828.764985] md: bind<sdb1>
> [42828.765270] md: bind<sdf1>
> [42828.786394] md: raid10 personality registered for level 10
> [42828.787258] md/raid10:md0: active with 2 out of 4 devices
> [42828.787316] md0: detected capacity change from 0 to 2000403038208
> [42828.859574] md0:
> [84855.526621] md0: p1
> root@debianbase:/# blkid
> /dev/md0: PTUUID="1eb47793-0cdf-4e16-ae84-33ec825ac448" PTTYPE="gpt"
> /dev/md0p1: UUID="49552036-b46f-4956-ade9-3541a3dd7f0a" TYPE="ext4"
> PARTLABEL="Linux filesystem"
> PARTUUID="2d6ef378-b27a-4de6-a42f-9c0a7e191a00"
> root@debianbase:/# fsck -n /dev/md0p1
> fsck from util-linux 2.26.2
> e2fsck 1.42.13 (17-May-2015)
> The filesystem size (according to the superblock) is 488379392 blocks
> The physical size of the device is 488379387 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort? no
You are five sectors short.
> /dev/md0p1 contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/md0p1: 618365/122101760 files (0.2% non-contiguous),
> 78222096/488379392 blocks
You will need to convert the partition table to dos -- gpt stores a
backup partition table at the end, occupying space that the ext4
filesystem is claiming.
Use gdisk to do this:
gdisk /dev/md0
select 'r' for recovery options, the 'g' for MBR conversion. Then w to
write and exit.
Then use fdisk to fix the partition:
fdisk /dev/md0
select 'd' then '1' to delete the partition.
select 'n' then 'p' for primary, then '1', then 2048, then accept the
suggested end sector (should be larger than in gdisk).
'w' to write and exit
probably need "partprobe /dev/md0" for the kernel to get the new size.
Then do a real fsck (without -n):
fsck -y /dev/md0p1
Then mount and backup.
> I think that I am right close to being able to backup the files.
Yes.
> Any suggestions for what to do after the files are backed up - - -
>
> Should I (after making backup copies) rebuild the array
>
> 1. just treat the disks as if they were empty
> 2. some other process
Just add the other drives back into the array in one step, then let them
recover.
mdadm /dev/md0 --add /dev/sdc1 --add /dev/sde1
{Use the current names if those aren't correct at this time.}
Although I wouldn't set up a new system quite like this, there's nothing
wrong with this layout. It'll be fine like this until the day you want
more space. A new bigger array would be an appropriate time to redesign.
Phil
--
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
