Re: strange partition table and slow speeds

[Benjamin ESTRABAUD <be@mpstor.com>]

You simply don't have a partition table on those disks.

This is not a problem. Disks do not specifically need to be partitioned.
In a way, it's like if you did "mkfs.ext3 /dev/sdX" instead of 
"mkfs.ext3 /dev/sdXn". The entire drive (including the space for the 
partition table) can be expected to be used.

The fact that it was there "before" and not anymore could be a fluke, 
some of the superblock may have only been written later on.

The fact that it is not there will not affect performance in any way, 
and the array is likely the same as it always was.

Regards,
Ben.

On 17/12/12 21:16, Alex Pientka wrote:
> I want to understand why my partition table is suddenly different
> moving it from one system to a different one. This happened after I
> moved the 6 drives from one system to the new system.
>
> Is this the reason why I suddenly have such bad performance?
> Alex
>
>
> On Mon, Dec 17, 2012 at 3:47 PM, Roy Sigurd Karlsbakk <roy@karlsbakk.net> wrote:
>> why would you want to use partitions for such a RAID in the first place?
>>
>> ----- Opprinnelig melding -----
>>> That brings up the question: Any reason to get the partition table
>>> fixed up? Is this just a cosmetic issue?
>>> Alex
>>>
>>>
>>> On Mon, Dec 17, 2012 at 12:41 PM, Phil Turmel <philip@turmel.org>
>>> wrote:
>>>> [Top-posting repaired. Please don't.]
>>>>
>>>> On 12/17/2012 12:26 PM, Alex Pientka wrote:
>>>>> On Mon, Dec 17, 2012 at 12:18 PM, Phil Turmel <philip@turmel.org>
>>>>> wrote:
>>>>>> Hi Alex,
>>>>>>
>>>>>> On 12/17/2012 09:17 AM, Alex Pientka wrote:
>>>>>>
>>>>>> [trim /]
>>>>>>> /dev/md0:
>>>>>>>          Version : 1.1
>>>>>>                     ^^^^^
>>>>>> You've deliberately chosen a metadata version that places the
>>>>>> superblock
>>>>>> at sector 0 of the given device. If that is a whole disk, it
>>>>>> overwrites
>>>>>> the partition table. The default metadata is v1.2 (which places
>>>>>> the
>>>>>> superblock at offset 4k) for this very reason.
>>>>> I assume upgrading to v1.2 is not possible. The only other way
>>>>> would
>>>>> be to fail every raw device (one-by-one) and then create the fd
>>>>> partition on it, correct?
>>>> You could put the array back on partitions if you like. I'd make a
>>>> complete backup, zero the superblocks, and use --create
>>>> --assume-clean
>>>> to switch to v1.2 in place (with due care to maintain the device
>>>> order
>>>> and data offsets).
>>>>
>>>> (Save the output of "mdadm -E /dev/sdXX" for each member device
>>>> before
>>>> you start.)
>>>>
>>>> However, that fdisk can't understand the partition table shouldn't
>>>> be
>>>> hurting anything, so I wouldn't make it a priority.
>>>>
>>>> BTW, partition type 'fd' is deprecated along with v0.90 metadata, as
>>>> it
>>>> only impacts kernel non-initramfs autoassembly, and that only works
>>>> with
>>>> DOS partition tables and v0.90 metadata.
>>>>
>>>> Phil
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> Vennlige hilsener / Best regards
>>
>> roy
>> --
>> Roy Sigurd Karlsbakk
>> (+47) 98013356
>> roy@karlsbakk.net
>> http://blogg.karlsbakk.net/
>> GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
>> --
>> I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html