Received: by 10.192.165.148 with SMTP id m20csp460353imm; Fri, 27 Apr 2018 01:51:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpqenRPl1NPbzCg2Hd//buUXGVVr5BtHYrkuxQ5Ak+aGGMlvtstnbruqu8q5EhU9tz3PADD X-Received: by 10.98.166.206 with SMTP id r75mr1448344pfl.82.1524819092813; Fri, 27 Apr 2018 01:51:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524819092; cv=none; d=google.com; s=arc-20160816; b=k76tHNmCodx4sZgp2+0hdwHWbdi0QXtRVJxfNYHwYk0IBEadmIX9RpV0vmCPfQKA7J XzlpjIeoByb+DVWfUqMSlJLH2Pcq8sy29qJMW7cnMhctRL0XzA5/CvLFooxeHUmZyISy qR7lneHvV6wElj1NKdKHQFs/17IpU0jxH0188jeJmPYWDSaTH2CxlOMjghHis5lAq4tw YrkE/O6PUUeF65ZKbEcl8G4aC4PWrMhMuHklS6s2Czfu4speg37ElIi7Ckjo3y+rH24g Q3ZcshUekWTdhJLoJGz8/9zPIE1AuZ+SfIotExq6J3+nbJg9aRrJXfibCJOuQrA0G+sO OJ0A== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:domainkey-signature :dkim-signature:arc-authentication-results; bh=7NoMcOiQ8RmxIT1NdLTDybq5I0dONkzpnGtO0uyq+xQ=; b=Gk4xDPaAv1+C5lyWuGFoTG6m1qZ49DvGfyDXqCakGbKekznOKvM4ttVEzSjvZOAdOu VAFukJYIsRGV6l9obyTTUWDoaNZdXeU9Hj52Yu5CwDEEljyIkLeD4Tr3C0hS44Q1fSHz YgdRlOwv1X19MINPOTrr5KGcS6FIjQPs6DFyL59oOdz6XLN/Lkioi2mQ4HWfCFO6/vzj 1ob2CKHD643R16S+5EkxMLK8qoJGShmwFld1MGwxnP/ksLv6h/12COhEDOpsbdb0iuBc zbnvz81Yel46pDFKIHBFVdERN+S3L42Ol2C42fWostNK6rAsi8u5P3/BrrSKLDOXm1N7 3vNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@earthlink.net header.s=dk12062016 header.b=q7fDpFQg; 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=NONE dis=NONE) header.from=earthlink.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g14-v6si795768pgv.648.2018.04.27.01.51.18; Fri, 27 Apr 2018 01:51:32 -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=@earthlink.net header.s=dk12062016 header.b=q7fDpFQg; 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=NONE dis=NONE) header.from=earthlink.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932403AbeD0IuG (ORCPT + 99 others); Fri, 27 Apr 2018 04:50:06 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]:44810 "EHLO elasmtp-dupuy.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932366AbeD0IuD (ORCPT ); Fri, 27 Apr 2018 04:50:03 -0400 X-Greylist: delayed 20318 seconds by postgrey-1.27 at vger.kernel.org; Fri, 27 Apr 2018 04:50:02 EDT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1524819003; bh=7NoMcOiQ8RmxIT1NdLTDybq5I0dONkzpnGtO 0uyq+xQ=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=q7fDpFQ gM2U+GL4QQ6ymr/RazyiCk5JVDGpn/GBk+AySv11Odbspgt9hjtKsK3e13J6ES4eJ1q 0xNFXibf7lrnrtTjjlFxqtBBs8sWVv0Aj4SHN+fufCq+fGGxhBdycQXb3vJWIyRVLOi Dx6Q6evNDbKyB5Q+3bZjmZ2znlU4wzSYZTJ5Tex7AHEGaCbAIirTwzny+B3Lqc+8i53 Irk/WyqVC3isbfjsei4PJnXRv+dirBKXPDn2DaShRDIQGvhzx/b56gjydwGxtwYIKiL NkbQeMiVVDyM3IJgLQuYQXH9eb4Q777JsAm/vkPsBYP+qPC+F/kWfydshDaizD5QaUw == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=iPPS/S1G0DUg1ghwhBw3qTQMQIGaotSzbX5E8d+z1yJhTREN1GVtRVOxMehhcdWeom4VN1aYGupFbkxxnIYbYy54NXDSJhMfPO7kFcqB+UFkyuRa4X8tj5MmJvGnrE4UIadcPf86TkGFXrlfMynONXJqfgKqg4D0Na2Tb3n1JI70y43kX7eIrgT5c/ntxJnmJxNRXxU1IcuHXAlsK8d2PdLHcsj06G1e3QPl4KTSQMXCy9z6BHO5wgwHZqh4gzm6DZhJndZIE+pnJ+Wp281W3jHy2ZbyCHUUdWAmfSXxMoBSnCMHDNcPW1XnZzsGL2L4VEvKPoiQLlGc4KbikLSf1Q==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.183.100.23] (helo=[192.168.37.199]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1fBsQN-000EoV-OR; Thu, 26 Apr 2018 21:43:47 -0400 Subject: Re: moving affs + RDB partition support to staging? To: Finn Thain , Geert Uytterhoeven Cc: Martin Steigerwald , Matthew Wilcox , David Sterba , Linux FS Devel , Linux Kernel Mailing List , Jens Axboe , linux-m68k References: <20180425154602.GA8546@bombadil.infradead.org> <20180425203029.GQ21272@twin.jikos.cz> <20180426025717.GA32430@bombadil.infradead.org> <1613268.lKBQxPXt8J@merkaba> From: jdow Message-ID: <0d06450e-b589-a794-9f5f-ee1c511e668c@earthlink.net> Date: Thu, 26 Apr 2018 18:43:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ELNK-Trace: bb89ecdb26a8f9f24d2b10475b57112003f01058fceb61e7e311c192ab679a963f4ab28b94bf857b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.183.100.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20180426 16:56, Finn Thain wrote: > On Thu, 26 Apr 2018, Geert Uytterhoeven wrote: > >> >> While non-native Linux filesystem support (e.g. affs/isofs/...) could be >> handled by FUSE > > Moving to FUSE is a great divide-and-conquer strategy for those who just > want the code to die and don't care about any of the data in that format. > > If there is a maintainence burden that can be shared then it should be > shared -- until it can be established that there is no data of value in > that format. > >> moving RDB partition support to staging is not an option, as it is the >> only partitioning scheme that Amigas can boot from. >> > > Whether or not the original hardware is in use is mostly irrelevant. > > As long as the old format is accessible using current hardware, the data > in that format remains accessible (to archivists, to curators, to your > decendents, etc). > >> 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!). >> This intrepid cyberunit is inclined to suggest that understanding the RDBs can go a long way towards defining if there is a bug somewhere and whether it is in the RDB description or its misuse. There are some things RDBs can do that REALLY REALLY don't make sense until you run across the situation which called for it creation. There are two variables that suggest some blocks at the beginning and the end, respectively, of a partition are not accessible by the OS. I have used these facilities to "interleave" partitions and RDBs. I have built a disk which reserved about 128 512 byte blocks for RDBs plus filesystem code (which probably should be abandoned) which embedded the RDBs describing the partition within the partition. Then I reserved space at the end of the partition and embedded a second partition in that space. As absurd as it sounds this had at one time a decent use case. Disk space was an expensive premium in those days so wasting space to get nice integer numbers in the disk description, which was phony for a hard disk in any case, we allowed any numbers and if that went past the end of the disk we reserved the necessary space so that it would never be used. The space at the beginning of a partition was needed in any case because a one block partition signature needed space at the start of the partition. It held the filesystem's signature, OFS, AFS, SFS, etc. There is also a good reason for allowing the anchor for the RDBs to start in any of the first 16 blocks with a recommendation not to use block 0 as other FSs used that. And we wanted to accommodate at least two different partition description technologies to work on the disk. My code always placed the RDBs at block 3. I hope passing along some of this history will mitigate some fo the feelings that RDBs are inherently flawed or full of bugs or whatnot. (Full pf security holes is another story. DriveInit code and filesystem code have worried me from day one.) {^_^} Joanne