Friesen@PCO-MULTICS.HBI.HONEYWELL.COM (10/04/88)
I am in the process of programming an all resolution painting program in GFA Basic, and I decided to put in a routine to show you how much free disk space you have on a disk. I ran the procedure and it said that I had 0K available, but only 622367 of the 720000+Bytes were used. I used the show info. option on the desktop and got the same results. What does this mean? Can it be corrected? Thanks in advance "Exterminate! Exterminate!"--Daleks /~\-* ###--< /***\ /*****\ Aric Friesen Addresses: Genie: A.FRIESEN ARPA: Friesen%PCO@BCO-MULTICS.ARPA
rjung@sal4.usc.edu (Robert allen Jung) (10/05/88)
In article <881004014748.973404@PCO-MULTICS.HBI.HONEYWELL.COM> Friesen%PCO@BCO-MULTICS.HBI.HONEYWELL.COM writes: >I am in the process of programming an all resolution painting program in >GFA Basic, and I decided to put in a routine to show you how much free >disk space you have on a disk. I ran the procedure and it said that I >had 0K available, but only 622367 of the 720000+Bytes were used. I used >the show info. option on the desktop and got the same results. What >does this mean? Can it be corrected? "Do not be alarmed. There is nothing wrong with your Desktop." What's going on is that ALL of the sectors on your disk are full, and that 622,367 bytes of that is being used for data. The rest of it is used for "overhead", such as disk directories (and folders), FAT records (to keep track of how a file is linked), and unused sectors. (In short, each sector is allocated for 512 bytes. If you created a file that was only 10 bytes long, you would have 502 bytes "wasted" because the sector is not completely full) --R.J. B-) ----------------------------------------------------------------------------- Disclaimer: These are my views, and mine alone. # ## # Mailing address: Beats me, just reply to this message # ## # (rjung@nunki.usc.edu?) ## ## ## #### ## ####
javoskamp@watmum.waterloo.edu (Jeff Voskamp) (10/06/88)
In article <881004014748.973404@PCO-MULTICS.HBI.HONEYWELL.COM> Friesen%PCO@BCO-MULTICS.HBI.HONEYWELL.COM writes: > >I am in the process of programming an all resolution painting program in >GFA Basic, and I decided to put in a routine to show you how much free >disk space you have on a disk. I ran the procedure and it said that I >had 0K available, but only 622367 of the 720000+Bytes were used. I used >the show info. option on the desktop and got the same results. What >does this mean? Can it be corrected? Here's what actually goes on as far as disk free space is concerned: Free space is defined as the number of bytes available in free sectors on the disk. Used space is defined as the total number of bytes used in all files on the disk. The thing is that space on the disk is allocated in multiples of 1k (2 sectors). Therefore while in your case 622367 bytes are being used the other 90K+ bytes are being "lost" in chunks of between 1 and 1023 bytes per file. (This is a case of what is known as internal fragmentation; the same thing can happen with memory allocation (except for the Malloc bug which doesn't let you go on that long (TOS 1.4 will let you see this in action (from what I've heard a lot of work has gone into it)))). This can be confusing since it means that even though there are 0 bytes free on a disk you can still write up to 1023 bytes PER FILE by appending the data, and there's nothing you can do about it. If you think it's fun on a floppy, try a 10Mbyte hard disk partition with 3000+ small files. It looks like about 1.5Mbytes is missing! Hope this helped. Jeff -- "I've lost my stutter!! How much wood could a wood chuck chunk if..." Ken in "A Fish called Wanda" bang path: ...{!uunet}!watmath!watmum!javoskamp domain : javoskamp@watmum.uwaterloo.ca or javoskamp@watmum.waterloo.cdn
koreth@ssyx.ucsc.edu (Steven Grimm) (10/06/88)
(the author wonders how a disk can be full if all the file sizes total less
than the amount of space on the disk...)
Remember that disks are split up into 1K blocks, and that those blocks are
the minimum unit of disk space that can be allocated. When you create a
1-byte file, you lose 1024 bytes of free space on the disk (or 2048, if you
are writing to a folder that needs to get bigger to hold the new file entry).
Thus, 360 1-byte files would fill up a single-sided disk, though show info
(and the "bytes used" field in desktop windows) would only show 360 bytes
being used.
---
These are my opinions, and in no way reflect those of UCSC, which are wrong.
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!korethapratt@atari.UUCP (Allan Pratt) (10/07/88)
It's worse than you think: if you create a file and write 10 bytes to it, 1014 bytes are being "wasted" -- files are allocated in "clusters" of 1K each. This is called "internal fragmentation" and is the kind of overhead you have to deal with. The alternative is to allocate files in bytes, which yields zero internal fragmentation but is REALLY SLOW and yields LOTS of external fragmentation. External fragmentation is the space used to keep track of the data: directories (including the root directory) and FATs. Show Info on the desktop adds up the number of data bytes used in each file; that's the "bytes used" field. Then it uses the OS Dfree call to determine bytes available. You will notice that the bytes available is always an even multiple of 1K. The difference between (bytes used + bytes available) and (bytes available on an empty disk) is the internal fragmentation plus subdirectory space. (Root directory and FAT space is not counted in the "bytes available" field for an empty disk). The Dfree call returns several numbers: the number of clusters on the disk to begin with, the number of clusters currently available, the number of disk sectors per cluster, and the size of a disk sector in bytes. Note that a freshly-formatted disk will show two clusters already used. This is a bug in GEMDOS. It can be fixed, but we decided not to, because it creates problems with new versus old ROMs. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
alderaan@netmbx.UUCP (Thomas Cervera) (10/09/88)
In article <881004014748.973404@PCO-MULTICS.HBI.HONEYWELL.COM>, Friesen@PCO-MULTICS.HBI.HONEYWELL.COM writes: > ... > GFA Basic, and I decided to put in a routine to show you how much free > disk space you have on a disk. I ran the procedure and it said that I > had 0K available, but only 622367 of the 720000+Bytes were used. I used > the show info. option on the desktop and got the same results. What > does this mean? Can it be corrected? Maybe it's because you have many small files on your disk. Each file occupies at least one cluster (1024 bytes), that is, one cluster, recorded in your FAT map. Because TOS cannot pack partial used clusters together, the smallest file one can create is 1024 bytes in length. But TOS will always give you the real length of your file, so the remaining space will be hidden and couldn't be used. Another possibility is that you may open one of your files for append fre- quently. As you know, on an extend, TOS always makes up a new cluster, even if there's room in the last cluster of the existing file. So, in worst case, if you make 720 appends of 1 byte records, the disk will be full and in the directory, you'll find a file of 720 bytes, the disk info will schow you 0 bytes available. So, the problem you have may be the difference between directory lookup and FAT lookup feature of TOS, directory lookup counts up the file lengths in bytes, FAT lookup (used by disk info) will show you the number of free disk clusters (FAT entries), times disk clustersize (*1024). If your problem is about appending, you may copy your files to another disk and then re-copy it to a virgin disk again. This will fix this problem for awhile, but you'll do this then again. If your problem is about many small files, you should decrease the media cluster size of your floppy during formatting (maybe 512 bytes). Hope, this helps you. -- alderaan OP RKOpdp (RSTS/E) FB Mathematik/Informatik RKO Berlin Dieffenbachstrasze 60-61 1000 Berlin 61 UNIX - Just say NO !
steven@cwi.nl (Steven Pemberton) (10/11/88)
In article <1183@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > Show Info on the desktop adds up the number of data bytes used in each > file; that's the "bytes used" field. Then it uses the OS Dfree call to > determine bytes available. You will notice that the bytes available is > always an even multiple of 1K. The difference between (bytes used + > bytes available) and (bytes available on an empty disk) is the internal > fragmentation plus subdirectory space. (Root directory and FAT space > is not counted in the "bytes available" field for an empty disk). By the way, there's a bug in Turbodos that returns the wrong number of bytes free: it seems always to overestimate the free space. I only noticed this after checking there was enough space on a diskette, and then trying to copy to it, and getting a disk full error. Try writing a small file to an empty disk with Turbodos loaded and do a show info - it told me the right number of bytes used, but said that there were the same number of bytes free as before I wrote the file. Steven Pemberton, CWI, Amsterdam; steven@cwi.nl