MacOS size weirdness

yellowdog-general@lists.terrasoftsolutions.com yellowdog-general@lists.terrasoftsolutions.com
Sun Jul 14 22:30:01 2002


Forgive me for belaboring this point...
The block size explanation makes sense to me, except for one thing.  
The weirdness isn't so much that my system folder takes up different 
space on different volumes, it's that it's not telling me the space it's 
actually taking up.  Here's the info:
on 1.0Gb HFS standard volume, get info tells me 252.5 MB on disk 
(224,735,017 bytes)
on 5.0Gb HFS standard volume, get info tells me 431.2 MB on disk 
(224,735,017 bytes)
But the space that's actually being taken up by data + wasted space on 
the 1.0 Gb volume is 431.2 Mb.  The 1.0Gb volume should have a 
smaller block size, and thus less wasted space--the "252.5 MB on disk" 
reflects that, but the effective disk usage (as reported by get info on the 
1.0 Gb volume icon, or by trying to put something else big on that 
volume) suggests that the block size(=>wasted space => effective disk 
usage) is larger.
Can someone explain this?  Is there a way I can get the number I'm 
actually interested in (effective disk usage) on the 1.0 Gb volume without 
such experimentation?

More to the point:  the motivation behind all this is that I want to partition 
my 20Gb hard drive so that I have some partitions for Linux and some 
for Mac, but I want the Linux side to be able to read the Mac 
partitions--so really, those are shared partitions.  Some of these 
partitions might be 5.0Gb, for which HFS isn't particularly well suited due 
to the block size issue--even, I understand it, if what I'm putting on it is, 
say, mp3s.  But Linux can't read HFS+, right?  Suggestions?

And a tangentially related question:  if I've got a dual-boot MacOS 9.1 
and YDL, can I run that MacOS 'system' via MOL from the linux side (that 
is, can I tell MOL "use this system folder on this volume here"), or does 
MOL maintain its own virtual hard disk in its own format, unbootable 
outside of MOL?

Thanks for the explanations, both past and yet to come (I hope!),

Andrew

Peter Bagnall <pete@surfaceeffect.com> said:

> The only think I can think of here is the block size.
[etc]