public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Jens Axboe <axboe@kernel.dk>, jdow <jdow@earthlink.net>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	linux-block@vger.kernel.org
Subject: Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB
Date: Fri, 29 Jun 2018 23:24:36 +0200	[thread overview]
Message-ID: <2499668.52U9LxLmUp@merkaba> (raw)
In-Reply-To: <76bf5b8d-6ee1-8e77-4c2a-e0b5a095992b@gmail.com>

Hi Michael.

Michael Schmitz - 29.06.18, 11:07:
> > But it's up to the person (which is not Linux) formatting the disk
> > to
> > not try to use
> > it on systems that cannot handle it, and may destroy it.
> >=20
> >>> Let me clarify: what exactly would the kernel option allow? When
> >>> to use it?>>=20
> >> Whether to use it if safe (on Linux). But whatever Linux does
> >> (after
> >> this patch), access will go to the right area of the disk (as
> >> specified by the RDB) so Linux won't any longer stomp on anything
> >> that would have mattered to 32 bit disk drivers. So it really
> >> should be safe.>=20
> > Personally, I see no reason to depend on a kernel option, if it is
> > safe to use. Just use it.
>=20
> So to recap - someone partitions a disk on AmigaOS 4.x, taking
> advantage of the large block device support there.
> Using that disk on AmigaOS 3.1, data loss ensues. Whether or not Linux
> (patched) ever touched the disk has no impact on that outcome.

I am not even completely sure about that. Frankly I have no idea what=20
would happen when using such a disk on AmigaOS 3.1 *without* NSDPatch or=20
TD64 support (I think you could patch AmigaOS 3.1 with 64 Bit support=20
already and some 3rd party harddisk controllers by Phase 5 hat TD64=20
support at that time already). Unless I try it, which I won=C2=B4t at the=20
moment, I=C2=B4d say the behaviour is largely undefined.

But hey, undefined means it may just overwrite start overwriting from=20
the beginning of the disk beyond 32 bit. And I think that is quite=20
likely. It could also crash, but if its an overflow I don=C2=B4t think why =
it=20
would crash. Anyway, I never tried this out.

But in any way: This would happen or not happen no matter whether Linux=20
parsed the RDB or not.

I still think that the native OS warning really does not hurt=E2=80=A6 but =
I=C2=B4d=20
spare myself the kernel option. Having the warning without the kernel=20
option would be a compromise between being cautious and being bold :).

Thanks,
=2D-=20
Martin

  parent reply	other threads:[~2018-06-29 21:24 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27  1:24 Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB schmitzmic
2018-06-27  8:13 ` Martin Steigerwald
2018-06-28  3:23   ` jdow
2018-06-27  8:24 ` Martin Steigerwald
2018-06-27 20:13   ` Michael Schmitz
2018-06-27 21:20     ` Martin Steigerwald
2018-06-28  3:48       ` jdow
2018-06-28  4:58       ` Michael Schmitz
2018-06-28  6:45         ` Geert Uytterhoeven
2018-06-28  7:13           ` Martin Steigerwald
2018-06-28  9:25             ` Geert Uytterhoeven
2018-06-29  8:42               ` Michael Schmitz
2018-06-29  8:51                 ` Geert Uytterhoeven
2018-06-29  9:07                   ` Michael Schmitz
2018-06-29  9:12                     ` Geert Uytterhoeven
2018-06-29  9:25                       ` Michael Schmitz
2018-06-29 21:24                     ` Martin Steigerwald [this message]
2018-06-29 23:24                       ` Michael Schmitz
2018-06-30  0:49                         ` jdow
2018-06-29 21:17                   ` Martin Steigerwald
2018-06-29  9:32                 ` jdow
2018-06-29 21:45                   ` Martin Steigerwald
2018-06-29 23:24                     ` jdow
2018-06-30  0:44                       ` Michael Schmitz
2018-06-30  0:57                         ` jdow
2018-06-30  1:31                           ` Michael Schmitz
2018-06-30  3:56                             ` jdow
2018-06-30  5:26                               ` Michael Schmitz
2018-06-30  6:47                                 ` jdow
2018-06-30  9:07                                   ` Martin Steigerwald
2018-06-30  9:39                                     ` jdow
2018-06-30  8:48                                 ` Martin Steigerwald
2018-06-30  9:28                                   ` jdow
2018-06-30  7:49                               ` Martin Steigerwald
2018-06-30  9:36                                 ` jdow
2018-07-01  2:43                                 ` Michael Schmitz
2018-07-01  4:36                                   ` jdow
2018-07-01 12:26                                   ` Martin Steigerwald
2018-06-29 12:44                 ` Andreas Schwab
2018-06-30 21:21                   ` Geert Uytterhoeven
2018-06-29 21:10                 ` Martin Steigerwald
2018-06-28  9:20           ` jdow
2018-06-28  9:29             ` Geert Uytterhoeven
2018-06-29  8:58           ` Michael Schmitz
2018-06-29  9:10             ` Geert Uytterhoeven
2018-06-29  9:19               ` Michael Schmitz
2018-06-28  7:28         ` Martin Steigerwald
2018-06-28  7:39           ` Geert Uytterhoeven
2018-06-28  9:34             ` jdow
2018-06-28  3:49   ` jdow
2018-06-27 13:30 ` Geert Uytterhoeven
2018-06-27 20:43   ` Michael Schmitz
2018-06-28  3:45   ` jdow
2018-06-29  9:12   ` Michael Schmitz
2018-06-30 21:10     ` Geert Uytterhoeven
2018-06-30 21:26       ` Michael Schmitz
2018-07-02  5:29 ` [PATCH] block: fix Amiga partition support for disks >= 1 TB Michael Schmitz
2018-07-02  6:38   ` Kars de Jong
2018-07-02 22:34     ` Michael Schmitz
2018-07-02  8:29   ` Geert Uytterhoeven
2018-07-02 23:58     ` Michael Schmitz
2018-07-03  7:22       ` Geert Uytterhoeven
2018-07-03  8:15         ` Michael Schmitz
2018-07-03 10:02         ` jdow
2018-07-02 19:36   ` Martin Steigerwald
2018-07-02 19:39     ` Martin Steigerwald
2018-07-03  7:19   ` [PATCH v2] " Michael Schmitz
2018-07-03 19:39   ` [PATCH v3] " Michael Schmitz

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=2499668.52U9LxLmUp@merkaba \
    --to=martin@lichtvoll.de \
    --cc=axboe@kernel.dk \
    --cc=geert@linux-m68k.org \
    --cc=jdow@earthlink.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=schmitzmic@gmail.com \
    /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