Resized my partions and all didnt go that well, advice needed

English Install/Boot/Login
1

I needed to resize my partition. Gparted seemed to be right tool.

Now it looks like this http://dl.dropboxusercontent.com/u/25648002/ScreenHotGparted.png
I changed sdb3 and sdb4. Moved sdb4 up and smaller and sdb3 bigger. Now the part where moved sdb4 away is unallocated in sdb3 and also this change left at the end unallocated space too. Hopefully I make some sense of what I did.

Everything works ok and all data still there, except missing 2tb+ disk space now.

Fdisk output:


# fdisk -l /dev/sdb                                                                                                                                                                                                                                              
                                                                                                                                                                                                                                                                               
Warning: GPT (GUID Partition Table) noticed ”/dev/sdb”! Fdisk does not support GPT. Use GNU Parted.                                                                                                                                                                  
                                                                                                                                                                                                                                                                              
Disk /dev/sdb: 6000.0 GB, 5999966552064bytes                                                                                                                                                                                                                                  
255 heads, 63 sektoria/ura, 729454 sylinteriä, yhteensä 11718684672 sektoria                                                                                                                                                                                                   
Yksiköt = 1 * 512 = 512 -tavuiset sectors                                                                                                                                                                                                                                      
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                                                                                                                                                          
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                                                                                                                                              
Levyn tunniste: 0x00000000                                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                               
    Device   Start         End    Lohkot   Id  System                                                                                                                                                                                                            
/dev/sdb1          2048   644239359   322118656   83  Linux                                                                                                                                                                                                                  
/dev/sdb2     644239360  1288476671 322118656   83 Linux                                                                                                                                                                                                                  
/dev/sdb4               1           1           0+  ee  GPT

Ok, that partly in .fi but should be selfexplanory. Tried to translate most.

Hardware:
3ware raid-5 card totaling 4x 2tb hdd
ssd boot so raid is only for storage
intel i7 k2600
OpenSuse 12.3
WinXp and Win7 In VirtualBox on sdb3

sdb3 missing totally in fdisk and sdb4 somehow changed to gpt? insted of ext4 it was like sdb1 and sdb2 are.
What I need advice on, before I loose any data how could I fix that? Or just live with it? Because not sure if that raid-5 works with all that unallocated space. And I really don’t want to loose a disk and then notice that can’t be retrieved back.

2

On 2013-11-16 10:36, Gholkro wrote:

> Ok, that partly in .fi but should be selfexplanory. Tried to translate
> most.

Please, make that in English.
When the system language is not English, you should do,
in order to post here, like this:


minas-tirith:~ # LANG=en_US.UTF-8 zypper info kvm
Loading repository data...
Warning: Repository 'openSUSE-11.4-Update' appears to outdated. Consider
using a different mirror or server.
Reading installed packages...

or this:


minas-tirith:~ # LANG=C zypper info kvm
Loading repository data...
Warning: Repository 'openSUSE-11.4-Update' appears to outdated. Consider
using a different mirror or server.
Reading installed packages...
^C

Even for gparted.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

3

First, I think that what you posted should be enough for me. The picture is clear enough I think I understand enough to have some thoughts.

I’m unsure about one thing… What that dotted line enclosure is around sdb3.
My first guess is that sdb3 might actually be a logical drive in an extended partition, but I’d need to see some other gparted screens to verify that. Also, by simply clicking on the object (dotted line) usually gparted will tell you what you just clicked on.

If this is the case, then the solution should be fairly simple. You will need to “operate” on the extended partition very much like the partitions and logical drives themselves (re-size and if necessary re-position).

If that dotted line is something else, click on it and post again what gparted tells you it is.

TSU

4

I don’t know why it was changed to “gpt”, except that for that size disk it is better to use “gpt”. Perhaps “gparted” prompted you and you accepted the change without paying enough attention.

In any case, given that the disk is “gpt”, you need to look at it with “gdisk” rather than with “fdisk”. The missing partition might well turn up when you use the correct tool.

5

I’m unsure about one thing… What that dotted line enclosure is around sdb3.

You guessed kinda right. I had clicked on it and it was ‘selected’.

Partition info with gdisk (looks kinda correct as 4x2tb -2tb for raid + 200gb unallocated seems to add up close to the correct number = 5.8TB)


Disk /dev/sdb: 11718684672 sectors, 5.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 07EECCCF-254C-4822-A93E-902C001D4E3B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 11718684638
Partitions will be aligned on 2048-sector boundaries
Total free space is 438654909 sectors (209.2 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       644239359   307.2 GiB   0700  primary
   2       644239360      1288476671   307.2 GiB   0700  primary
   3      1288476672      9964070911   4.0 TiB     0700  primary
   4      9964070912     11280031743   627.5 GiB   0700  primary

And more detailed below.


Partition number (1-4): 1
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: 60EBECCA-5FD6-4A4D-9967-47D9BA5D4FD2
First sector: 2048 (at 1024.0 KiB)
Last sector: 644239359 (at 307.2 GiB)
Partition size: 644237312 sectors (307.2 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Partition number (1-4): 2
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: 58A53EE9-8A8F-477E-A277-BA334B43042E
First sector: 644239360 (at 307.2 GiB)
Last sector: 1288476671 (at 614.4 GiB)
Partition size: 644237312 sectors (307.2 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Partition number (1-4): 3
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: B97A2BDE-C2EE-472A-A3D9-E2E8F65E7216
First sector: 1288476672 (at 614.4 GiB)
Last sector: 9964070911 (at 4.6 TiB)
Partition size: 8675594240 sectors (4.0 TiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Partition number (1-4): 4
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: D80A28EF-8A26-46BA-AEB8-827575F853A4
First sector: 9964070912 (at 4.6 TiB)
Last sector: 11280031743 (at 5.3 TiB)
Partition size: 1315960832 sectors (627.5 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

I like to give enough information. So one can see the full picture.

Looks like all partitions ok. But how to format that unallocated space iinside partition without loosing data allready in there? Should I try to resize it smaller - then format the unallocated to ext4 - resize back?

Also last partition is gpt and array is raid-5 and cant find any information if that affects raid functionality. I do not want to find out the hard way. One could think that raid just spreads the data and nondependant of the format on disk as long as that 3ware card can read it. Don’t know.

There is an option to ‘convert GPT into MBR and exit’ in gdisk. Maybe going to try that but wonder if it destroys data there? Anybody?
Here is how I see it-But- the data part! Anyway 1. sdb4 GPT->MBR 2. Format the unallocated to ext4 3. Resize sdb4 with gdisk to include the 200gb+ at the end. I cant figure out a solution to sdb3 yet. Maybe same way with gdisk. Just need to know if it looses the data. Those root partition apps do have that bad tendency.

I have Win7 and WinXP under vbox in sdb3. If I wanted to be sure, I’d go buy couple 2tb disks and backup everything and reformat/partition. But dont have the $ and that much of data its gonna take a week+. And pc is online in production (my www pages). Slow raid card. Its only for storage.

6

Here’s some thoughts. To be honest, your situation puzzles me somewhat. I thought that openSUSE 12.3 would pick up a GPT partitioned disk automatically - even one converted from MBR - at least after a reboot or power off/on cycle. What you describe here, doesn’t indicate that. I would also think that discontinous partitioning wouldn’t matter, as the tables would be pointing properly, but that may also be incorrect. Actually, there are a few things here that I am not fully aware of (I’m in the process of studying the topic myself). Maybe all that is missing, is fstab content to match, and that is what is not being generated automatically (see below for some of that). However, even if you should test my suggestions, I doubt that they could harm your setup, as they are hardly any more destructive than a gparted partition resize/move.

I assume the following, as it hasn’t been described:
You are booting from an SSD disk that is booting to openSUSE 12.3 directly, and no other OS-es are involved in this setup except from those located inside VMs as you describe. Your openSUSE kernel is obtained from standard openSUSE repositories (as in: you haven’t compiled it yourself and thereby disabled the support for GPT disk partitioning).

Some history would help as well. A guess: You got more storage and you wanted to make use of it (of course, who wouldn’t ;)). You used to have your partitions elsewhere in another storage setup which was less than 2TiB in total size, thus there were nothing but MBR disk partitioning. This was transferred to the (new?) 3ware RAID5 4 x 2TiB disk volume as-they-were, keeping the MBR partitioning scheme.

When you moved sdb4 out of the 2TiB area offset from the disk’s start, it cannot be accessed through MBR any more, as there is an absolute 2TiB limit to what MBR can address. So it “became” GPT - and the same happened to sdb3 when you made it larger than 2TiB.

Note, however, like your gdisk-dump above demonstrates, your whole volume including the sdb1 and sdb2 partitions are now true GPT partitions, as disk partitioning isn’t a per-partition-thing. GPT covers the whole disk - or not. That goes for MBR too, but see below.

This is a consequence if the GPT partitioned disk is accessed as if it was MBR partitioned. openSUSE needs to be told that the new data store is GPT, not MBR. That may not happen automatically (but I thought it would), as GPT incorporates a “protective MBR” offering an old fashioned MBR table for old-style disk-accessing SW to be happy. In fact, your experience may be an example of that - I haven’t tried that myself.

If everything went well during conversion (it wold seem so from what you explain), all data are intact and you could actually redo it by shrinking and “un-moving” the partitions to their original sizes. You would, however, not revert back to pure MBR by that - you would still have GPT, but it wouldn’t matter. Within the first 2TiB of any disk volume, GPT is MBR compatible also, and the disk data can be accessed as if they were stored in the old fashioned MBR way. You should be careful manipulationg GPT disks with “on-the-iron” MBR disk manipulation SW, though, as e.g. fdisk, as they may overwrite the GPT tables in an attempt to “rectify disk problems”.

3ware says that all their RAID-controllers are all full HW RAID implementations. That makes your RAID-5 functionality transparent to any OS, and you can forget about what RAID-5 does to your data, and openSUSE can ignore it just as you. But you cannot move individual disks out of the RAID-5 system and connect it to, say, a SATA-only controller and expect to read data from it. That will not work.

Don’t do that unless you have “undone” your resizing of your partitions first. See above.

** Suggestions that you can test prior to reverting to your original partition sizes:**

Based on the gdisk output above, openSUSE did pick up the partitions - but they are not mounted. That suggests that the following should work:

Accessing sdb3 and sdb4:
Start a terminal:

su -
mount -n UUID=B97A2BDE-C2EE-472A-A3D9-E2E8F65E7216 /dev/sdb3
mount -n UUID=D80A28EF-8A26-46BA-AEB8-827575F853A4 /dev/sdb4
exit
exit

I picked the UUIDs from your gdisk dump above, so you should be able to copy the command without editing - provided I do remember the mount-syntax correctly (it is provided off the top of my head - I don’t have Linux available atm.). Now, start a GUI file manager and see if they become accessible.

If that worked, you should unmount sdb4. Again, from a terminal:

su -
umount /dev/sdb4
exit
exit

Moving sdb4:
Start gparted as you did earlier and select sdb4, and select it for resizing. You should see a number >0 in the uppermost size-entry (space before partition). Set that to 0. Apply, and wait for sdb4 to be moved just after sdb3. Now all unused space on your RAID should be available for you to use as you like - readily available in one chunk at the end of the disk.

fstab:
If accessing sdb3 and/or sdb4 didn’t work above, you could try the same procedure now. If you can access these partitions now, you should be ready to edit the fstab file to make the partitions to mount automatically when booting openSUSE. That, however, is something I have to read up on myself, before instructing anybody else;). I have to come back on that, unless somebody else beats me to it (which would be preferrable, as you would save time waiting).

Let us know how it worked out. Good luck!

dayfinger

7

Thank You for taking the time to share thoughts, ideas and advice. I’ll start ‘playing’ with those ideas on this coming weekend as a live system so can restore if something goes wrong before monday.

Cant just figure out that 2tb limit because I have 3tb (4x1tb) raid-5 on my sql server where I also boot from the raid. Its running 11.4 as never bothered upgrading as no need.It doesent even have keyboard nor monitor. Or actually never checked, it could be capped to 2tb usable space…

Also you guessed quite correct how this current system setup as of the setup that didn’t mention. And also nice thoughts you gave me on that long post what to do next.

Tnx again. Will let you know monday how it went.

8

On 2013-11-19 22:06, Gholkro wrote:

> Cant just figure out that 2tb limit because I have 3tb (4x1tb) raid-5 on
> my sql server where I also boot from the raid. Its running 11.4 as never
> bothered upgrading as no need.It doesent even have keyboard nor monitor.
> Or actually never checked, it could be capped to 2tb usable space…

The limit is a partition limit, not filesystem limit. Those partitions
of yours are just 1 TB, it is the filesystem which is 3 TB. At least of
software raid, I’m unsure on real hardware raid.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

9

Hmmmm…will need to check that as only have 1 3tb partition + swap there. Never thought of some limits on size. That might be then the reason to my probs. So I’ll just resize and move partitions around a bit and make sure all <2tb.

10

On 2013-11-19 22:46, Gholkro wrote:
>
> Hmmmm…will need to check that as only have 1 3tb partition + swap
> there. Never thought of some limits on size. That might be then the
> reason to my probs. So I’ll just resize and move partitions around a bit
> and make sure all <2tb.

Wait. Using traditional partitioning, or MBR partitioning, I understand
that the total partition space is 2 TB. Or rather the disk space that
the partition table can index.

See, for example:


> http://blogs.technet.com/b/askcore/archive/2010/02/18/understanding-the-2-tb-limit-in-windows-storage.aspx

(Windows or Linux does not matter here)

+++······································
Partition Size Limitation

The partition size is pretty straight forward. On an MBR (Master Boot
Record) disk, the locations where the partition sizes are stored are
only 4 bytes long. Since this is in hexadecimal, the largest value we
can stuff in there is all F’s. So the max value would 4,294,967,295 in
decimal.

FF FF FF FFh = 4294967295d

This maximum partition size is not in bytes, it is in number of sectors.
Since currently sectors are limited to 512 bytes, the maximum size ends
up being 2 TB.

4,294,967,295 sectors * 512 bytes/sectors = 2,199,023,255,040 bytes or 2TB.
······································+±

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

11

Ok. Did some reading after the latest replies. No wonder fdisk couldnt read my partitions but needed to use g(pt)disk as GPT filesystem partly, formatted ext4. Max partition size then 16TB and 128 partitions on a disk (or raid) and disk max size 8.6 billion TB. MBR only allows 2TB and 4 partitions on a single disk.

Here is best explaining article so far that found: Make the most of large drives with GPT and Linux (writer is the author of gdisk)

That is quite well written and explains things that I partly accidentally allready made as have both MBR and GPT filesystems on same disk. If you are as stupido on partitioning then me and want to learn about it Read that article : )

Thank you all that made me realize MBR restrictions. Not everything solved on my prob yet, but after reading previous replies and that article, I now a bit wiser too. My raid card can take 12 disks so can add 1-8 more to test my new knowledge!

12

On 2013-11-20 00:56, Gholkro wrote:
>
> Ok. Did some reading after the latest replies. No wonder fdisk couldnt
> read my partitions but needed to use g(pt)disk as GPT filesystem partly,
> formatted ext4. Max partition size then 16TB and 128 partitions on a
> disk (or raid) and disk max size 8.6 billion TB. MBR only allows 2TB
> and 4 partitions on a single disk.

Here we should stop a minute and use the right units. The limit is not 2
TB, but 2 TiB. A 2 TB disk doesn’t have a problem with MBR, because it
is about 2% smaller than 2 TiB

> Here is best explaining article so far that found: ‘Make the most of
> large drives with GPT and Linux’
> (http://www.ibm.com/developerworks/linux/library/l-gpt/) (writer is the
> author of gdisk)

It is indeed a good explanation. Good find, thanks.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

13

A small correction:
You may find that the above mount commands will fail with “directory does not exist” or something similar. That would be because, normally, /dev/sdb3 and /dev/sdb4 aren’t existing directories.

Either you need to create them (“mkdir /dev/sdb3” etc) or you create entirely different directories where you want the mount points to be, and modify the mount statements above, accordingly. But you must specify full paths in the mount command. The mount point is where you can access its content. Example:

su -
mkdir /mypartition
mount -n UUID=B97A2BDE-C2EE-472A-A3D9-E2E8F65E7216 /mypartition
df -h
cd /mypartition
ls -l
exit
exit

dayfinger

14

…mmmm not entirely correct, if I may say so. 2TB is approx. 10% smaller than 2TiB. While 1KB is approx. 2% smaller than 1KiB, it scales up:

1MB = 1000B x 1000 [x 1000 = 1GB etc.]
1MiB = 1024B x 1024 [x 1024 = 1GiB etc.]

That makes
1TB = 1 x 10^12 bytes = 1000000000000 bytes
1TiB = 1 x 2^40 bytes = 1099511627776 bytes (or 10000000000 bytes in hexadecimal notation) :wink:

For others reading this:
The notation of KB, MB, GB, TB etc. are all based on the day-to-day non-technical decimal numbering system, where e.g. the “K” means kilo (=1000), “M” means mega (=1000000) etc.
The notation KiB, MiB, GiB, TiB etc. are all based on the binary numbering system, where e.g. “Ki” means kilo which is “nearly 1000”, or 1024 (=2^10). Further, 1Mi=2^20, 1Gi=2^30, 1Ti=2^40.
The last letter “B” means bytes (as opposed to “b” which would mean bit - there are 8b in 1B - 8 bits in 1 byte).

dayfinger

15

On 2013-11-20 02:46, dayfinger wrote:

…

> You may find that the above mount commands will fail with “directory
> does not exist” or something similar. That would be because, normally,
> /dev/sdb3 and /dev/sdb4 aren’t existing directories.

Depends on what machine, in mine they do exist. At best, the call would
fail; at worst, terrible. I’m not going to try and find out :wink:

> Either you need to create them (“mkdir /dev/sdb3” etc)

No, never create mount points in /dev, even less with a reserved name
such as sdb3. Results can be unpredictable, even damaging.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

16

I’ve seen that “exist” and “not exist” myself when testing lately. That’s why I said “may” not exist. The difference may have been when using live DVDs and not (13.1RC2 64bit KDE live DVD to be specific).

Point taken. Thanks.

dayfinger

17

On 2013-11-20 03:16, dayfinger wrote:
>
> robin_listas;2598999 Wrote:
>> Here we should stop a minute and use the right units. The limit is not 2
>> TB, but 2 TiB. A 2 TB disk doesn’t have a problem with MBR, because it
>> is about 2% smaller than 2 TiB
>
> …mmmm not entirely correct, if I may say so. 2TB is approx. 10%
> smaller than 2TiB. While 1KB is approx. 2% smaller than 1KiB, it scales
> up:

Ah, right… the percent is not constant.

> For others reading this:

…

To add to the confusion, disk manufacturers have always used powers of
10, like “GB”, while for the rest of the industry MB meant a power of 2.
Nowdays they keep using the same units, which now happen to be the
industry standard (and correct), but some people keep using “MB” meaning
the power of 2 units, that is, when they should write “MiB”.

The result is that when we see “MB” we do not know if they mean “MB” or
“MiB” till clarified.

What is clear is that a 2 TB disk, size specified by the manufacturer,
is way smaller that 2 TiB and thus usable with MBR partitions. :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)