public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Goryachev <mailinglists@websitemanagers.com.au>
To: Andreas Klauer <Andreas.Klauer@metamorpher.de>,
	Wols Lists <antlists@youngman.org.uk>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Linux raid wiki - setting up a system - advice wanted :-)
Date: Mon, 26 Sep 2016 13:40:53 +1000	[thread overview]
Message-ID: <2f6bd11c-3232-7548-288e-3a503c160d31@websitemanagers.com.au> (raw)
In-Reply-To: <20160926021622.GA25056@metamorpher.de>

On 26/09/16 12:16, Andreas Klauer wrote:
> On Sun, Sep 25, 2016 at 10:16:24PM +0100, Wols Lists wrote:
>> I need to know what will happen if you give entire drives to mdadm.
> Installers will pick unpartitioned disks first. Forget just trashing
> the metadata, easy to accidentally write across the entire disk.
>
> This is what it looks like when installing Windows: http://imgur.com/a/GtcR2
>
> Same can happen with Linux installers. Unpartitioned disks are just unusual.
>
> Not sure why this is a thing anyway. There's no downside to partitions.
> Adds a safety margin, is yet another place that has metadata (with GPT
> you can use mdnumber-role as partition name / partlabel), doesn't harm
> performance in any way...
>
> People panic too much about partition alignment? But alignment is something
> you need to provide through all layers, all the way down to the filesystem,
> not just partitions. Besides, MiB alignment has been standard for years now,
> so this shouldn't be a problem.
>
> The only other obscure issue with partition tables I can think of is
> enclosures for USB-HDD that emulate the wrong sector size (4K vs 512)
> and unfortunately GPT still depends on the sector size; and Linux is
> not flexible/smart enough to support alien sector size GPT partitions.
>
> So if you switch HDD enclosures you might be forced to recreate
> the partition table before you can access your data.
>
Personally, I agree, avoiding a partition table has almost zero benefit. 
Having a partition table can help massively (ie, clearly identifies the 
drive as in-use, shows the content of the drive/partition (RAID), etc....
I would think using a USB interfaced drive in a raid array is hopefully 
not common, and changing the enclosure should be even less common, 
though perhaps likely when dealing with failures.... Can you comment on 
the behaviour of removing the drive from the enclosure and direct 
connecting it? What is the worst case scenario here?
When you say forced to recreate the partition table, I assume in the 
majority of cases it is just delete and re-create using 100% of 
available space, or is there some other difference (eg, the gap at the 
beginning of the drive that might require some searching for the right 
value)?

Regards,
Adam



-- 
Adam Goryachev Website Managers www.websitemanagers.com.au

  reply	other threads:[~2016-09-26  3:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-25 21:16 Linux raid wiki - setting up a system - advice wanted :-) Wols Lists
2016-09-26  0:59 ` Francisco Parada
2016-09-26  8:17   ` keld
2016-09-26  2:16 ` Andreas Klauer
2016-09-26  3:40   ` Adam Goryachev [this message]
2016-09-26  6:50   ` Wols Lists
2016-09-26 14:13     ` Phil Turmel
2016-09-26 15:48       ` Wols Lists
2016-09-26  9:30 ` keld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f6bd11c-3232-7548-288e-3a503c160d31@websitemanagers.com.au \
    --to=mailinglists@websitemanagers.com.au \
    --cc=Andreas.Klauer@metamorpher.de \
    --cc=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox