t19@nikhefh.UUCP (Geert J v Oldenborgh) (08/26/87)
Yet another weird effect. One of the partitions on our hard disk
suddenly appeared full, "df" and the desktop "show info" gave 5.99 out
of 6 Mb used. "du", however, only found 3.5 Mb to be accounted for (du
does not count directories, so a small discrepancy is to be expected).
We next moved all of the files on this partition to another one. 2.5 Mb
was still occupied... It looked as if the area reserved for removed
files was sometimes not cleared properly in the FAT.
Zeroing the partition solved the problem, but does anybody have any idea
what may have happened? Schoonschip, our algebraic manipulation
package, may have something to do with it as the only other hard-disk
owner which we know to have encountered the same problem also uses it.
Geert Jan van Oldenborgh.apratt@atari.UUCP (Allan Pratt) (08/27/87)
in article <385@nikhefh.UUCP>, t19@nikhefh.UUCP (Geert J v Oldenborgh) says: > > > Yet another weird effect. One of the partitions on our hard disk > suddenly appeared full, "df" and the desktop "show info" gave 5.99 out > of 6 Mb used. "du", however, only found 3.5 Mb to be accounted for (du > does not count directories, so a small discrepancy is to be expected). > We next moved all of the files on this partition to another one. 2.5 Mb > was still occupied... [...] The obvious answer is that at some time (or at several times), files were created, written to, but not closed. This only happens if your system is reset or powered off, because when a process terminates, all its files are closed automatically. But if this does happen, the clusters allocated to the file in question will be marked as "used" in the FAT, but won't be linked with any directory entry. These are known as "lost clusters," and CHKDISK would find them, if we had one. We do have one in-house, but I don't know a release date or anything. If "du" looks at files rather than the FAT, it would miss these, too. Here's another possibility: Each cluster in a subdirectory can hold 32 files. When you delete a file, that entry is marked as "available," and the next file creation will use it. If there are no available entries, GEMDOS will allocate another cluster to that subdirectory. Under no circumstances will GEMDOS de-allocate a cluster for a subdirectory -- even if all the entries in it are for deleted files. This means that if your application uses lots of files in subdirectories, and you delete all the files (but not the subdirectories themselves), there will still be lots of clusters allocated to the subdirectories. If you actually remove the subdirectories, of course, the disk space allocated to them is freed. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/ "Yow! Am I interfaced yet?"
grieggs@devvax.UUCP (08/31/87)
In article <385@nikhefh.UUCP> t19@nikhefh.UUCP (Geert J v Oldenborgh) writes: >Yet another weird effect. One of the partitions on our hard disk >suddenly appeared full, "df" and the desktop "show info" gave 5.99 out >of 6 Mb used. "du", however, only found 3.5 Mb to be accounted for (du >does not count directories, so a small discrepancy is to be expected). This sort of thing will happen when the system crashes while a file or files is open in write mode. There is not a lot you can do about it expect back up and restore the files, as the FAT is in an un-predictable and potentially in-consistent state. _john -- John T. Grieggs (Telos @ Jet Propulsion Laboratory) 4800 Oak Grove Drive, Pasadena, Ca. 91109 M/S 301-260A (818) 354-0465 Uucp: {cit-vax,elroy,chas2}!devvax!grieggs Arpa: ...devvax!grieggs@cit-vax.ARPA