CompuServe Thread

#New Filesystem

7 messages in this thread
#152990From: Eugene KushnirJun 19, 1994 12:35 AM
I uploaded a file called: "ffs31.lha" and here is what the docs say: "This new Fastfilesystem and HDToolbox are pre-releases of Workbench 3.1 from Commodore. There are a few applications, such as the new Studio 16 digital audio editing system that need _really_, _really_ fast file transfers, so even though Commodore isn't ready to release Workbench 3.1, they agreed to allow these files to be distributed. Be advised that you have to re-format your drives to take advantage of the extra speed. Be further advised that using the higher block sizes, while providing blinding speed increases, can use up a lot of hard drive space. My own personal compromise was to set the block size to 2048, which doubled the speed of my A4000 IDE drive, but took up just under 10% of the available storage space on the drive. Basically, besides a new L:Fastfilesystem device driver file, there's a new HDToolbox program to format the drive with. This new HDToolbox allows reading and writing block sizes other than the usual 512 bytes per block. It allows you to set up to 32K block sizes! This is like having built-in drive cacheing. With a 16K block size, my lowly Seagate IDE drive turned over 3 megabytes per second transfers, using DPerf2 as a benchmark. Prior to this, transfers were around 600K or so, according to DPerf2. Also note that the fastest transfers occur with "International Mode" and "Directory Cacheing" turned OFF. There's a price for this, though! Since the smallest amount of data that can be written to your hard disk is one disk block, the size of your disk blocks will regulate the smallest file you can save. For example, right now, the smallest file you can have is 512 bytes. Well, the file can be smaller, let's say 200 bytes, but it will take up 512 bytes of space on the hard disk, since that's the block size. If you change your block size to 16K, that same 200 byte file will now take 16,384 bytes of space, even though the file is only 200 bytes! So a very large block size will result in blinding hard drive speeds, but if you have a lot of small files, waste a great deal of hard drive space. On a graphics partition with 24-bit files, you have a lot of big files there, a big block size would probably work OK. But on a more standard partition, such as your boot partition, there's a lot of smaller files, so a large block size could waste a lot of your space. In my own test, a block size of 2048 doubled the speed of my A4000's IDE drive, but only wasted a little under 10% of the storage space. It was a trade I was more than willing to make. Your mileage may vary…. Best thing to do is to make a small partition, say around 10MB or so, test the speed with a benchmark program, then copy a known amount of files to it to check the storage efficiency. If 3MB of files leave a 10MB partition 50% full, you've lost 20%…" What do you think? Is it worth reformatting the drive? The HDToolbox program is different and has more options, plus the new fastfile is included.
#153072From: Ash WyllieJun 19, 1994 10:38 AM
How often do you need to transfer data at 3meg/sec. The only time that I can think of is replaying videos, and even then 500k/sec is faster than anim files are played. I suspect that the new file system will be useful for large(500meg+) drives with uncompressed images. The problem of internal fragmentation will keep people from using big blocks anywhere else. -ash
#153129From: Robert ComerJun 19, 1994 8:46 PM
You'd be surprised. Almost all of the bigger systems have bigger block sizes, and NEED it! If I could get 3MB a sec out of my PC or Amiga, it would make virtual mem less of a time waster. HD space costs less than my time, so I'd DEFINITELY use the new FFS! (When I can buy the 3.1 upgrade anyway) btw, big blocks don't adversely effect fragemntation any more than little blocks do… Bob Comer — AmigaDOS and OS/2, the only way to compute! Cheyenne, Wyoming U.S.A.
#153330From: Brian BartlettJun 21, 1994 5:12 AM
Bob, actually, it should be an inverse relationship. Big blocks reduce fragmentation. The Four Seasons of Southern California: Fire, Flood, Earthquake, and Riot.
#153329From: Brian BartlettJun 21, 1994 5:11 AM
Ash, actually, larger blocks should reduce the amount of file fragmentation, not increase it. Essentially, for each block that can be written to the hard disk, you face a binary decision tree, can it be written contiguously or not. The same applies to the next block as well, and so on until the end of the file. Where fragmentation rears its ugly head is when a prior file has been deleted. With smaller block sizes, subsequent deletion of files results in sequences of small holes on the disk. Therefore, any file that comes along later will try to fill in those small holes first. Now with a larger block size, in comparison to the previous example, each block can accommodate a larger chunk of information, so the new file will, if larger than one block in size, be spread over less blocks. Since each chunk of a file is accomodated in a smaller number of blocks, overall, there is less overall chance that it will be fragmented, or at least, the number of fragmented blocks that it occupies will be less in number. Very probabilistic since it all depends on the initial fragmentation of the disk, but for any given amount of fragmentation, you should do better, overall. Of course, you pay a price in that files don't come in even block sizes. On average, you should figure that the last block for each file is only half-full. So, for each file (15,000+ in my case not counting directory blocks and such), you will waste 1K. Not bad really (15 MB or so here). [That's assuming an average normal distribution, a poisson might fit better, in which case the wastage would be slightly worse.] As usual, you gain some, you lose some. You win on fragmentation and speed, you lose on effective use of disk space. The Four Seasons of Southern California: Fire, Flood, Earthquake, and Riot.
#153102From: John GagerJun 19, 1994 3:32 PM
"What do you think? Is it worth reformatting the drive? The HDToolbox program is different and has more options, plus the new fastfile is included." Well I guess you have to decide is the need for speed greater than your sense of security? I would have a hard time with installing a new filesystem unless I absolutely was sure it came from CBM. It wouldn't take much for a hacker to make a few patches to the FFS so that at some point in the future wipe out your hard drive. I'm not being paranoid, but caution is the best policy. // John (Speeding on the Information Superhighway) \X/ Mercury@ins.infonet.net
#153122From: Eugene KushnirJun 19, 1994 7:12 PM
"I'm not being paranoid, but caution is the best policy. " I think I agree with you. I won't do anything to my HD until I get the real 3.1 upgrade. However, at $120 it will have to wait.