Subject: Re: [netatalk-admins] Large Volume Support? again

From: [email-masked] (Donald Lee)
Date: Tue, 3 Feb 1998 09:27:15 -0600

At 2:16 AM 2/3/98, Walt Bigelow wrote:
>Andrew McNabb wrote:
>> 
>> On Sun, 18 Jan 1998, Tracy Peek wrote:
>> 
>> > Hello Everyone On This List ...
>> >
>> > I have a problem I hope that can be solved ... I have installed a 9 gig
>> > drive in my
>> > server and have made two partitions of just of 4.0 gigs a piece. One for
>> > appleshare
>> > (netatalk) and one fro Samba (PC Support). If though a "df" shows only 21
>> > percent
>> > used on the netatalk volume .. the mac client finder shows only 200 megs
>> > available.
>> 
>> MacOS has some problems with large volumes.  However, the problem depends
>> on the model of the computer.  Certain types of Macs running 7.5.2 or
>> later will support any size of a hard drive (up to several terabytes).
>> However, anything else has an upper limit that is more restrictive: 4GB.
>> Any MacOS system before 7.5 can only support 2GB.
>> 
>> Apple has several documents relating to this in the TIL:
>Sorry to bring this up yet again, but I have 2 PPC's one a 9500 and one
>a 7100, both running MacOs 8 (and after reading the apple support pages,
>aparently the machines can support up to 4TB.)  I wound up with a
>problem in limits of drive size when I mount the netatalk server (Linux
>slackware 96/netatalk 1.4b2 with the mac os 8 fix).  It reports 2gig
>where I actually have a 32GB raid array available on the file server.  I
>have looked through the dist for a compile time option, but have found
>none.  What is the trick to make it repor the ACTUAL size? 
>
>Thanks again,
>Walt

I believe that this is a problem not with the software, but with
the AFS protocol.  As I recall, there are some limitations in the protocol
that limit the reported size of disks to mod(realsize,2gig), so if your
disk is 3 gig it reports 1 gig, etc.

In the latest clients (shipped with MacOS8) I think it figures out on the
client side that the size is over 2G and simply reports its max, but
I don't know.  This has been a point of discussion on some Apple
server mail lists, and they;re working on it.

This does not affect how big volumes can get and doesn't pose a problem
in accessing the whole 32Gb, just in the reported free space/size.

-dgl-

---

From: "Stefan Bethke" <[email-masked]>
Date: Tue, 03 Feb 1998 18:40:22 +0100

> none.  What is the trick to make it repor the ACTUAL size? 

You have to understand the various parts involved: the AFP server
(protocol), the AppleShare client, the External File System interface and
the Finder.

As of MacOS 8.0 the External File System interface does exchange volume
information as an unsigned 32bit number (4 GB). This was upped from a signed
32bit in 7.6 (2 GB). This hasn't changed in 8.1, as I believe.

netatalk 1.4b2 (with or without macos8 patch)  only does AFP 2.1, which also
limits the number to 32 bits (4 GB). Currently, netatalk only uses 31 bits.
AFP 2.2 introduced new calls that use 64 bits (about 17,000,000 TB).

AppleShare client 3.7.0 was the first to support AFP 2.2 (including
afp-over-tcp aka AppleShare IP), but didn't take advantage of those 64 bit
calls. 3.7.2 and above take advantage of the calls.

The Finder (even in 8.1 I think) normally is limited to 4 GB.

However, AppleShare Client 3.7.2 and above tweak the numbers so the Finder
actually can display sizes of over 4 GB. (I'm not sure what the upper limit
is.)

Note that this has *nothing* to do with the ability of 7.6 and above to use
*local* HFS/HFS+ volumes larger than 2 or 4 GB.

So, what gives? If you want to see accurate volume information for volumes
larger than 2 GB, use Adrian Sun's patches for AFP 2.2 support and
AppleShare 3.7.2 or newer.

Stefan

--
Stefan Bethke
Promo Datentechnik      |  Tel. +49-40-851744-18
+ Systemberatung GmbH   |  Fax. +49-40-851744-44
Eduardstrasse 46-48     |  e-mail: [email-masked]
D-20257 Hamburg         |  http://www.Promo.DE/