Conference 7.286::atarist

     Steph, as far as I know the ST-Series uses 24 physical address-lines,
     that means 2 powered by 24 gives you a room of 16,777,216 Bytes
     to address. I think that's also the reason why the MMU *only* handles
     16 Meg of Memory on the motherboard as a maximum.
     So you have to divide your Winchester in virtual drives with 16Meg
     each.
    
     Bernd
    
    
    

Sorry, but .1 is junk.  68000 addressing has nothing to do with disk
partitions sizes, and in addition, 1040's and 520's only have an MMU
capability of 4mb.

You will notice that 16mb is 32768 512-byte blocks.  I would surmise that
either careless use of signed numbers in the file system, or the use of
256-byte blocks, is responsible here.

 Re: .2

>You will notice that 16mb is 32768 512-byte blocks.  I would surmise that
>either careless use of signed numbers in the file system, or the use of
>256-byte blocks, is responsible here.

  Jeff, I believe that you are correct on it being carelessness on the use
of signed numbers.  Also, Atari's position on this is they say that they
aren't going to fix it.  I'm Unsure as to why they don't want or can't fix
it.

Bill Powers

    Actually, one interesting point is that you can't even have 16 Mbyte
    partitions.  You can only have 16MByte - 1KByte (one cluster)
    partitions.
    
    Allan Pratt said that he looked into fixing it, and determined that
    it would be too much work for now.
    
    Steph

Jeff, after reading me through some lecture I must say that I was
definitly wrong. I just tried to find an explanation for something
I couldn't understand as well.
It must be a problem with the TOS of the 520ST or 1040ST because a
friend works with a Winchester of 20MB on a Mega4 and has only one
partition for it. A sho info on the HD gives him a little less than
20MB of usable space. He does not know if there is a chance to
use more space for partitions with the Blitter-TOS of the Mega4, he
only got a 20MB HD. 
Somebody told me that defining to much space for a single partition
makes the HD awfull slow. Is it right that the HD becomes the slower
the larger the partition is?

Bernd

    Re: .5
    
    I have also read that performance is worse for large partitions.
    
    I would guess that it's because it takes longer to traverse the
    free space list.
    
    Martin H.

    Re: .5, .4
    
    You are absolutely correct that the size of the partition affects
    the free-list traversal.  In the current version of TOS, the function
    is a strong one.  The Dfree function takes forever on a 16Mbyte
    partition.
    
    There is, however, a PD program, called FATSPEED which is claimed
    to weaken this function considerably.  HDs are supposed to perform
    resonably well with it.  I haven't tried it yet.
    
    The ST has about the slowest file system I have ever seen.
    
    Steph
    

I read some Atari-manuals meanwhile, and every manual speaks of a
GEMDOS-problem with the 16MB, which is solved now in the Blitter-TOS.
On a Mega-ST one can size the partition to 32 MB.
But they don't tell you, where in GEMDOS the faulty part is located.
The max-size of a partition is defined in the FAT of the HD,
which is 16 Bits long (Floppy: 12 Bits). A 16Bit-FAT gives room
for 32766 clusters ($8000 - 2) with 1024 Bytes each which can make a 
logical drive 32MB big. For each cluster TOS allocates 16 Bits.
(B.t.w. another fault in old GEMDOS causes counting of free bytes on a
disk to be wrong. It counts two clusters less).

Entries of 16-Bit-FAT for HD's:

$0000          unused
$0001          impossible
$0002 - $7FFF  pointer to next cluster
$8000 - $FFEF  impossible
$FFF0 - $FFF7  damaged cluster
$FFF8 - $FFFF  end of file

So the conclusion of the whole problem is a failure in GEMDOS of the ST's,
as said before in this note. Sorry I couldn't find out more...

Bernd

    Is there any current information on partition size? Is 32 meg still
    the largest partition size?
    
    What is the maximum number of partitions?
    
    Does anyone have any information on DC Data Diet, or any other hard
    drive data compression program available? Do these programs cause
    excessive wear and tear on the drive? Is there a problem backing up
    compressed data (I use GOOD BACK-UP UTILITY)? How much do they effect
    the drive performance? 
    
    I have read a couple a of blurbs on DC Data Diet. nothing that I have
    read covers the above questions.
    
    My 50 meg drive is almost full and I'm going to have to make a decision
    pretty soon or I'm going to to be doing the "Floppy Shuffle" once again
    
       
         thanks
    
                Bill

>    Is 32 meg still the largest partition size?
With some of the newer HD formatters (Atari, ICD, ???) you can have partitions
of any size. This is done by increasing the block size, which makes it
incompatiable with disk checking programs like DLII.
    
>    What is the maximum number of partitions?
14.
    
>    Is there a problem backing up compressed data (I use GOOD BACK-UP UTILITY)?
No problem, backups are not affected by the format of the data.

Don't know anything about DC Data Diet.
    
	Ray

>    Is there any current information on partition size? Is 32 meg still
>    the largest partition size?

Atari has standardized the method for going beyond 32 MB.  If you use
the latest ICD software, or the latest Atari software, you can create
partitions of very large sizes.  The following numbers are relevant:

- Maximum number of clusters on a disk is 32768 in TOS 1.0 & 1.2, and is
65536 in TOS.  A cluster is the smallest unit of allocation that is
given to a file.

- As near as I can tell, a cluster is required to be 2 sectors.

- There is nothing that prevents a disk driver from lying about the
sector size, and allowing sectors up to 65536 bytes.  Realisticly, 4096
or 8192 bytes are as large as you might want to.

What this all means, is that the largest practical partition size is
about 512 Megabytes.
    
>    What is the maximum number of partitions?

C-P (16 partitions).  Letters hight than P can be used with Meta-Dos,
but that is not relevant to this problem.
   
>    Does anyone have any information on DC Data Diet, or any other hard
>    drive data compression program available? Do these programs cause
>    excessive wear and tear on the drive? Is there a problem backing up

The won't cause wear and tear, but I would worry about their reliability.

>    compressed data (I use GOOD BACK-UP UTILITY)? How much do they effect
>    the drive performance? 

GOOD does it's I/O at the sector level.  If "DC Data Diet" replaces the
block-level routines, GOOD will work fine.  If it replaces the GEMDOS
file I/O routines, it will not work.  I would also be interested in
information about this product.  I would bet that there was a
performance impact as well, but I don't know any more than you do.
    
>    My 50 meg drive is almost full and I'm going to have to make a decision
>    pretty soon or I'm going to to be doing the "Floppy Shuffle" once again

Get a syquest cartridge. :-)