Results 1 to 10 of 11

Thread: expanding partition on RAID array

Hybrid View

  1. #1
    Join Date
    Aug 2006
    Beans
    87

    expanding partition on RAID array

    I have a 3ware 9500S-8 RAID card running with Ubuntu 10.04 64 bit server.

    The array is not the boot drive.


    I added a drive to my array (using the 3ware migrate utility). This expanded my array to 5.4 TB. Ubuntu is not 'seeing' the new space. I understand this is because the partition space hasn't been allocated.

    Using gparted, I attempted to expand the partition to take up the full space on the drive.

    Gparted fails; I saved the log file, but I can't locate it on my system - not sure where it was put.

    Gparted correctly identified the correct size of the drive prior to attempt to extend the partition.

    Questions:

    Is there a limit on drive size that gparted can address?
    Is there another tool I can use to correctly extend the partition and get full use of the array? I don't want to create a separate partition - I'd like to keep it as a single partition.

    Any help is appreciated.

    Andrew

  2. #2
    Join Date
    Aug 2006
    Beans
    87

    Re: expanding partition on RAID array

    This is the error message created by gparted. I'm not sure how to fix the gpt as suggested.

    Help?



    GParted 0.6.2

    Libparted 2.3
    Grow /dev/sdc1 from 2.73 TiB to 4.55 TiB 01:52:16 ( ERROR )

    calibrate /dev/sdc1 00:00:03 ( SUCCESS )

    path: /dev/sdc1
    start: 34
    end: 5859311582
    size: 5859311549 (2.73 TiB)
    check file system on /dev/sdc1 for errors and (if possible) fix them 00:55:49 ( SUCCESS )

    e2fsck -f -y -v /dev/sdc1

    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

    28367 inodes used (0.01%)
    3453 non-contiguous files (12.2%)
    47 non-contiguous directories (0.2%)
    # of inodes with ind/dind/tind blocks: 21237/4359/90
    310327601 blocks used (42.37%)
    0 bad blocks
    105 large files

    27269 regular files
    1089 directories
    0 character device files
    0 block device files
    0 fifos
    0 links
    0 symbolic links (0 fast symbolic links)
    0 sockets
    --------
    28358 files
    e2fsck 1.41.12 (17-May-2010)
    grow partition from 2.73 TiB to 4.55 TiB 00:00:00 ( ERROR )

    old start: 34
    old end: 5859311582
    old size: 5859311549 (2.73 TiB)
    check file system on /dev/sdc1 for errors and (if possible) fix them 00:56:23 ( SUCCESS )

    e2fsck -f -y -v /dev/sdc1

    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

    28367 inodes used (0.01%)
    3453 non-contiguous files (12.2%)
    47 non-contiguous directories (0.2%)
    # of inodes with ind/dind/tind blocks: 21237/4359/90
    310327601 blocks used (42.37%)
    0 bad blocks
    105 large files

    27269 regular files
    1089 directories
    0 character device files
    0 block device files
    0 fifos
    0 links
    0 symbolic links (0 fast symbolic links)
    0 sockets
    --------
    28358 files
    e2fsck 1.41.12 (17-May-2010)
    grow file system to fill the partition 00:00:01 ( SUCCESS )

    resize2fs /dev/sdc1

    resize2fs 1.41.12 (17-May-2010)
    The filesystem is already 732413943 blocks long. Nothing to do!

    libparted messages ( INFO )

    The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
    Not all of the space available to /dev/sdc appears to be used, you can fix the GPT to use all of the space (an extra 3906207744 blocks) or continue with the current setting?
    The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
    Not all of the space available to /dev/sdc appears to be used, you can fix the GPT to use all of the space (an extra 3906207744 blocks) or continue with the current setting?
    Unable to satisfy all constraints on the partition.

    ========================================

  3. #3
    Join Date
    Mar 2010
    Location
    Woonsocket, RI USA
    Beans
    3,195

    Re: expanding partition on RAID array

    I was pretty sure that libparted (upon which GParted is based) corrected this problem automatically. I could be misremembering, though, or it could be a version-specific difference.

    In any event, you can use my GPT fdisk (gdisk) to fix the problem. Download and install the latest version from its Sourceforge downloads page (the version in the Ubuntu repositories is hopelessly out of date), and do this:


    1. Type "sudo gdisk /dev/sdc" (or whatever the appropriate device filename is)
    2. Type "x" to enter experts' mode
    3. Type "e" to relocate the backup data
    4. Type "w" to save your changes.



    You can also create new partitions with gdisk, if you like, but if you want to resize partitions, GParted is much easier to use.

  4. #4
    Join Date
    Aug 2006
    Beans
    87

    Re: expanding partition on RAID array

    srs5694,

    Thanks for the response - I believe you replied directly to an email from me with the same info.

    A bit of clarification:

    Are you saying that if I follow your four steps my problem is (hopefully solved)? Or do I need additional steps somewhere between steps 1 and 4?

    Additionally, do I need to run these steps AFTER I run gparted and it fails or just 'all by themselves'.

    I'm tarring up the array now, but I'd rather not have to f*%#% it up (the array) and do a restore.

    All your help and hand-holding is appreciated.

    Andrew

  5. #5
    Join Date
    Mar 2010
    Location
    Woonsocket, RI USA
    Beans
    3,195

    Re: expanding partition on RAID array

    Once the software is installed, those four steps fix it. It doesn't matter whether or not GParted looks at the disk first (unless of course doing so would fix the problem, in which case my procedure would do neither harm nor good).

    Backups are always good. You may also want to check out the 'b' option on the gdisk main menu; that backs up the partition table itself so that you can restore it later. This could be handy if a partitioning tool clobbers the partition table without damaging the filesystems within the partitions.

  6. #6
    Join Date
    Aug 2006
    Beans
    87

    Re: expanding partition on RAID array

    Ran the program and no change to array size.

    Downloaded the newest version (64 bit) and ran it. Completed successfully.
    Upon reboot, the array is still 3.0 TB in the OS and 5.4 on the 3ware side (it sees everything).

    I ran the commands exactly as stated and then ran
    sudo sync
    3 times (read in one other post somewhere to do that)

    Stubborn array!

    I'm happy to provide more info, but I don't know what to do next.

    Andrew

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •