Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: jdow <jdow@earthlink.net>
To: Finn Thain <fthain@telegraphics.com.au>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Martin Steigerwald <martin@lichtvoll.de>,
	Matthew Wilcox <willy@infradead.org>,
	David Sterba <dsterba@suse.cz>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>
Subject: Re: moving affs + RDB partition support to staging?
Date: Thu, 26 Apr 2018 18:43:45 -0700
Message-ID: <0d06450e-b589-a794-9f5f-ee1c511e668c@earthlink.net> (raw)
In-Reply-To: <alpine.LNX.2.21.1804270939470.8@nippy.intranet>

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

  reply index

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 15:46 Moving unmaintained filesystems to staging Matthew Wilcox
2018-04-25 15:47 ` Christoph Hellwig
2018-04-25 20:30 ` David Sterba
2018-04-26  2:57   ` Matthew Wilcox
2018-04-26 10:28     ` moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging) Martin Steigerwald
2018-04-26 10:45       ` moving affs + RDB partition support to staging? John Paul Adrian Glaubitz
2018-04-26 10:59         ` David Sterba
2018-04-26 11:06           ` John Paul Adrian Glaubitz
2018-05-06  0:59         ` Al Viro
2018-05-06  7:40           ` Al Viro
2018-05-06 20:46             ` Al Viro
2018-05-06 20:49               ` John Paul Adrian Glaubitz
2018-05-06 21:32               ` Al Viro
2018-05-07  2:15                 ` Al Viro
2018-05-07  2:40                   ` Michael Schmitz
2018-05-07  7:08                     ` Martin Steigerwald
2018-05-07 20:50                       ` Michael Schmitz
2018-05-07 20:56                         ` Ingo Jürgensmann
2018-05-07 20:58                           ` John Paul Adrian Glaubitz
2018-05-06  8:40           ` John Paul Adrian Glaubitz
2018-05-06 10:12           ` Martin Steigerwald
2018-04-26 11:00       ` moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging) Christoph Hellwig
2018-04-26 11:08       ` Geert Uytterhoeven
2018-04-26 23:56         ` Finn Thain
2018-04-27  1:43           ` jdow [this message]
2018-04-27  1:26         ` moving affs + RDB partition support to staging? jdow
2018-05-06  8:52           ` John Paul Adrian Glaubitz
2018-05-06 10:10             ` Martin Steigerwald
2018-05-07  4:54             ` jdow
2018-04-27  2:11         ` moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging) Michael Schmitz
2018-06-24  9:06           ` Martin Steigerwald
2018-06-24 11:33             ` moving affs + RDB partition support to staging? jdow
2018-06-24 11:40             ` jdow
2018-06-26  2:23               ` Michael Schmitz
2018-06-26  5:17                 ` jdow
2018-06-26  8:12                   ` Martin Steigerwald
2018-06-26  9:46                     ` jdow
2018-06-26  8:31                   ` Michael Schmitz
2018-06-26  9:45                     ` jdow
2018-06-27  1:07                       ` Michael Schmitz
2018-06-27  6:24                         ` jdow
2018-06-27  8:03                           ` Martin Steigerwald
2018-06-28  2:57                             ` jdow
2018-06-28  7:40                               ` Amiga RDB partition support for disks >= 2 TB (was: Re: moving affs + RDB partition support to staging?) Martin Steigerwald
2018-06-27  9:00                           ` moving affs + RDB partition support to staging? Michael Schmitz
2018-06-28  3:44                             ` jdow
2018-06-28  5:43                               ` Michael Schmitz
2018-06-28  6:39                                 ` jdow
2018-06-28  8:16                                   ` Amiga RDB partition support for disks >= 2 TB (was: Re: moving affs + RDB partition support to staging?) Martin Steigerwald
2018-06-28 10:00                                     ` Amiga RDB partition support for disks >= 2 TB jdow
2018-06-28 11:30                                       ` Martin Steigerwald
2018-06-28 11:38                                         ` Martin Steigerwald
2018-06-28 12:31                                           ` jdow
2018-06-28  8:07                                 ` Amiga RDB partition support for disks >= 2 TB (was: Re: moving affs + RDB partition support to staging?) Martin Steigerwald
2018-06-27  7:57                         ` moving affs + RDB partition support to staging? Martin Steigerwald
2018-06-28  2:56                           ` jdow
2018-06-26  8:02                 ` Martin Steigerwald
2018-06-26  8:40                   ` Michael Schmitz
2018-06-26  9:31                   ` jdow
2018-06-25  7:53             ` moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging) Michael Schmitz
2018-06-25  8:26               ` Martin Steigerwald
2018-06-25  8:40               ` Geert Uytterhoeven
2018-04-27  8:01         ` Martin Steigerwald
2018-04-26  4:58   ` Moving unmaintained filesystems to staging Nikolay Borisov
2018-04-26  5:30     ` Willy Tarreau
2018-04-26  6:11 ` Pavel Machek
2018-04-26 10:36   ` Martin Steigerwald
2018-05-03  9:18     ` Pavel Machek
2018-04-27  1:10   ` Luis R. Rodriguez
2018-04-29 12:07   ` Greg KH
2018-04-29 20:07     ` Ondrej Zary
2018-04-29 23:37       ` Greg KH
2018-05-01 10:14         ` Pavel Machek

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=0d06450e-b589-a794-9f5f-ee1c511e668c@earthlink.net \
    --to=jdow@earthlink.net \
    --cc=axboe@kernel.dk \
    --cc=dsterba@suse.cz \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=martin@lichtvoll.de \
    --cc=willy@infradead.org \
    /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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git