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

Also fdisk says on top:

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

["Followup-To:" header set to comp.os.linux.misc.]
On 2008-01-23, Ignoramus11153 <ignoramus11153@NOSPAM.11153.invalid> 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.
>
> 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.
>
Does it show sdb1 as an extended partition? Perhaps you should back up
your data, just in case, and create a logical partition with gparted.
You might need to resize the filesystem to use the entire partition.

> 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

In comp.os.linux.misc Ignoramus11153 <ignoramus11153@nospam.11153.invalid> 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

On 2008-01-23, Ignoramus11153 <ignoramus11153@NOSPAM.11153.invalid> 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

brothel slavery, having served their apprenticeship
as domestic slaves. We are informed that fully seven-tenths of the
domestic slave girls found in Chinese homes in America--and every
well-to-do Chinese family (except Christians) keeps at least one or
two slaves--end their lives in immorality. Some of them when they
become old enough are seized by their masters as concubines, others
are sent to the brothels. Reports of conditions at Hong Kong which we
have already quoted, speak of the special celebration of the entrance
of a virgin into prostitution, and the high prices paid by patrons for
this initiation, but leave it obscure as to the nationality of the men
who initiate girls into the life of a brothel slave. But Chinese in
San Francisco do not hesitate to make the charge that Chinamen recoil,
through moral sense or superstition, from deflowering a virgin, and
that this horrible privilege is purchased at a special price by the
white, not the yellow patrons of Chinese houses of ill-fame. Baker
alley has probably been the scene of more terrible brutality of this
sort than any other part of San Francisco. Before the rubbish was
cleared away, in the oasis of

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.

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

On 2008-01-23, Joshua Baker-LePain <jlb17@begone.spam.duke.edu> 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

On 2008-01-23, Joshua Baker-LePain <jlb17@begone.spam.duke.edu> wrote:
> On 2008-01-23, Ignoramus11153 <ignoramus11153@NOSPAM.11153.invalid> 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

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)