From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mondschein.lichtvoll.de ([194.150.191.11]:37829 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753264AbeF0IDz (ORCPT ); Wed, 27 Jun 2018 04:03:55 -0400 From: Martin Steigerwald To: jdow Cc: Michael Schmitz , Geert Uytterhoeven , Matthew Wilcox , David Sterba , Linux FS Devel , Linux Kernel Mailing List , Jens Axboe , linux-m68k Subject: Re: moving affs + RDB partition support to staging? Date: Wed, 27 Jun 2018 10:03:51 +0200 Message-ID: <3093795.YrKfDMMbMq@merkaba> In-Reply-To: <83f7c594-b24e-69f5-03fb-3c9229d15438@earthlink.net> References: <20180425154602.GA8546@bombadil.infradead.org> <83f7c594-b24e-69f5-03fb-3c9229d15438@earthlink.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Dear Joanne. jdow - 27.06.18, 08:24: > You allergic to using a GPT solution? It will get away from some of > the evils that RDB has inherent in it because they are also features? > (Loading a filesystem or DriveInit code from RDBs is just asking for > a nearly impossible to remove malware infection.) Furthermore, any 32 > bit system that sees an RDSK block is going to try to translate it. > If you add a new RDB format you are going to get bizarre and probably > quite destructive results from the mistake. Fail safe is a rather > good notion, methinks. > > Personally I figure this is all rather surreal. 2TG of junk on an > Amiga system seems utterly outlandish to me. You cited another > overflow potential. There are at least three we've identified, I > believe. Are you 100% sure there are no more? The specific one you > mention of translating RDB to Linux has a proper solution in the RDB > reader. It should recover such overflow errors in the RDB as it can > with due care and polish. It should flag any other overflow error it > detects within the RDBs and return an error such as to leave the disk > unmounted or mounted read-only if you feel like messing up a poor > sod's backups. The simple solution is to read each of the variables > with the nominal RDB size and convert it to uint64_t before > calculating byte indices. > > However, consider my inputs as advice from an adult who has seen the > Amiga Elephant so to speak. I am not trying to assert any control. Do > as you wish; but, I would plead with you to avoid ANY chance you can > for the user to make a bonehead stupid move and lose all his > treasured disk archives. Doing otherwise is very poor form. I am pretty confident that larger than 2 TiB disks are fully supported within AmigaOS 4, as I outlined in my other mail. So with all due respect: I used a larger than 2 TiB disk in AmigaOS 4 in 2012 already *just* fine. I even found I had the same questions back then, and researched it. Which lead to this official article back then: http://wiki.amigaos.net/wiki/RDB I am also pretty sure that AmigaOS still uses RDB as partitioning format. They support MBR. I don�t think AmigaOS 4.1 supports GPT. Whether to implement that of course is the decision of AmigaOS 4 development team. I am no longer a member of it since some time. Linux m68k should already be able to use disks in GPT format, but you likely won�t be able to read them in AmigaOS, unless there is some third party support for it meanwhile. Thanks, Martin > > {o.o} Joanne "Said enough, she has" Dow > > On 20180626 18:07, Michael Schmitz wrote: > > Joanne, > > > > As far as I have been able to test, the change is backwards > > compatible (RDB partitions from an old disk 80 GB disk are still > > recognized OK). That"s only been done on an emulator though. > > > > Your advice about the dangers of using RDB disks that would have > > failed the current Linux RDB parser on legacy 32 bit systems is well > > taken though. Maybe Martin can clarify that for me - was the 2 TB > > disk in question ever used on a 32 bit Amiga system? > > > > RDB disk format is meant for legacy use only, so I think we can get > > away with printing a big fat warning during boot, advising the user > > that the oversize RDB partition(s) scanned are not compatible with > > legacy 32 bit AmigaOS. With the proposed fix they will work under > > both AmigaOS 4.1 and Linux instead of truncating the first > > overflowing partition at disk end and trashing valid partitions > > that overlap, which is what Martin was after. > > > > If that still seems too risky, we can make the default behaviour to > > bail out once a potential overflow is detected, and allow the user > > to > > override that through a boot parameter. I'd leave that decision up > > for the code review on linux-block. > > > > Two more comments: Linux uses 512 byte block sizes for the partition > > start and size calculations, so a change of the RDB blocksize to > > reduce the block counts stored in the RDB would still result in the > > same overflow. And amiga-fdisk is indeed utterly broken and needs > > updating (along with probably most legacy m68k partitioners). Adrian > > has advertised parted as replacement for the old tools - maybe this > > would make a nice test case for parted? > > > > Cheers, > > > > Michael > > > > On Tue, Jun 26, 2018 at 9:45 PM, jdow wrote: > >> If it is not backwards compatible I for one would refuse to use it. > >> And if it still mattered that much to me I'd also generate a > >> reasonable alternative. Modifying RDBs nay not be even an > >> approximation of a good idea. You'd discover that as soon as an > >> RDB uint64_t disk is tasted by a uint32_t only system. If it is > >> for your personal use then you're entirely free to reject my > >> advice and are probably smart enough to keep it working for > >> yourself. > >> > >> GPT is probably the right way to go. Preserve the ability to read > >> RDBs for legacy disks only. > >> > >> {^_^} > >> > >> On 20180626 01:31, Michael Schmitz wrote: > >>> Joanne, > >>> > >>> I think we all agree that doing 32 bit calculations on 512-byte > >>> block > >>> addresses that overflow on disks 2 TB and larger is a bug, causing > >>> the issues Martin reported. Your patch addresses that by using > >>> the correct data type for the calculations (as do other partition > >>> parsers that may have to deal with large disks) and fixes > >>> Martin's bug, so appears to be the right thing to do. > >>> > >>> Using 64 bit data types for disks smaller than 2 TB where > >>> calculations don't currently overflow is not expected to cause > >>> new issues, other than enabling use of disk and partitions larger > >>> than 2 TB (which may have ramifications with filesystems on these > >>> partitions). So comptibility is preserved. > >>> > >>> Forcing larger block sizes might be a good strategy to avoid > >>> overflow > >>> issues in filesystems as well, but I can't see how the block size > >>> stored in the RDB would enforce use of the same block size in > >>> filesystems. We'll have to rely on the filesystem tools to get > >>> that right, too. Linux AFFS does allow block sizes up to 4k (VFS > >>> limitation) so this should allow partitions larger than 2 TB to > >>> work already (but I suspect Al Viro may have found a few issues > >>> when he looked at the AFFS code so I won't say more). Anyway > >>> partitioning tools and filesystems are unrelated to the Linux > >>> partition parser code which is all we aim to fix in this patch. > >>> > >>> If you feel strongly about unknown ramifications of any > >>> filesystems on partitions larger than 2 TB, say so and I'll have > >>> the kernel print a warning about these partitions. > >>> > >>> I'll get this patch tested on Martin's test case image as well as > >>> on a RDB image from a disk known to currently work under Linux > >>> (thanks Geert for the losetup hint). Can't do much more without > >>> procuring a working Amiga disk image to use with an emulator, > >>> sorry. The Amiga I plan to use for tests is a long way away from > >>> my home indeed. > >>> > >>> Cheers, > >>> > >>> Michael > >>> > >>> Am 26.06.18 um 17:17 schrieb jdow: > >>>> As long as it preserves compatibility it should be OK, I suppose. > >>>> Personally I'd make any partitioning tool front end gently force > >>>> the > >>>> block size towards 8k as the disk size gets larger. The file > >>>> systems > >>>> may also run into 2TB issues that are not obvious. An unused > >>>> blocks > >>>> list will have to go beyond a uint32_t size, for example. But a > >>>> block > >>>> list (OFS for sure, don't remember for the newer AFS) uses a tad > >>>> under 1% of the disk all by itself. A block bitmap is not quite > >>>> so bad. {^_-} > >>>> > >>>> Just be sure you are aware of all the ramifications when you make > >>>> a > >>>> change. I remember thinking about this for awhile and then > >>>> determining I REALLY did not want to think about it as my brain > >>>> was getting tied into a gordian knot. > >>>> > >>>> {^_^} > >>>> > >>>> On 20180625 19:23, Michael Schmitz wrote: > >>>>> Joanne, > >>>>> > >>>>> Martin's boot log (including your patch) says: > >>>>> > >>>>> Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) > >>>>> sdb1 > >>>>> (LNX^@)(res 2 spb 1) sdb2 (JXF^D)(res 2 spb 1) sdb3 (DOS^C)(res > >>>>> 2 spb > >>>>> 4) > >>>>> Jun 19 21:19:09 merkaba kernel: [ 7891.844055] sd 7:0:0:0: [sdb] > >>>>> Attached SCSI disk > >>>>> > >>>>> so it's indeed a case of self inflicted damage (RDSK (512) means > >>>>> 512 > >>>>> byte blocks) and can be worked around by using a different block > >>>>> size. > >>>>> > >>>>> Your memory serves right indeed - blocksize is in 512 bytes > >>>>> units. > >>>>> I'll still submit a patch to Jens anyway as this may bite others > >>>>> yet. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Michael > >>>>> > >>>>> On Sun, Jun 24, 2018 at 11:40 PM, jdow wrote: > >>>>>> BTW - anybody who uses 512 byte blocks with an Amiga file > >>>>>> system is > >>>>>> a famn > >>>>>> dool. > >>>>>> > >>>>>> If memory serves the RDBs think in blocks rather than bytes so > >>>>>> it > >>>>>> should > >>>>>> work up to 2 gigablocks whatever your block size is. 512 blocks > >>>>>> is > >>>>>> 2199023255552 bytes. But that wastes just a WHOLE LOT of disk > >>>>>> in > >>>>>> block maps. > >>>>>> Go up to 4096 or 8192. The latter is 35 TB. > >>>>>> > >>>>>> {^_^} > >>>>>> > >>>>>> On 20180624 02:06, Martin Steigerwald wrote: > >>>>>>> Hi. > >>>>>>> > >>>>>>> Michael Schmitz - 27.04.18, 04:11: > >>>>>>>> test results at > >>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=43511 > >>>>>>>> indicate the RDB parser bug is fixed by the patch given > >>>>>>>> there, so if > >>>>>>>> Martin now submits the patch, all should be well? > >>>>>>> > >>>>>>> Ok, better be honest than having anyone waiting for it: > >>>>>>> > >>>>>>> I do not care enough about this, in order to motivate myself > >>>>>>> preparing the a patch from Joanne Dow�s fix. > >>>>>>> > >>>>>>> I am not even using my Amiga boxes anymore, not even the > >>>>>>> Sam440ep > >>>>>>> which > >>>>>>> I still have in my apartment. > >>>>>>> > >>>>>>> So RDB support in Linux it remains broken for disks larger 2 > >>>>>>> TB, > >>>>>>> unless > >>>>>>> someone else does. > >>>>>>> > >>>>>>> Thanks. > >>>>>> > >>>>>> -- > >>>>>> To unsubscribe from this list: send the line "unsubscribe > >>>>>> linux-m68k" 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-m68k" 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-m68k" in the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Martin