Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4857818imm; Tue, 26 Jun 2018 01:33:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK6+qTKG43POTPE2DboFfTTo5iCQvI0rMBwQcnq/Uy7H0wC/EYA5acYbuzR8DO6mc73PRgQ X-Received: by 2002:a65:4a10:: with SMTP id s16-v6mr526700pgq.57.1530002017219; Tue, 26 Jun 2018 01:33:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530002017; cv=none; d=google.com; s=arc-20160816; b=nHpZhCrVq6PUoJ/aFACExUtKQB0TiaxyZ2GkDgqF8i6dXWZH0uDz3qnWrvbZ36Pbpt SZokm2BuqrvzJLP286qVwplht+42R6jln5h6gn01mifteFsdpJ0F9ctHamPOGfFgzoab HoGkQkh1EM4Llre6SbhywqtIsorzJdAP68nrrAK9NggkKCtA6eBSsz0SHCWpWz6YVV16 3uVXXJ16LHVnkJkuc9Yf+DCAxB212DL13qRNe7Dc34PT3EyyVfeENknltZRDxtjUXkyy cWM5rZrGKwloOcrAdhtoY9aC/lcQjjRqp3jNLjPWoo219Xf8hzvIgrZ6PyE7lrLdkKST CxMw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject:dkim-signature:arc-authentication-results; bh=F19DCH2t1FauUiRbiWiZ8MF4FWkO1sE1hx3P6E8wEbA=; b=0EhrDlJGP/vzVowSwFRVlOIuUvsNLyS7SOJ36YwZJK0lvdtUrJEqnPIK98tPjmRAms MHIFeWYldC2B1loHvSy5mSU04w2dzqhyRMveBKHwbumND9aYwLm00dBugaZRgTJpdZrN 2ART96350XXoTQGPjQk0a7nqlOrleYrn4H0edfZfeMDL0fu320IHuM5PwYFLRF0MPaX/ JdwjRVjIj9+Ah6HvSL8mPaUBhAQ4ivrs0b+VnAyLFf2+xRI3eGkKF226Dfkyjq9cdBxk erttTpEufej83q8gn3FJqUYx6jWR8VoVk3NFtVpuvHLaPB6+ja8sFNBlPvK/atbDB/ed w6Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ECU1AhZw; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e189-v6si1205718pfe.80.2018.06.26.01.33.21; Tue, 26 Jun 2018 01:33:37 -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=pass header.i=@gmail.com header.s=20161025 header.b=ECU1AhZw; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752984AbeFZIbj (ORCPT + 99 others); Tue, 26 Jun 2018 04:31:39 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:44575 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752777AbeFZIbg (ORCPT ); Tue, 26 Jun 2018 04:31:36 -0400 Received: by mail-io0-f193.google.com with SMTP id g7-v6so15139824ioh.11; Tue, 26 Jun 2018 01:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=F19DCH2t1FauUiRbiWiZ8MF4FWkO1sE1hx3P6E8wEbA=; b=ECU1AhZwm+s8u3amqJB9op873/WKf4BAfZkbz9si8JVAGOBqNziKxl1xVQFRb3CvDa fSr8+M1jo8jYXCWov4vM0CkVW6jE2TTyfwCe2LVYvTd5ZdjrxyG+b6iDGHQy+z2UGT6I YuWfK8+HyRCaxeHIswVgs5Uq1rWhCst4dTC1UHx8XIizjY2cJQP9YU+nHgM5pW9oHUtf /lmPHmPcrwSm8rzNMeblF/+VmvR1sKtNAuZ7Sz1yVvLdsK+HcHMDaHIRNRLVqVJMkO8m 9tDuop1a913BJmbkrKvAXAqlFoORue7y4zycYbf7+8SNdDyxs8iUc9rP5bWIL7JLXAAx hcuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=F19DCH2t1FauUiRbiWiZ8MF4FWkO1sE1hx3P6E8wEbA=; b=fJP9GKd9OfXsqdXqTrwKxLfnahkjuxfliy2q4FiIpb43EWxg2+7VaEaUT5Juf95dxR vBCV4YXb5YCUTviRirrTBLCdV5xE8E4DU9ikUP3pj6Ojf3Ex1clsJjHwrA9JWiYma414 oZqTpAppZC1KmpLSUR0ZXPmGNrBy3tOqYiVNJ+C3qDojfdEOQZbywKaKBIdrjYCQ+MSk vTmqTErThXo7iSHHkyvLNA2nAAfHajAg4l0fjds63cGXJyOHcT62UOVIhMmQ7pDQvnTB Zh9tNpyQP9cOEng496N/DPjNa44kg6rIvQHXxJrcczT7mCTFAaFlyOF4i11fpvDLN+SD PmVw== X-Gm-Message-State: APt69E3lBdDRPAiE46rDVKT0AXSykcIA8YTBjt6RVe3DiqkFSzgxfqF/ BWg98kig/H5gO2lygWAaRKQ= X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr397592ioh.235.1530001895354; Tue, 26 Jun 2018 01:31:35 -0700 (PDT) Received: from Schmitz-MBP.telecom (222-154-41-72-adsl.bb.spark.co.nz. [222.154.41.72]) by smtp.googlemail.com with ESMTPSA id e63-v6sm465825ioa.85.2018.06.26.01.31.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 01:31:34 -0700 (PDT) Subject: Re: moving affs + RDB partition support to staging? To: jdow Cc: Martin Steigerwald , Geert Uytterhoeven , Matthew Wilcox , David Sterba , Linux FS Devel , Linux Kernel Mailing List , Jens Axboe , linux-m68k References: <20180425154602.GA8546@bombadil.infradead.org> <1910962.ItDVNtUG5Q@merkaba> <45e05e92-e2b1-d46c-11fb-4bd75e793712@earthlink.net> From: Michael Schmitz Message-ID: <00416cde-ddda-a9e6-f4e8-ee424b2e2a1c@gmail.com> Date: Tue, 26 Jun 2018 20:31:23 +1200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <45e05e92-e2b1-d46c-11fb-4bd75e793712@earthlink.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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