lkml.org 
[lkml]   [2018]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: moving affs + RDB partition support to staging?
    From
    Date
    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

    \
     
     \ /
      Last update: 2018-04-27 10:50    [W:2.558 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site