All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leslie Rhorer <lesrhorer@att.net>
To: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: My superblocks have gone missing, can't reassemble raid5
Date: Wed, 19 May 2021 11:54:44 -0500	[thread overview]
Message-ID: <337ea246-99b0-2834-8b07-e12025d04b7d@att.net> (raw)
In-Reply-To: <e4258686-7673-9f5f-d333-fbbb95c066b1@turmel.org>

On 5/19/2021 8:41 AM, Phil Turmel wrote:
> On 5/19/21 9:20 AM, Leslie Rhorer wrote:
>>
>>
>> On 5/18/2021 1:31 PM, Reindl Harald wrote:
> 
> [trim/]
> 
>>> leave some margin and padding around the used space solves that 
>>> problem entirely and i still need to hear a single valid reason for 
>>> using unpartitioned drives in a RAID
>>
>>      I can give you about a dozen.  We will start with this:
>>
>> 1. Partitioning is not necessary.  Doing something that is not 
>> necessary is not usually worthwhile.
> 
> 1a: sure.  1b:  I can think of many things that aren't *necessary* but 
> are certainly worthwhile.  I can even throw a few out there, like 
> personal hygiene, healthy diets, exercise.  In this context, I would 
> list drive smart monitoring, weekly scrubs, and sysadmins with a clue.

	Every one of those things are not only necessary but absolutely 
essential.  The consequences of failing in those areas can be absolutely 
devastating.  What's more, I did not say, "...Never".  I very 
specifically said , "...Not usually".  There was a reason I did that.

>> 2. Partitioning offers no advantages.  Doing something unnecessary is 
>> questionable.  Doing something that has no purpose at all is downright 
>> foolish.
> 
> Who says it has no purpose.  Its purpose is to segment a device into 
> regions with associated metadata.

	Context, please.  If there is only one region with data then there is 
no reason for any association with or existence of any metadata.  A 
system containing only one segment needs no internal identification of 
any sort.  A universe requires no names or labels of any sort.

	A system consisting of multiple segments is a very different thing.  In 
any such system, partitioning or something similar is essential.  That 
is why my main servers all have partitioned OS arrays and 
non-partitioned data arrays.


>> 3. Partitioning introduces an additional layer of activity.  This 
>> makes it both more complex and more wasteful of resources.  And yes, 
>> before you bring it up, the additional complexity and resource 
>> infringement are quite small.  They are not zero, however, and they 
>> are in essence continuous.  Every little bit counts.
> 
> Hmm.  A sector offset and limit check, buried deep in the kernel's 
> common code.  I dare you to measure the incremental impact.

	You are assuming, there.  The kernel can most certainly be compiled 
without that code.  In fact, I have done so on embedded systems.  I 
could measure the impact, if it were an issue for me.  It isn't.  The 
simple fact is every bit of code takes time to run.  I don't need a 
quantitative measure to confirm that.  I also know the run time of the 
code is only a few msec for the first run and a few nanosec for 
subsequent runs, assuming the blocks are kept in cache somewhere.  That 
is indeed minimal.

>> 4. There is no guarantee the partitioning that works today will work 
>> tomorrow.  It should, of course, and it probably will, but why take a 
>> risk when there is absolutely no gain whatsoever?
> 
> You assert "no gain", but you provide no support for your assertion.

	That is because it is not possible to provide support for nothing.  One 
cannot prove non-existence.  If you have support for the notion there is 
some sort of gain, then by all means provide it.  Short of that, there 
is no evidence there is some gain to be had, and my statement stands. 
Believe me, my feelings are not going to be hurt by being proved wrong.

>> 5. It is additional work that ultimately yields no positive result 
>> whatsoever.  Admittedly, partitioning one disk is not a lot of work. 
>> Partitioning 50 disks is another matter.  Partitioning 500 disks...
> 
> You assert "no positive result whatsoever".  Sounds like #4.  With 
> similar lack of support.  Fluffing up your list, much?

	No, it is the cost side of the argument, which is not the same as the 
consequential side.  They are the two sides of the cost / benefit 
analysis.  In #4, I assert the benefit is negligible, perhaps even zero. 
  You haven't bothered to refute this, by the way.  In this point, I 
highlight the fact there is some cost to the practice.  Again, you have 
not refuted this.  An ad hominem reference to some alleged procedural 
failure on my part does not support your position.  Note I would be 
happy for you to do so, but don't think criticizing my abilities, 
whether accurate or not, in no way supports your position.

>> 6. Partitioning has an intent.  That intent is of no relevance 
>> whatsoever on a device whose content is singular in scope.  Are you 
>> suggesting we should also partition tapes?  Ralph Waldo Emerson had 
>> something important to say about repeatedly doing things simply 
>> because they have been done before and elsewhere.
> 
> No relevance?  Metadata can be rather useful when operating systems 
> encounter what looks like an empty disk.

	I am afraid you are going to have to be more specific for me to concede 
this point.  I am having trouble coming up with a good example.

> Metadata that says "not 
> empty!"  Especially valuable when metadata is *recognized* by all 
> operating systems.  You know, like, a *standard*.

	Please name one such case.  I cannot think of even a single protocol or 
standard that is universally recognized.  Some are close, but then only 
those that are very, very old.

> While MDraid places 
> metadata on the devices it uses, only Linux *recognizes* it.

	The logical extension of this is no system, anywhere, should ever use 
RAID of any flavor.  Nor indeed, any file system.  Nor, for that matter, 
any file system.  Indeed, we should never use any hard drive, and 
definitely not any tape drives.

>> 7. There is no downside to forfeiting the partition table.  Not 
>> needing to do something is an extremely good reason for not doing it.  
>> This is of course a corollary to point #1.
> 
> Just more fluff.

	"Just" more ad hominem.  Going down a short side path for a moment, the 
term "just" is almost always an illegitimate attempt to belittle and 
avoid an idea with the intent of being dismissive to an opponent in a 
debate.  All it really does is highlight the speaker's inability to 
properly support the speaker's side of the debate.  I would request you 
please stop "justiing" and instead provide some real support for your 
argument.  It doesn't greatly matter to me who wins this argument, but 
having to reply to unsupported rhetoric wastes my time.

> Microsoft and a number of NAS products are known to corrupt drives with 
> no partition table.

	Which is a pretty good argument to avoid those products, if true. 
Actually, I can't speak to any particular NAS (most of which are Linux 
based, and so quite unlikely to behave in such a manner), but while MS 
was accused of such activity in the past.  It was not true up to and 
including Windows 7.  I don't know about Windows 10, but I doubt it. 
Notwithstanding, I still avoid Windows whenever possible.  I certainly 
avoid doing anything merely to accommodate Windows.

> I vaguely recall hardware raid doing it, too. 
> That's a damn good reason to add a tiny (measurable?) amount of overhead.

	No, it's a damn good reason to completely avoid any such products, for 
reasons far deeper than just mucking around with partition tables. 
Mucking around the system without the express intent and direction of 
the system supervisor is not acceptable under any circumstances.  It's 
also a damn good reason why the supervisor needs to know what they are 
doing.

> And dude, making a single partition on a disk can be /scripted/.  Might 
> want to learn about that, if the pain of the driving fdisk/gdisk 
> occasionally is too much for your delicate fingers.

	It's not too much.  It's just unnecessary.  So is typing <scriptname> 
when it is not necessary.  The fact it can be scripted is irrelevant. 
You are free to do whatever you like.  I am not going to try to stop 
you.  You asked for reasons why one may chose not to partition RAID 
members.  I gave you some.  Accept them or reject them.  I don't really 
care.  Show me where my statements were factually incorrect.  I am 
always happy to learn of my mistakes.

	By the way, I don't partition non-RAID drives, either, unless they 
require multiple segments.  Not all of the media have any file systems, 
either.

  reply	other threads:[~2021-05-19 16:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  4:16 My superblocks have gone missing, can't reassemble raid5 Christopher Thomas
2021-05-17  4:23 ` Christopher Thomas
2021-05-17  6:28 ` Roman Mamedov
2021-05-17  9:30   ` Wols Lists
     [not found]   ` <CAAMCDec=H=6ceP9bKjSnsQyvmZ0LqTAYzJTDmDQoBOHSJV+hDw@mail.gmail.com>
2021-05-17 13:19     ` Roman Mamedov
2021-05-18 17:47       ` Phil Turmel
2021-05-18 18:31         ` Reindl Harald
2021-05-19 13:20           ` Leslie Rhorer
2021-05-19 13:41             ` Phil Turmel
2021-05-19 16:54               ` Leslie Rhorer [this message]
2021-05-20 19:37               ` Nix
2021-06-07  9:52                 ` Leslie Rhorer
2021-05-19 14:20             ` Andy Smith
2021-05-19 14:59               ` Leslie Rhorer
2021-05-19 14:48 ` Leslie Rhorer
2021-05-19 16:41   ` antlists
2021-05-19 17:03     ` Leslie Rhorer
2021-05-19 17:08     ` Leslie Rhorer
2021-05-19 18:00       ` Wols Lists
2021-05-19 19:01         ` Leslie Rhorer
2021-05-19 20:01           ` antlists
2021-05-19 23:45             ` Leslie Rhorer
2021-05-20 20:49               ` Nix
2021-05-21  4:07                 ` Leslie Rhorer
2021-06-07  9:55                   ` Leslie Rhorer
2021-05-20 20:48           ` Nix
2021-05-21  3:56             ` Leslie Rhorer

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=337ea246-99b0-2834-8b07-e12025d04b7d@att.net \
    --to=lesrhorer@att.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.