Hard Disk Partitions
Andrew H Krieg
the book for the BMS 100 that it said only 64 Meg of a single drive would be
supported, no matter how big the drive is. Is this a software or hardware
limitation? If I use Supra Utilities instead of the software that came from
BMS, could I use larger drives? Or do I need to upgrade to a BMS 200 (or
possibily a different Adaptec) to use larger drives?
Also, when checking the partitions of my current drive, I noticed the
software said that GEM only supports 16 Meg partitions adequately. Is this
still true?
--
= Andrew Krieg | =
= kr...@ct.med.ge.com | Treguna Mekoides Trecorum Satis Dee =
= or | =
= kr...@point.cs.uwm.edu| - Astoroth =
Mickey Boyd
> I am using a BMS 100 and Adaptec 4000 to run my hard drives. I noticed in
> the book for the BMS 100 that it said only 64 Meg of a single drive would be
> supported, no matter how big the drive is. Is this a software or hardware
> limitation? If I use Supra Utilities instead of the software that came from
> BMS, could I use larger drives? Or do I need to upgrade to a BMS 200 (or
> possibily a different Adaptec) to use larger drives?
I am not sure about the BMS host adaptor, but ICD does not have this
limitation, and they claim that their software will run on other host adaptors
now (with caching disabled, unless you pay for it). You may want to check
on this (i.e. it may be a software thing).
> Also, when checking the partitions of my current drive, I noticed the
> software said that GEM only supports 16 Meg partitions adequately. Is this
> still true?
TOS 1.0 and 1.2 had this limitation. For TOS 1.4 and above, it is 32mb per
partition. I am not sure about the Falcon/TT.
--
******************************************************************************
* Mickey Boyd *
* Systems Administrator *
* Florida State University Mathematics Department *
* email: bo...@math.fsu.edu Office: (904) 644-7167 Pager: (904) 657-6425 *
******************************************************************************
Claus Brod
> Andrew H Krieg (ult...@csd4.csd.uwm.edu) wrote:
> > I am using a BMS 100 and Adaptec 4000 to run my hard drives. I noticed in
> > the book for the BMS 100 that it said only 64 Meg of a single drive would be
> > supported, no matter how big the drive is. Is this a software or hardware
> > limitation?
It is a software (hard disk driver) limitation.
> > Also, when checking the partitions of my current drive, I noticed the
> > software said that GEM only supports 16 Meg partitions adequately. Is this
> > still true?
>
> TOS 1.0 and 1.2 had this limitation.
The truth is that GEMDOS can handle 32768 logical sectors per partition
at max. At 512 bytes/sector, this adds up to 16 MB. With bigger logical
sectors, you can have partitions up to 256 MB.
>For TOS 1.4 and above, it is 32mb per
> partition.
With 512 bytes/sector, no. There are still bugs in TOS 1.04 and
above that might bite you if you have partitions with more than
32768 sectors, so the limit is still 16 MB (with 512 bytes/sector).
--
--cl...@hpbeo79.bbn.hp.com----------------------------------------------
Claus Brod, MDD, HP Boeblingen Things. Take. Time. (Piet Hein)
--#include <std_disclaimer>----------------------------------------------
gerry_o'rourke
writes:
****Stuff Seleted*****
>The truth is that GEMDOS can handle 32768 logical sectors per partition
>at max. At 512 bytes/sector, this adds up to 16 MB. With bigger logical
>sectors, you can have partitions up to 256 MB.
>
>>For TOS 1.4 and above, it is 32mb per
>> partition.
>
>With 512 bytes/sector, no. There are still bugs in TOS 1.04 and
>above that might bite you if you have partitions with more than
>32768 sectors, so the limit is still 16 MB (with 512 bytes/sector).
>
>
>--
>--cl...@hpbeo79.bbn.hp.com----------------------------------------------
>Claus Brod, MDD, HP Boeblingen Things. Take. Time. (Piet Hein)
>--#include <std_disclaimer>----------------------------------------------
>
What are these bugs?. I have been using TOS 1.04 for over one year,with four 32
Mbyte partitions (512 Bytes/Sector).I have never had any problems apart from
using disk editors/de-fraggers that could not handle >16Meg.
I use folder100 in the auto.
I thought that TOS 1.04 was supposed to sort these disk bugs out.
The only strange part is the negative sector numbers (Supra Utils).
Gerry O'Rourke
Mickey Boyd
> The truth is that GEMDOS can handle 32768 logical sectors per partition
> at max. At 512 bytes/sector, this adds up to 16 MB. With bigger logical
> sectors, you can have partitions up to 256 MB.
True, but the default block size (bytes per sector) is 512k, and many programs
have problems with any other value. BGM partitions (those with blocks
of larger than 512k) can be used for mass storage and such, but I have not
had much success with anything but the desktop.
BTW, BGM partitions are a feature of the ICD host adaptor software. To my
knowledge, they were the first folks to do it. My understanding it that is
has become a semi-standard.
> >For TOS 1.4 and above, it is 32mb per
> > partition.
> With 512 bytes/sector, no. There are still bugs in TOS 1.04 and
> above that might bite you if you have partitions with more than
> 32768 sectors, so the limit is still 16 MB (with 512 bytes/sector).
Eh? I personally do not have TOS 1.4, but I have several friends that have
been using it (and 32mb partitions) for years without problems. There was
a time when some disk utility programs assumed a 16mb limit (which caused
some problems), but most of these have been upgraded or superceeded. For
example, early defraggers stopped at the first 16mb (which was not particularly
healthy for the disk). Newer utilites support the 32mb standard, as well
as BGM partitions.
So, what are these bugs you are referring to? Are you sure they are not
fixed by one of the myriad auto folder tos patches out there?
Giles Malcolm Welcome Guthrie
] GEM only supports 16 Meg partitions adequately. Is this
] still true?
Nah. TOS 1.4 and higher supports partitions of up to 32Mb, but decent HD software can
use logical sectors - sectors w/ >512 bytes each to increase the size. Try ICD's HD
utils.
Giles Guthrie
gm...@st-andrews.ac.uk
Julian F. Reschke
> Claus Brod (cla...@hpbbrd.bbn.hp.com) wrote:
> > The truth is that GEMDOS can handle 32768 logical sectors per partition
> > at max. At 512 bytes/sector, this adds up to 16 MB. With bigger logical
> > sectors, you can have partitions up to 256 MB.
>
> True, but the default block size (bytes per sector) is 512k, and many programs
> have problems with any other value. BGM partitions (those with blocks
> of larger than 512k) can be used for mass storage and such, but I have not
> had much success with anything but the desktop.
Only programs that directly access the disk come in touch with this: disk
monitors, re-organizers and such. If they don't work with more than 512 bytes/sec,
they are probably older than 3..4 years.
>
> BTW, BGM partitions are a feature of the ICD host adaptor software. To my
> knowledge, they were the first folks to do it. My understanding it that is
> has become a semi-standard.
>
Wrong. They were introduced with AHDI 3.0.
---
-----------------------------------------------------------------------------
Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster (from July, 1st: D-48161)
eMail: jul...@math.uni-muenster.de, j...@ms.maus.de
_____________________________________________________________________________
Claus Brod
> >With 512 bytes/sector, no. There are still bugs in TOS 1.04 and
> >above that might bite you if you have partitions with more than
> >32768 sectors, so the limit is still 16 MB (with 512 bytes/sector).
> >
> Mbyte partitions (512 Bytes/Sector).I have never had any problems apart from
> using disk editors/de-fraggers that could not handle >16Meg.
Many people have used oversized partitions, and in most cases they didn't
have problems. A fellow netter (Juergen Lock) has disassembled quite
a few parts of GEMDOS (both in TOS 1.04 and TOS 2.06) and found problems
in internal functions that are called by Fread/Fwrite when you are
writing large chunks of data. Juergen, are you listening?
Claus Brod
> BTW, BGM partitions are a feature of the ICD host adaptor software. To my
> knowledge, they were the first folks to do it. My understanding it that is
> has become a semi-standard.
Not true. BGM partitions were introduced with AHDI 3.00 and are documented
in the AHDI 3.00 specs. This is an ATARI standard.
> So, what are these bugs you are referring to? Are you sure they are not
> fixed by one of the myriad auto folder tos patches out there?
They are definitely not handled by any auto folder patch that I know
of. I think I have a description on my HD at home; I'll have a look.
Frank Bartels
>Andrew H Krieg (ult...@csd4.csd.uwm.edu) wrote:
>> Also, when checking the partitions of my current drive, I noticed the
>> software said that GEM only supports 16 Meg partitions adequately. Is this
>> still true?
>TOS 1.0 and 1.2 had this limitation. For TOS 1.4 and above, it is 32mb per
>partition. I am not sure about the Falcon/TT.
That is only right if you use 512 bytes/sector.
If you use 1024 bytes/sector and (any) TOS >=1.04 your partition limit
is at 64 MByte(BGM). You can use up to 4096 Bytes/cluster.
Atari's HDX does not support this. You have to use Hushi (SCSI-Tools
from Julian Reschke) or HDDRIVER (from Uwe Seimet).
Knarf
--
+-----------------------------------------------------------------+
| Frank Bartels - kn...@nasim.sta.sub.org - Munich - West-Germany |
+-----------------------------------------------------------------+
Thomas Omerzu
In article <H.ea.vQZV&h&q4&M...@nasim.sta.sub.org>
kn...@nasim.sta.sub.org (Frank Bartels) writes:
>If you use 1024 bytes/sector and (any) TOS >=1.04 your partition limit
>is at 64 MByte(BGM). You can use up to 4096 Bytes/cluster.
>
>Atari's HDX does not support this. You have to use Hushi (SCSI-Tools
>from Julian Reschke) or HDDRIVER (from Uwe Seimet).
Atari's HDX 5.0 _does_ support BGM partitions with > 512 bytes/sector.
--
*--------------------------------------------------------------------------*
Thomas Omerzu Internet: ome...@quantum.de
Quantum Software GmbH Telefon: +49-231-75441-0
Dortmund, Germany FAX: +49-231-75441-115
W.A.B.Evans
>usenet@bmers95 wrote:
>> What are these bugs?. I have been using TOS 1.04 for over one year,with four 32
>> Mbyte partitions (512 Bytes/Sector).I have never had any problems apart from
>> using disk editors/de-fraggers that could not handle >16Meg.
>
>Many people have used oversized partitions, and in most cases they didn't
>have problems. A fellow netter (Juergen Lock) has disassembled quite
>a few parts of GEMDOS (both in TOS 1.04 and TOS 2.06) and found problems
>in internal functions that are called by Fread/Fwrite when you are
>writing large chunks of data. Juergen, are you listening?
>
sector size 512) partition for years on my STE with no problems that I've
detected. FURTHER I have saved huge ramdisk files (i.e. containing ramdisk
contents) of up to 2 Mbyte sizes on these partitions with no detectable harm.
May I suggest your pal, Juergen, re-examine the code again and he may find
that what he "thought" was a bug is not one in fact. Or, if indeed there is
a bug with large file sizes, do tell us how to reproduce it - and at what
file sizes does it manifest itself.
Someone opined once in this Newsgroup (or allied one) that 32 Mbyte
partitions became possible when Atari suddenly discovered "unsigned" ints!!
W. Alan B. Evans
[ wa...@ukc.ac.uk ]
Uwe Seimet
>If you use 1024 bytes/sector and (any) TOS >=1.04 your partition limit
>is at 64 MByte(BGM). You can use up to 4096 Bytes/cluster.
The maximum sector size is 8192 bytes per sector which corresponds to a
maximum cluster size of 16384 bytes. This means with TOS >= 1.04 you get a
maximum partition size of 512 MB, with older TOS version the limit is 256
MB.
>Atari's HDX does not support this. You have to use Hushi (SCSI-Tools
>from Julian Reschke) or HDDRIVER (from Uwe Seimet).
HDX supports partitions up to 256 MB. This is compatible with _all_ TOS
versions, 512 MB partitions need TOS >= 1.04. There might be a bug in TOS >=
1.04 so that you shouldn't use partitions > 256 MB but this is not quite
clear. On my drives I didn't have any problems so far.
***************************************
* Uwe Seimet *
* sei...@rhrk.uni-kl.de *
* sei...@chemie.uni-kl.de *
*-------------------------------------*
* I really hate this damned machine, *
* I wish that they would sell it. *
* It never does that what I mean *
* but only what I tell it. *
***************************************
Peter Missel
>Julian Reschke) or HDDRIVER (from Uwe Seimet).
>Atari's HDX 5.0 _does_ support BGM partitions with > 512 bytes/sector.
This feature has been invented by Atari in HDX 3.00, supported ever since AHDI
3.00 appeared on the same day in 1988...
Frank Bartels
>In article <H.ea.vQZV&h&q4&M...@nasim.sta.sub.org>
>kn...@nasim.sta.sub.org (Frank Bartels) writes:
>>Atari's HDX does not support this. You have to use Hushi (SCSI-Tools
>>from Julian Reschke) or HDDRIVER (from Uwe Seimet).
>Atari's HDX 5.0 _does_ support BGM partitions with > 512 bytes/sector.
Yes, sure. But it does not support 32 MB partitions with 512
bytes/sector. If I install a 32 MB partition it uses 1024 bytes/sector.
I don't want to be compatible to TOS 1.00/1.02! I want to save disk
space!
Bye,
Erling Henanger
In a message on 1 June, wrote :
kR> Sender: ne...@stasys.sta.sub.org
kR> Path: ugle.unit.no!trane.uninett.no!sunic!mcsun!uunet!spool.mu.edu!howlan
kR> .ans.net!usc!elroy.jpl.nasa.gov!decwrl!sun-barr!news2me.EBay.Sun.COM!seve
kR> t.Sun.COM!sungy!stasys!nasim.sta.sub.org!knarf
kR> From: kn...@nasim.sta.sub.org (Frank Bartels)
kR> Newsgroups: comp.sys.atari.st.tech
kR> Distribution: world
kR> Message-ID: <H.ea.YWv...@nasim.sta.sub.org>
kR> Organization: Knarf's UUCP-Center, Munich, West-Germany
kR> X-News: HERMES MMAIL 1.04 Rev. Sep 5 1992
kR> Subject: Re: Hard Disk Partitions
kR> References: <1tj1d8...@uwm.edu> <C7EB8...@mailer.cc.fsu.edu>
kR> <H.ea.vQZV&h&q4&M...@nasim.sta.sub.org>
kR> <1993May28....@quando.quantum.de>
kR> Date: Tue, 01 Jun 1993 00:46:06 MESZ
kR> Lines: 21
kR>
kR> ome...@quando.quantum.de (Thomas Omerzu) writes:
kR>
kR> >In article <H.ea.vQZV&h&q4&M...@nasim.sta.sub.org>
kR> >kn...@nasim.sta.sub.org (Frank Bartels) writes:
kR>
kR> >>Atari's HDX does not support this. You have to use Hushi (SCSI-Tools
kR> >>from Julian Reschke) or HDDRIVER (from Uwe Seimet).
kR>
kR> >Atari's HDX 5.0 _does_ support BGM partitions with > 512 bytes/sector.
kR>
kR> Yes, sure. But it does not support 32 MB partitions with 512
kR> bytes/sector. If I install a 32 MB partition it uses 1024 bytes/sector.
kR> I don't want to be compatible to TOS 1.00/1.02! I want to save disk
kR> space!
Humm, if you know what you are doing, you could use a sector editor to
change the boot-sector. That's what I did (to get 1024 byte sectors on
64 Mb partitions).
If you make the sector-size half of what it used to be, remember also
to double the number of sectors (since each is half the size)
to QUADRUPLE the size of the FAT, since you:
a) Need a FAT twice the size of what
you used to have (more sectors)
b) Each sector is half the previous size
kR>
kR> Bye,
kR> Knarf
kR> --
kR> +-----------------------------------------------------------------+
kR> | Frank Bartels - kn...@nasim.sta.sub.org - Munich - West-Germany |
kR> +-----------------------------------------------------------------+
kR>
Erling
---
ş ATP/Unix 1.40 ş Hunt the whale
--
_______ _____ o ____ Erling Henanger
/___ /____/ / / /| / / Norwegian Institute
/ /\ / / / | / | ___ of Technology. (NTH)
------ / \ /____ / / |/ \____| o Don't save the whale !
Claus Brod
there are bugs that effectively restrict the size of partitions
to 32768 sectors, i.e. 16 MB with the standard sector size of
512 bytes. This claim was based on some facts that a fellow
netter, Juergen Lock, found some time ago. Juergen tried to post
the following details to the net, but for some reason (local
news problems), his message didn't make it into c.s.a.s.t (at least
I didn't see it), therefore I post it for him:
---------cut here----
From: n...@jelal.north.de (Juergen Lock)
Reply-To: n...@jelal.north.de, d0...@alf.zfn.uni-bremen.de
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Hard Disk Partitions; mails to me...
Message-ID: <3847....@jelal.north.de>
Distribution: world
Date: 31 May 93 20:32:22 GMT
References: <1993May25.1...@bmers95.bnr.ca>
<C7onG...@hpbbrd.bbn.hp.com> <45...@eagle.ukc.ac.uk>
In <45...@eagle.ukc.ac.uk> wa...@ukc.ac.uk (W.A.B.Evans) writes:
>In article <C7onG...@hpbbrd.bbn.hp.com> cla...@hpbbrd.bbn.hp.com (Claus
Brod) writes:
>>Many people have used oversized partitions, and in most cases they didn't
>>have problems. A fellow netter (Juergen Lock) has disassembled quite
>>a few parts of GEMDOS (both in TOS 1.04 and TOS 2.06) and found problems
>>in internal functions that are called by Fread/Fwrite when you are
>>writing large chunks of data. Juergen, are you listening?
>>
> This does not ring true!! I have been using a 32 Mbyte (logical
>sector size 512) partition for years on my STE with no problems that I've
>detected. FURTHER I have saved huge ramdisk files (i.e. containing ramdisk
>contents) of up to 2 Mbyte sizes on these partitions with no detectable harm.
>May I suggest your pal, Juergen, re-examine the code again and he may find
>that what he "thought" was a bug is not one in fact. Or, if indeed there is
:-)
>a bug with large file sizes, do tell us how to reproduce it - and at what
>file sizes does it manifest itself.
mixed `long' (more than 1 sector/cluster) and `short' (less than...)
access (Fread/Fwrite) to the the same place is the problem.. if everything
on the disk will only ever be read and written in long _or_ short chunks
without seeking around it may well be you never notice the bug.
technical: `short' read/writes go thru GEMDOS' buffer lists (root in
_bufl, $4b2) that work like sort of single-sector caches. when there
is a read or write request longer than one or two sectors it is not
splitted into single-sector requests that go thru the `cache' but
instead its done in one Rwabs, and all cache entries that are in the
sector range are flushed (forgot, written back) before. and that
check-if-in-the-range has a bug, it still thinks sector numbers are
15 bit + sign.
> Someone opined once in this Newsgroup (or allied one) that 32 Mbyte
>partitions became possible when Atari suddenly discovered "unsigned" ints!!
yes they just forgot one place... (at least) this is in TOS 2.06:
(gdb) disas 0xe10c10 0xe10d80
Dump of assembler code from 0xe10c10 to 0xe10d80:
0xe10c10: linkw fp,#0
0xe10c14: moveml d4-d7/a5,sp@-
0xe10c18: movew fp@(12),d5
start of sector range
0xe10c1c: movew d5,d6
0xe10c1e: addw fp@(10),d6
end of sector range
0xe10c22: moveal fp@(18),a0
0xe10c26: movew a0@(6),d7
0xe10c2a: movew d7,sp@
0xe10c2c: movew #9,sp@-
0xe10c30: jsr @#0xe0fa76
0xe10c36: addql #2,sp
0xe10c38: cmpl #1,d0
0xe10c3e: bne 0xe10c46
0xe10c40: movew d7,sp@
0xe10c42: bsr 0xe10a6c
0xe10c46: moveal @#0x4b6,a5
buffer list...
0xe10c4c: bra 0xe10c74
0xe10c4e: cmpw a5@(4),d7
0xe10c52: bne 0xe10c72
0xe10c54: cmpw a5@(8),d5
0xe10c58: bgt 0xe10c72
this is a signed check! unsigned would be bhi...
0xe10c5a: cmpw a5@(8),d6
0xe10c5e: ble 0xe10c72
ditto here, unsigned would be bls
0xe10c60: tstw a5@(10)
0xe10c64: beq 0xe10c6c
0xe10c66: movel a5,sp@
0xe10c68: bsr 0xe10ab0
flush entry
0xe10c6c: movew #-1,a5@(4)
0xe10c72: moveal a5@,a5
0xe10c74: movel a5,d0
0xe10c76: bne 0xe10c4e
climb the list
0xe10c78: moveal fp@(18),a0
0xe10c7c: movew a0@(6),sp@
0xe10c80: movew d5,sp@-
0xe10c82: moveal fp@(18),a0
0xe10c86: movew a0@(4),d0
0xe10c8a: addw d0,sp@
0xe10c8c: movew fp@(10),sp@-
0xe10c90: movel fp@(14),sp@-
0xe10c94: movew fp@(8),sp@-
0xe10c98: movew #4,sp@-
0xe10c9c: jsr @#0xe0fa76
bios (4, ...) == Rwabs
0xe10ca2: addaw #12,sp
0xe10ca6: movel d0,@#0x59d4
0xe10cac: beq 0xe10cce
0xe10cae: moveal fp@(18),a0
0xe10cb2: movew a0@(6),@#0x6730
0xe10cba: movel @#0x59d4,sp@
0xe10cc0: movel #26226,sp@-
0xe10cc6: jsr @#0xe0fb34
0xe10ccc: addql #4,sp
0xe10cce: tstl sp@+
0xe10cd0: moveml sp@+,d5-d7/a5
0xe10cd4: unlk fp
0xe10cd6: rts
0xe0fa76: movel sp@+,@#0x29b2
0xe0fa7c: trap #13
0xe0fa7e: movel @#0x29b2,sp@-
0xe0fa84: rts
and while i'm at it... here's another GEMDOS bug nobody seems to
believe me :-) open a file, read from it. open the same file again,
write (append) something at the end, then close both. if you do it
`right' and your lucky the stuff you just wrote now is lost, without
warning. (example: two processes with MiNT, like less and cat >>...)
still waiting for a multitos with fast GEM and a decent multitasking
BSD-type filesystem... :-)
Juergen
PS: north.de lost mail, apparently for weeks now... if your wondering
i did not get something you might want to send it again, preferably with
a copy to my other address, d0...@alf.zfn.uni-bremen.de. sorry :-(
--
J"urgen Lock / n...@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
...ohne Gewehr
--------------------------------------------------------------------
This should clarify my claim. Tnx, Juergen! I guess that the bug
occurs rarely enough that you don't have to panic about your
32 MB partitions, but there is a bug, and I wouldn't want to rely
on such a configuration. Maybe Eric has more on this, since he has
access to the GEMDOS source code 8-)