Partition troubles on a GIANT storage server - Hardware

This is a discussion on Partition troubles on a GIANT storage server - Hardware ; We have a storage server with a 3ware RAID drive. It has a bunch of disks that together form a 5TB storage array. Linux sees that array as /dev/sdb. The capacity is 5 TB (as I said). fdisk sees it ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Partition troubles on a GIANT storage server

  1. Partition troubles on a GIANT storage server

    We have a storage server with a 3ware RAID drive.

    It has a bunch of disks that together form a 5TB storage array.

    Linux sees that array as /dev/sdb. The capacity is 5 TB (as I said).
    fdisk sees it as follows:

    ### Disk /dev/sdb: 5249.9 GB, 5249921187840 bytes
    ### 255 heads, 63 sectors/track, 638266 cylinders
    ### Units = cylinders of 16065 * 512 = 8225280 bytes
    ### Disk identifier: 0xcf00cb1c
    ###
    ### Device Boot Start End Blocks Id System
    ### /dev/sdb1 1 267349 2147480811 5 Extended
    ### /dev/sdb5 1 267349 2147480779+ 83 Linux

    Which is the way I want. I formatted this disk with fdisk a while
    ago. There is one giant extended partition, and a almost the same size
    logical partition inside, holding Linux data.

    The device /dev/sdb5 is mounted on /data. However, df -k /data says:

    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/sdb5 2113784952 239323764 1767087152 12% /data

    The above is wrong (or at least is not the way I expect), as I expect
    1K-blocks count to say 5 million instead of 2 million.

    This got worse as I continued looking. If I start gparted /dev/sdb, it
    tells me that the only partition is /dev/sdb1 (ignoring /dev/sdb5),
    which according to it occupies the whole array and is in use.

    Somehow gparted does not see /dev/sdb5 at all, I think.

    The same exact thing happens to QTParted.

    The server works fine.

    I am very worried that 1) I am using less than half of what is
    available and 2) that something wrong could heppen.

    Some clarification will be appreciated.

    i

  2. Re: Partition troubles on a GIANT storage server


    Also fdisk says on top:

    WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util
    fdisk doesn't support GPT. Use GNU Parted.


  3. Re: Partition troubles on a GIANT storage server

    In comp.os.linux.misc Ignoramus11153 wrote:
    > We have a storage server with a 3ware RAID drive.
    >
    > Filesystem 1K-blocks Used Available Use% Mounted on
    > /dev/sdb5 2113784952 239323764 1767087152 12% /data
    >
    > The above is wrong (or at least is not the way I expect), as I expect
    > 1K-blocks count to say 5 million instead of 2 million.
    >
    > This got worse as I continued looking. If I start gparted /dev/sdb, it
    > tells me that the only partition is /dev/sdb1 (ignoring /dev/sdb5),
    > which according to it occupies the whole array and is in use.
    >


    Well- that's "billion" not "million", right?

    2,113,784,952

    In which case it looks suspiciously like 32-bit integer issues.
    It may well be that the "df" you are using is simply unable
    to report a value greater than 32-bits allows.
    Or maybe something totally different.

    Stan

    --
    Stan Bischof ("stan" at the below domain)
    www.worldbadminton.com

  4. Re: Partition troubles on a GIANT storage server

    On 2008-01-23, Ignoramus11153 wrote:
    >
    > Linux sees that array as /dev/sdb. The capacity is 5 TB (as I said).
    > fdisk sees it as follows:
    >
    > ### Disk /dev/sdb: 5249.9 GB, 5249921187840 bytes
    > ### 255 heads, 63 sectors/track, 638266 cylinders
    > ### Units = cylinders of 16065 * 512 = 8225280 bytes
    > ### Disk identifier: 0xcf00cb1c
    > ###
    > ### Device Boot Start End Blocks Id System
    > ### /dev/sdb1 1 267349 2147480811 5 Extended
    > ### /dev/sdb5 1 267349 2147480779+ 83 Linux
    >
    > Which is the way I want. I formatted this disk with fdisk a while
    > ago. There is one giant extended partition, and a almost the same size
    > logical partition inside, holding Linux data.


    fdisk does not support a device that big. You must use parted. I also
    rather hope that you're using a GPT disklabel, as standard (msdos) ones also
    don't work on a device that large.

    > The device /dev/sdb5 is mounted on /data. However, df -k /data says:
    >
    > Filesystem 1K-blocks Used Available Use% Mounted on
    > /dev/sdb5 2113784952 239323764 1767087152 12% /data
    >
    > The above is wrong (or at least is not the way I expect), as I expect
    > 1K-blocks count to say 5 million instead of 2 million.


    Yep, it's wrong. The safest thing to do is backup the data somwhere else,
    recreate the partition (with parted), reformat, and *verify* before putting
    data on the system that everything is working correctly.

    As an aside, there's really no need to use an extended partition on a device
    you'll only have one partition on anyway. Just create one primary partition
    and format that.

    --
    Joshua Baker-LePain
    Department of Biomedical Engineering
    Duke University

  5. Re: Partition troubles on a GIANT storage server



    On Wed, 23 Jan 2008, Ignoramus11153 wrote:

    > We have a storage server with a 3ware RAID drive.
    >
    > It has a bunch of disks that together form a 5TB storage array.
    >
    > Linux sees that array as /dev/sdb. The capacity is 5 TB (as I said).
    > fdisk sees it as follows:
    >
    > ### Disk /dev/sdb: 5249.9 GB, 5249921187840 bytes
    > ### 255 heads, 63 sectors/track, 638266 cylinders
    > ### Units = cylinders of 16065 * 512 = 8225280 bytes
    > ### Disk identifier: 0xcf00cb1c
    > ###
    > ### Device Boot Start End Blocks Id System
    > ### /dev/sdb1 1 267349 2147480811 5 Extended
    > ### /dev/sdb5 1 267349 2147480779+ 83 Linux
    >
    > Which is the way I want. I formatted this disk with fdisk a while
    > ago. There is one giant extended partition, and a almost the same size
    > logical partition inside, holding Linux data.
    >
    > The device /dev/sdb5 is mounted on /data. However, df -k /data says:
    >
    > Filesystem 1K-blocks Used Available Use% Mounted on
    > /dev/sdb5 2113784952 239323764 1767087152 12% /data
    >
    > The above is wrong (or at least is not the way I expect), as I expect
    > 1K-blocks count to say 5 million instead of 2 million.



    I am not sure why you would expect this, when your partition is less than
    half the available space. You will note that fdisk reports that there are
    638266 cylinders on the disk, while your partition ends at cylinder
    267349.


  6. Re: Partition troubles on a GIANT storage server

    ["Followup-To:" header set to comp.os.linux.misc.]

    On 2008-01-23, Joshua Baker-LePain wrote:
    >
    > As an aside, there's really no need to use an extended partition on a device
    > you'll only have one partition on anyway. Just create one primary partition
    > and format that.


    Well, if you're really sure that you'll only ever have one partition,
    technically you don't even need a partition. You can simply create the
    filesystem on /dev/sdb and mount that. (Some tools will complain about
    mounting an entire physical device, though.)

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  7. Re: Partition troubles on a GIANT storage server

    On 2008-01-23, Joshua Baker-LePain wrote:
    > On 2008-01-23, Ignoramus11153 wrote:
    >>
    >> Linux sees that array as /dev/sdb. The capacity is 5 TB (as I said).
    >> fdisk sees it as follows:
    >>
    >> ### Disk /dev/sdb: 5249.9 GB, 5249921187840 bytes
    >> ### 255 heads, 63 sectors/track, 638266 cylinders
    >> ### Units = cylinders of 16065 * 512 = 8225280 bytes
    >> ### Disk identifier: 0xcf00cb1c
    >> ###
    >> ### Device Boot Start End Blocks Id System
    >> ### /dev/sdb1 1 267349 2147480811 5 Extended
    >> ### /dev/sdb5 1 267349 2147480779+ 83 Linux
    >>
    >> Which is the way I want. I formatted this disk with fdisk a while
    >> ago. There is one giant extended partition, and a almost the same size
    >> logical partition inside, holding Linux data.

    >
    > fdisk does not support a device that big. You must use parted. I also
    > rather hope that you're using a GPT disklabel, as standard (msdos) ones also
    > don't work on a device that large.


    OK.

    >> The device /dev/sdb5 is mounted on /data. However, df -k /data says:
    >>
    >> Filesystem 1K-blocks Used Available Use% Mounted on
    >> /dev/sdb5 2113784952 239323764 1767087152 12% /data
    >>
    >> The above is wrong (or at least is not the way I expect), as I expect
    >> 1K-blocks count to say 5 million instead of 2 million.

    >
    > Yep, it's wrong. The safest thing to do is backup the data somwhere else,
    > recreate the partition (with parted), reformat, and *verify* before putting
    > data on the system that everything is working correctly.


    Yes. I scheduled data backup for 1am tonight, I will double verify it
    in the morning and will redo partitioning.


    > As an aside, there's really no need to use an extended partition on a device
    > you'll only have one partition on anyway. Just create one primary partition
    > and format that.
    >


    Fair enough. So, the plan is:

    1) Backup the data at 1am tonight
    2) In the morning, verify backup
    3) umount /data
    4) use gparted to repartition. Create one primary partition only, and
    label it as linux
    5) mkfs -t ext3 /dev/sdb1
    6) remount
    7) restore the backup.

    i

  8. Re: Partition troubles on a GIANT storage server

    Ignoramus11153 wrote:
    > Also fdisk says on top:
    >
    > WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util
    > fdisk doesn't support GPT. Use GNU Parted.
    >


    Yes... this is true. In order to use traditional partitioning
    and create a single partition larger than 2TB, you have to use
    GPT instead of a normal default partition table.

    IMHO, you're better off using LVM instead though. That way
    you don't have to deal with this kind of mess.

    Also, large partitions (or logical volumes) with filesystems
    will always create a problem since it takes a LONG time to
    fsck one if something bad should happen. Just an fyi. (Other
    things are somewhat impractical as well)

    If I were starting from scratch I'd place all of /dev/sdb
    under LVM control and carve it up using logical volumes
    rather than depending on a partition table.
    (hindsight being 20/20)


  9. Re: Partition troubles on a GIANT storage server

    On 2008-01-24, Chris Cox wrote:
    > Ignoramus11153 wrote:
    >> Also fdisk says on top:
    >>
    >> WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util
    >> fdisk doesn't support GPT. Use GNU Parted.
    >>

    >
    > Yes... this is true. In order to use traditional partitioning
    > and create a single partition larger than 2TB, you have to use
    > GPT instead of a normal default partition table.


    That's what parted does by default?

    > IMHO, you're better off using LVM instead though. That way
    > you don't have to deal with this kind of mess.
    >
    > Also, large partitions (or logical volumes) with filesystems
    > will always create a problem since it takes a LONG time to
    > fsck one if something bad should happen. Just an fyi. (Other
    > things are somewhat impractical as well)


    that's OK

    > If I were starting from scratch I'd place all of /dev/sdb
    > under LVM control and carve it up using logical volumes
    > rather than depending on a partition table.
    > (hindsight being 20/20)
    >


    I am not that good with LVM, I am afraid to use it basically, the
    information in question is "valuable" and I would hate to lose it.

    i

  10. OUTCOME -- Partition troubles on a GIANT storage server

    This was a lot more trouble than I thought as gparted was refusing to
    create partitions bigger than 793 GiB. All kinds of tools like parted
    and such were not able to create a large enough logical volume.

    Finally, this sequence worked:

    $ aptitude install lvm2
    $ reboot

    after reboot:

    $ modprobe dm-mod

    $ dd if=/dev/zero of=/dev/sdb bs=512 count=1 # Zero out first block to enable adding to LVM
    $ pvcreate /dev/sdb # make it physical volume
    $ vgcreate datavg /dev/sdb # creates volume group
    $ lvcreate -n datavol -l 1251678 datavg # creates logical volume
    $ ls -l /dev/datavg/datavol
    lrwxrwxrwx 1 root root 26 2008-01-25 14:16 /dev/datavg/datavol -> /dev/mapper/datavg-datavol
    $ mkfs -t ext3 /dev/datavg/datavol # make ext3 filesystem

    /etc/fstab:
    /dev/datavg/datavol /data ext3 defaults 0 0

+ Reply to Thread