Re: strange partition table and slow speeds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux