Received: by 10.192.165.148 with SMTP id m20csp1915506imm; Thu, 26 Apr 2018 04:10:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3XA+bOEpuDt+KHiqa7iumU2l2g0KxLFS9cryoSD6wF0P63ISRrLM+9+5z6euY9znNJhEE X-Received: by 10.99.65.197 with SMTP id o188mr9473194pga.280.1524741006653; Thu, 26 Apr 2018 04:10:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524741006; cv=none; d=google.com; s=arc-20160816; b=uJqNuSc6KiNwiaiaUd649qSzZ/aZgn1RyLL60DRI44FtTuH0VRhuT7lWHqrOqOnnn5 vFYl/TWQ54mS0J7T9DDXJJJtlXUEfRDcpZ+arwUm1/df5VipP+IfRwJDRnsD+eGrh31R FoVxZ5drCrEplhUGa1I+QIscCZ4JN6i+2KHr44ROjADUhNjdIEi6x+Bl83l/sapWet4i y8SyKVvcPcjwc7NMmjTRU/f8ozs2m2zTvEd8luenUe/WNic9zCLDm2RWe4ShXFSFbB9g c/ZhsPixdagqpYpn7qrPBHTKdWZ62dJYwKhIZoKELKnsV2qKKUV2u4MZWxkHKHW02yxO 1oDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=GqbXY9RY2cu/fa04CRIbeEb2wQ9GBY7gum95OIEwS2I=; b=uIUUcnIxMKvKy2F717lZVeo6k9CtEpYcLJCAZVcI811D9kOk7mq1JXDvox4AmdpPQw WtSYKMT/ZFm6g+Dr5ur4akQNPzn0NrwQu1EfzhSSU8O3gnB2OmKfyIzChBlHExQTrwEs 1b1edavbiTLHjbCzu/7RT2fqs/5ArNfHjl+eKtCiNx0+VtrcMupa+WcQKuyUJQdWZadb qshcTj50SR9OyFhjUo34gDleNXayqE4kWwCK6+5wWF6Jruv06L+lTfjMuoILrwqrHnWN FDtA2EHHZXMOeuMhczVShdDLyxvlqbWNEukNTaUZ7mdzrhb987KLOKmBUQiNhAfuEPEG ne6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Lpul9+cD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q14-v6si17778326pls.286.2018.04.26.04.09.52; Thu, 26 Apr 2018 04:10:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Lpul9+cD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754862AbeDZLIq (ORCPT + 99 others); Thu, 26 Apr 2018 07:08:46 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:41152 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754094AbeDZLIn (ORCPT ); Thu, 26 Apr 2018 07:08:43 -0400 Received: by mail-vk0-f67.google.com with SMTP id 131so10993519vkf.8; Thu, 26 Apr 2018 04:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=GqbXY9RY2cu/fa04CRIbeEb2wQ9GBY7gum95OIEwS2I=; b=Lpul9+cDRsqvAa/zmdAcP+NwlY7uzh6jOko9R+0x6pBBBSH9MSkm/2V2IXcN8RLhmE lxZji2/0/PXx/tBMFGIaRLvq5/M7A/NMEJh0SdSlV3/y3jsy6oY2Ak50CHF57ejbcoYx ZVBxMYU8p6VTAhmyBHz9X9AbClNzzco+ng17/NjUSUYhryIgTvnxWiR/6WQ1Q51ZnSPd CYyNj+eU6cUuv1KkhxZUztNYNJPLypXmF+8p8Y+qD2edXXO/yJ/TdpjDEf1r/J7SLcg+ M+xE/FG5lLPf3qeD4kbNMOr8IGe1v+VmLkwnpomiCWMg5ok33bUG997wOhLuRVicvaad XK6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=GqbXY9RY2cu/fa04CRIbeEb2wQ9GBY7gum95OIEwS2I=; b=fLf7eWDc2zcZsG6qtIbnD3eLJ6oUJ/eCtsjgrFniNbWbLrkNU7OyaHq1ZA3mPNKdvX WWpRQRQqJaIIQmAFO88B1DV+KVvlnj9s0Y/ii7viKyFV96JsTR/GuGZ50v5t0Ew3QvGd PG2b9nxc4rv9GP4e0fZPwHimALcP5DLmm4aA790TsTbKcIf14V6sS4LRrf2Me1glZxk7 NJtDknpVV9b7M69oBwrdceBFFIh2S2/CNqIimIv/bF9PUq416KeuvSoSpChIiyczc0mi 0QtgIMP7RSwElNXmAHlD3jN7OuhOYWDm0M6yoGPqaH4+uW2COF039WhC7nf7hN98rBZr QuvQ== X-Gm-Message-State: ALQs6tBtN6j05T5M3NZL+HroyI31dJVEyOkCj3kmTcLv64sArpWXv83R jKwBzcDGMv3ZCxKR24pvufBDsMXkNborAh7XJKM= X-Received: by 10.31.55.10 with SMTP id e10mr22821158vka.106.1524740922492; Thu, 26 Apr 2018 04:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.122.68 with HTTP; Thu, 26 Apr 2018 04:08:41 -0700 (PDT) In-Reply-To: <1613268.lKBQxPXt8J@merkaba> References: <20180425154602.GA8546@bombadil.infradead.org> <20180425203029.GQ21272@twin.jikos.cz> <20180426025717.GA32430@bombadil.infradead.org> <1613268.lKBQxPXt8J@merkaba> From: Geert Uytterhoeven Date: Thu, 26 Apr 2018 13:08:41 +0200 X-Google-Sender-Auth: BQCAAFo7wuVYXuiPlDrH_p9ZnZM Message-ID: Subject: Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging) To: Martin Steigerwald Cc: Matthew Wilcox , David Sterba , Linux FS Devel , Linux Kernel Mailing List , Jens Axboe , linux-m68k , Joanne Dow Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Martin, CC jdow On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald wrote: > You probably put your stick into a cave with ancient sleeping dragons :) > > Added in linux-m68k mailing list, as they likely have an opinion on how > to treat affs + RDB partition support. Also added in Jens Axboe about > patching that RDB support broken with 2 TB or larger harddisks issue > which had been in Linux kernel for 6 years while a patch exists that to > my testing back then solves the issue. While non-native Linux filesystem support (e.g. affs/isofs/...) could be handled by FUSE, moving RDB partition support to staging is not an option, as it is the only partitioning scheme that Amigas can boot from. If there are bugs in the RDB parser that people run into, they should be fixed. If there are limitations in the RDB format on large disks, that's still not a reason to move it to staging (hi msdos partitioning!). > Matthew Wilcox - 26.04.18, 04:57: >> On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote: >> > I had similar toughts some time ago while browsing the fs/ >> > directory. >> > Access to the filesystem images can be reimplemented in FUSE, but >> > other than that, I don't think the in-kernel code would be missed. >> > >> > It's hard to know how many users are there. I was curious eg. about >> > bfs, befs, coda or feevxfs, looked at the last commits and searched >> > around web if there are any mentions or user community. But as long >> > as there's somebody listed in MAINTAINERS, the above are not >> > candidates for moving to staging or deletion. >> >> Yeah, it's pretty sad how few commits some of these filesystems have >> had in recent years. One can argue that they're stable and don't need >> to be fixed because they aren't broken, but I find it hard to believe >> that any of them were better-implemented than ext2 which still sees >> regular bugfixes. > > Regarding affs there is a severe issue which is not in affs itself but > in the handling of Rigid Disk Block (RDB) partitions, the Amiga > partitioning standard, which is far more advanced than MBR: It overruns > for 2 TB or larger drives and then wraps over to the beginning of the > drive =E2=80=93 I bet you can imagine what happens if you write to an are= a > larger than 2 TB. I learned this with an external 2TB RDB partitioned > harddisk back then, which I used for Sam440ep (a kind of successor for > old, classic Amiga hardware) backup + some Linux related stuff in > another partition. > > Joanne Dow, a developer who developed hdwrench.library which HDToolBox > uses for partitioning in AmigaOS 3.5/3.9, provided a patch back then, > but never officially put it officially through upstreaming as I offered > to make a good description and upstream it through Jens Axboe. > > I may take this as a reason to=E2=80=A6 actually follow through this time= , > hopefully remembering all the details in order to provide a meaningful > patch description =E2=80=93 but I think mostly I can do just careful copy= and > paste. Even tough I believe Joanne Dow=C2=B4s fix only fixed my bug repor= t > 43511, but not 43511 which is more about a safeguarding issue in case of > future overflows, I still think it would be good to go in in case affs + > RDB stays in their current places. > > However, in case you move affs to staging, I may be less motivated to do > so, but then I suggest you also move RDB partitioning support to > staging, cause this is the one that is known to be dangerously badly for > 2 TB or larger disks. And yeah, I admit I did not follow through with > having that patch upstreamed. Probably I did not want to be responsible > in case my description would not have been absolutely accurate or the > patch breaks something else. I do not have that 2 TB drive anymore and > don=C2=B4t feel like setting one up in a suitable way in order to go abou= t > this patch, but my testing back then was quite elaborate and I still > feel pretty confident about it. > > I totally get your motivation, but I would find it somewhat sad to see > the filesystems you mentioned go into staging. However, as I just shown > clearly, for the user it may be better, cause there may be unfixed > dangerous bugs. FUSE might be an interesting approach, but I bet it will > not solve the maintenance issue. If there is no one maintaining it in > the kernel, I think its unlikely to find someone adapting it to be a > FUSE filesystem and maintaining it. And then I am not aware of FUSE > based partitioning support. (And I think think ideally we=C2=B4d had a > microkernel and run all filesystems in userspace processes with a > defined set of privileges, but that is simply not Linux as it is.) > > Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in > AmigaOS 4.1 > https://lkml.org/lkml/2012/6/17/6 > > Bug 43521 - Amiga RDB partitions: truncates miscalculated partition size > instead of refusing to use it > https://bugzilla.kernel.org/show_bug.cgi?id=3D43521 > > Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way too big, > while OK in AmigaOS 4.1 > https://bugzilla.kernel.org/show_bug.cgi?id=3D43511 > > I forward the relevant mail of Joanne, in > > https://bugzilla.kernel.org/show_bug.cgi?id=3D43511#c7 > > I even have the patch in diff format. And I just checked, the issue is > still unpatched as of 4.16.3. > > ---------- Weitergeleitete Nachricht ---------- > > Betreff: Re: Partitions: Amiga RDB partition on 2 TB disk way too big, > while OK in AmigaOS 4.1 > Datum: Montag, 18. Juni 2012, 03:28:48 CEST > Von: jdow > An: Martin Steigerwald > Kopie: Geert Uytterhoeven , linux- > kernel@vger.kernel.org, Jens Axboe , linux- > m68k@vger.kernel.org > > On 2012/06/17 14:20, Martin Steigerwald wrote: >> Am Sonntag, 17. Juni 2012 schrieb jdow: >>> On 2012/06/17 09:36, Geert Uytterhoeven wrote: >>>> On Sun, Jun 17, 2012 at 2:58 PM, Martin Steigerwald >> wrote: >>>>> Am Sonntag, 17. Juni 2012 schrieb jdow: >>>>> | JXFS 64 bit file system >>>>> | >>>>> | With AmigaOS 4.x a new file system has been introduced called >>>>> | JXFS. It is a totally new 64 bit file system that supports >>>>> | partitions up to 16 TB in size. It is a modern journalling file >>>>> | system, which means that it reduces data loss if data writes to >>>>> | the disk are interrupted. It is the fastest and most reliable >>>>> | file system ever created for AmigaOS. >>>>> >>>>> http://www.amigaos.net/content/1/features >>>>> >>>>> Well I asked AmigaOS 4 developers about this issue as well. Lets > see >>>>> what they say about 2 TB limits. >>>> >>>> 16 TB =3D 2 TB * 8. Perhaps they increased the block size from 512 to >>>> 4096? >>>> >>>> block/partitions/amiga.c reads the block size from >>>> RigidDiskBlock.rdb_BlockBytes, >>>> but after conversion to 512-byte blocks, all further calculations > are >>>> done on "int", so it will overflow for disks larger than 2 TiB. >>>> >>>> Note that in your profile-binary.img, the field is 0x200, i.e. 512 >>>> bytes per block, >>>> so I'll have to get a deeper look into your RDB first... >> [=E2=80=A6] >>> Note that the work I did on the Linux RDB code eons ago took full >>> cognizance of the physical and virtual block sizes. >> [=E2=80=A6] >>> I've asked Martin for a digital copy of his RDBs and what he thinks > the >>> partition(s) should look like. I should also be told whether the disk >>> is supposed to be solely Amiga OSs or not. I gather it's not. >> >> Its all in the bug report. profile-binary.img should be it. >> >> Its small so I attach it. >> >> Meanwhile I try to get the currently supported maximum disk size out > from >> the OS 4 developers. Maybe JXFS is playing tricks that other > filesystems do >> not play or simply has a different implementation. >> >> Thanks, > > I've sent Jens a proposed fix changing these lines in amiga.c. > =3D=3D=3D8<--- was > struct PartitionBlock *pb; > int start_sect, nr_sects, blk, part, res =3D 0; > int blksize =3D 1; /* Multiplier for disk block size */ > =3D=3D=3D8<--- becomes changing line 338 into lines 338-339 > struct PartitionBlock *pb; > sector_t start_sect, nr_sects; > int blk, part, res =3D 0; > int blksize =3D 1; /* Multiplier for disk block size */ > =3D=3D=3D8<--- > > (I'm working without proper tools at the moment or I'd make a real diff. > Sorry.) > > This fix may not be complete. The RDBs contain provisions for describing > the physical disk block size and how many physical blocks are used in a > file system's logical blocks. This MAY not work quite right large > physical > block sizes. > > {^_^} Joanne Dow > -- > 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 > > ------------------------------------------------------------- > [=E2=80=A6] > >> As long as there's someone who can be pestered with bugs, I don't see >> the need to push their baby out of the tree. I'm a bit more nervous >> about hfsplus; if it has users and no maintainer, those users are at >> risk. >> >> Perhaps we could advertise on Craigslist or something ... maintainer >> wanted for LTR. Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds