I'll have to make time to look it over, considering I am more or less
the mommy of the RDBs. Now, 2TB may be a tad beyond the abilities of
the RDBs to express. Memory insists that the RDBs worked on either
BYTE or block counts. Your seeing a problem at 2TB suggests it really
stored bit counts.
By the way, what did you use to setup the Amiga RDBs?
{^_^} Joanne Dow
On 2012/06/17 01:33, Martin Steigerwald wrote:
Sorry, forgot to keep Cc.
I think I will keep the disk as is for a while. I just won´t plug it to
the Amiga, since I have my Amiga backup on another dedicated
disk and do
On 2012/06/17 09:36, Geert Uytterhoeven wrote:
On Sun, Jun 17, 2012 at 2:58 PM, Martin Steigerwald mar...@lichtvoll.de 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
On 2012/06/17 14:06, Martin Steigerwald wrote:
Am Sonntag, 17. Juni 2012 schrieb Geert Uytterhoeven:
On Sun, Jun 17, 2012 at 2:58 PM, Martin Steigerwald mar...@lichtvoll.de wrote:
Am Sonntag, 17. Juni 2012 schrieb jdow:
| JXFS 64 bit file system
|
| With AmigaOS 4.x a new file system has
On 2012/06/17 14:15, Geert Uytterhoeven wrote:
Hi Joanne,
On Sun, Jun 17, 2012 at 11:06 PM, jdow j...@earthlink.net wrote:
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
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
mar...@lichtvoll.de wrote:
Am Sonntag, 17. Juni 2012 schrieb jdow:
| JXFS 64 bit file system
On 2012/06/17 14:06, Martin Steigerwald wrote:
...
I have a usage note for you and the person who did that partitioning.
If you start the partition at block 1 instead of block zero it probably
can coexist nicely with normal fdisk partitioning as well. (It used to
be able to since x86 partition
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
mar...@lichtvoll.de wrote:
Am Sonntag, 17. Juni 2012 schrieb jdow:
| JXFS 64 bit file system
On 2012/06/18 13:39, Martin Steigerwald wrote:
Am Sonntag, 17. Juni 2012 schrieb Geert Uytterhoeven:
On Sun, Jun 17, 2012 at 2:58 PM, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Sonntag, 17. Juni 2012 schrieb jdow:
| JXFS 64 bit file system
|
| With AmigaOS 4.x a new file system has been
On 20180506 01:52, John Paul Adrian Glaubitz wrote:
On 04/27/2018 03:26 AM, jdow wrote:
And before I forget there are two features of the RDBs that I heartily
recommend never implementing on Linux. They were good ideas at the time; but,
times
changed. The RDBs are capable of storing
sense" event and
had to be reminded that the real world was wider than he envisioned. I don't
know what has happened since then.
{^_^} Joanne Dow
On 20180426 04:08, Geert Uytterhoeven wrote:
Hi Martin,
CC jdow
On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
<mar...@lichtvoll.de
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
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 219902322 bytes.
But that wastes just a WHOLE LOT of disk in block
It's more likely the filesystem unless I didn't get the RDBs up to 3.1 status. I
am pretty damn sure I did as I had an 18 gigabyte disk I was using at the time.
And I made sure it would mount with Linux. Files greater than 2 gigs were sure
to get messed up. But that was not RDBs. The disk had 9
.
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
HDToolBox is not mine. That is where the intelligence is needed.
{^_^}
On 20180626 01:02, Martin Steigerwald wrote:
Michael.
Michael Schmitz - 26.06.18, 04:23:
Joanne,
Martin's boot log (including your patch) says:
Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) sdb1
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
needs to grow more
intelligence. The step from RDB uint32_t to RDB uint64_t probably needs a great
deal of thought. Personally I'd be tempted to adopt GUID based partitioning
system. It has already considered this stuff.
{^_^}
On 20180626 01:12, Martin Steigerwald wrote:
Joanne.
jdow
rs,
Michael
On Tue, Jun 26, 2018 at 9:45 PM, jdow wrote:
If it is not backwards compatible I for one would refuse to use it. And if
it still mattered that much to me I'd also generate a reasonable
alternative. Modifying RDBs nay not be even an approximation of a good idea.
You'd discov
acy m68k partitioners). Adrian
has advertised parted as replacement for the old tools - maybe this
would make a nice test case for parted?
I always used AmigaOS based tools to partition in RDB format, cause I
never trusted amiga-fdisk :).
On Tue, Jun 26, 2018 at 9:45 PM, jdo
The issue is what happens when one of those disks appears on a 3.1 system.
{^_^}
On 20180627 01:03, Martin Steigerwald wrote:
Dear Joanne.
jdow - 27.06.18, 08:24:
You allergic to using a GPT solution? It will get away from some of
the evils that RDB has inherent in it because they are also
Three issues exist here in two different places.
As far as a 32 TG disk is concerned RDBs can describe it and mount it safely -
sort of - modulo the following issues. They are not a problem, I believe, with
Amiga OSs new enough to understand RDBs. I cannot prove that. They are not
sufficient,
an point out a way to cause data loss with these precautions, for a disk
2 TB or larger that was partitioned and used on a recent version or AmigaOS
supporting such large disks, I'd consider omitting the 'eat_my_RDB_disk' boot
option, and just bail out as the only safe option.
Cheers,
Michael
Am 2
Error : Conventional RDBs cannot define more than 4,294,967,296 blocks.
or
Error : Conventional RDB block count overflow.
That is a HARD limit. The documentation for error should suggest larger
logical block (cluster, whatever) sizes as a way out. Of course, block size
"could" go
Um. new 64 bit stuff must be invisible to old 32 bit stuff.
{^_^}
On 20180627 14:20, Martin Steigerwald wrote:
Hi Michael.
Michael Schmitz - 27.06.18, 22:13:
On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald
wrote:
Thanks a lot again for your patch.
schmitz...@gmail.com - 27.06.18,
e will
remember any of this ...
Cheers,
Michael
Am 28.06.2018 um 15:44 schrieb jdow:
Michael, as long as m68k only supports int fseek( int ) 4 GB * block
size is your HARD limit. Versions that support __int64 fseek64( __int64
) can work with larger disks. RDBs could include RDSK and a new
On 20180627 23:45, Geert Uytterhoeven wrote:
Hi Michael,
On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
And as stated in my other reply to the patch:
partition needs 64 bit disk device support in AmigaOS or AmigaOS
like
operating
On 20180628 00:39, Geert Uytterhoeven wrote:
Hi Martin,
On Thu, Jun 28, 2018 at 9:29 AM Martin Steigerwald wrote:
Michael Schmitz - 28.06.18, 06:58:
[…]
In the interest of least surprises, we have to fix the 32 bit
overflow (so we can even detect that it would have happened), and
give the
On 20180628 01:16, Martin Steigerwald wrote:
Dear Joanne.
jdow - 28.06.18, 08:39:
Anything done to RDBs for Linux must remain 100.000% compatible with
existing Amiga equipment. Otherwise, what's the point of bothering to
use RDBs?
Done to, in the sense of written to: Yes. I completely
On 20180628 04:38, Martin Steigerwald wrote:
Martin Steigerwald - 28.06.18, 13:30:
jdow - 28.06.18, 12:00:
On 20180628 01:16, Martin Steigerwald wrote:
[…]
That brings to the fore an interesting question. Why bother with
RDBs
over 2TB unless you want a disk with one single partition
On 20180629 01:42, Michael Schmitz wrote:
Hi Geert,
Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
Do we really need the warning?
Once the parsing is fixed doing 64-bit math, it does not matter for
Linux anymore.
Well, irony of this is: In my case the RDB has been created on a machine
On 20180629 14:45, Martin Steigerwald wrote:
> Beware: Essay ahead which proofs it to the point that there is no
> overflow in RDB before 96 bits maximum value of sectors:
Time to go into more detail on RDBs. It isn't as simple as it started to appear.
extract from hardblocks.h RDSK block
On 20180629 16:24, Michael Schmitz wrote:
> Martin,
>
>
...
> The problem that still remains is with unpatched legacy versions. RDB
> does support large enough partitions out of the box, due to C/H/S all
> using u32. We all agree there. The question is with file systems and
Nope, I bothered to
ng large blocks.
{^_^}
On 20180629 17:44, Michael Schmitz wrote:
Joanne,
Am 30.06.18 um 11:24 schrieb jdow:
On 20180629 14:45, Martin Steigerwald wrote:
Beware: Essay ahead which proofs it to the point that there is no
overflow in RDB before 96 bits maximum value of sectors:
Time to g
On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
>
> Am 30.06.18 um 12:57 schrieb jdow:
>> On 20180629 17:44, Michael Schmitz wrote:
>>
>>> struct PartitionBlock {
>>>__be32 pb_ID;
>>>__be32 pb_SummedLongs;
>
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joanne,
>
>
> Am 30.06.18 um 15:56 schrieb jdow:
>>
>>>>> As far as I can guess from the code, pb_Environment[3] (number of
>>>> heads)
>>>>> and pb_Environment[5] (nu
o the RDB parser, cause the patch is on
changing that. The RDB parser is not responsible for what any file
system may do. Securing AFFS would be a different, important, topic.
With that mail I am probably out as this discussion took already quite a
bit of time.
But for details, read on:
Micha
Get everybody
On 20180630 00:49, Martin Steigerwald wrote:
> Whoa, my summary essay triggered digging even more accurately into that
> matter. For some obscure reason I am even enjoying this. :)
>
> jdow - 30.06.18, 05:56:
>> On 20180629 18:31, Michael Schmitz wrote:>
As software is discovered to be "broken" at it to the appropriate incompatible
list.
Otherwise permanently limit AmigaDOS to 2TB.
{^_^}
On 20180630 02:07, Martin Steigerwald wrote:
jdow - 30.06.18, 08:47:
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joann
FWIW on the other side this appears to be a good source of Amiga software data.
http://amigadev.elowar.com/
{^_^}
On 20180630 19:43, Michael Schmitz wrote:
Martin,
Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
I am really inclined to point some AmigaOS 4 developers to this
discussion and
On 20180703 00:22, Geert Uytterhoeven wrote:
Hi Michael,
On Tue, Jul 3, 2018 at 1:58 AM Michael Schmitz wrote:
On Mon, Jul 2, 2018 at 8:29 PM, Geert Uytterhoeven wrote:
+
+ /* Warn user if start_sect or nr_sects overflow u32 */
+ if ((nr_sects > UINT_MAX ||
41 matches
Mail list logo
