TIP: Click on subject to list as thread! ANSI
echo: os2
to: Murray Lesser
from: Mike Roark
date: 1999-10-24 20:39:05
subject: Warp 3 install

Hello Murray!

Friday October 22 1999 22:03, Murray Lesser wrote to Mike Roark:

 MR>> That 47 byte file would take up a 32k cluster on a 1 gig fat
 >> partition. Notice it only takes 512 bytes of space. I just gained
 >> 31k of space for something else.

 ML>     I don't know what program you were using to produce your
 ML> "directory" display, but a one-byte file under HPFS takes up at least
 ML> 1 KB of disk space (one sector for the file itself and a minimum of
 ML> one sector for its Fnode).  There is only one sector used for the
 ML> Fnode, irrespective of the size of the file, unless the Extended
 ML> Attributes portion of the
 ML> Fnode takes up more room than is available in that sector.

I'm sure it does. As for what made the directory. It was a straight 'dir'
command using 4dos as the command processor. I just tried it with the OS/2
cmd.exe, and it says it uses 47 bytes. Nothing I have short of DFsee shows
anything about the fnode. But I do have a question. Isn't the fnode already
allocated in the HPFS section of the drive? I hope I'm clear about what I'm
asking. I mean the part that is allocated before any files are put on the
drive.


 ML>     The "big cluster" argument is a meaningless red-herring; HPFS
 ML> stands on its own merits without such nonsense.  You have to have a
 ML> very large number of small FAT files to have the "wasted cluster
 ML> space" exceed the "unavailable" disk space used by the HPFS file
 ML> system, itself.  Some day, when you haven't anything else to do,
 ML> format a partition HPFS and FAT, in turn, and use CHKDSK to see how
 ML> much more useful file space there is in the empty FAT partition than
 ML> there is in the same empty partition formatted HPFS.  (For example:
 ML> you get about 3 MB more on a "100 MB" Iomega Zip Diskette formatted
 ML> FAT than you do on one formatted HPFS.)

While this is true, I did recover almost 200 meg when I switched my file
storage drives that at the time were about 2 gig in size with lots of zip
files on them. I think it matters if there is a large number of any size files 
on a drive. I am talking about storing about 2000+ files on a drive.


 ML>     Incidentally, although HPFS is usually a better-performing file
 ML> system than FAT, there are some not-too-pathological data sets that
 ML> will perform better in a FAT partition than under HPFS--such as a
 ML> relatively few very-long sequential files.  It helps to understand
 ML> what your application set needs, when configuring your system :-).
 ML> For the record, I use an all-HPFS system (except for the CD_ROM
 ML> reader, floppies, and my Iomega Zip drive) on my two OS/2-only
 ML> systems.

I had so many problems when things were on fat partitions that I couldn't
stand it any more. like you I run all HPFS except of course the CD-rom. My zip 
drive finally bit the dust.. (an older scsi model known to die)..


 MR>> About the only drawback to HPFS is not being able to
 >> reliably recover deleted files. You learn quickly to make backups
 >> before doing anything destructive.

 ML> attempt before the system has written anything else to that space.  I
 ML> use the "UnDelete" utility from the GammaTech Utilities set, but there
 ML> are other utilities that will also do the job.  Usually when I
 ML> accidentally delete a file, I can get it back because I recognize my
 ML> stupidity before anything else is written to the partition.  But you
 ML> are right!  Backups are very necessary--no matter what file system you
 ML> may be using.

I haven't tried the GammaTech Utilities. I guess I should look and see what
I'm missing. And I think that my backup has a backup.. ;-)


Have a good day!!
Mike
Internet bcomber@cave.fido.de

---
* Origin: Finally Warped! (2:2490/8016)

SOURCE: echoes via The OS/2 BBS

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.