All abot Hard Drive Formatting, Cylinder Size and Block Size

[TheBilgeRat]

There's a lively (for the Natami board) discussion going on over at the Natami Forum about "hard drive" tuning for compact flash cards.  The suggestion is that running a CF card with block sizes of 16k increase speed and longevity.

Now, I was never an early adopter of hard drives, so my experience of formatting and partitioning is using cfdisk and busting out a few partitions to slap linux or windows on - IE I never ever mucked around with block sizes, cylinders or any of that.  I attempted some cursory googling and came up short or with "Just run the wizard, type in your number and let windows do the rest!"

So, having read through the thread, I fired up HDInstTools off my trusty Amiga911 disk and decided to muck around with a 4G CF card I have.  HDinstTools lets you adjust setup on 4 things: Cylinders, Blocks per Track, Heads, and Block size (Oh, and interleave and auto park).  If I adjust Block size by itself to 16k, the "size" of my disk increases to 122Gb or so, a tad outside the actual capacity.  Obviously the 4 things relate to each other, but I'm not positive how.  I am handy with numbers, but I'm not sure what the ratios are.

Can someone explain how all this stuff relates to one another?  Or offer up a good link where I can RTFM?

[TheBilgeRat]

I imagine they're talking about filesystem blocksize, cylinders, heads, etc, shouldn't have any performance impact (but the calculated total space of the drive needs to be correct).

Cut/Pasted from the thread (from Gunnar von Boehn, Natami Team Member):

Modern Flash medias like e.g. Compact Flash provide some very interesting features:* Very low latency and no seek time.
    This means reading directories or loading of many small files like  AMIGA icons runs at very high speed. Much faster than any normal  hardrive.
* No moving parts.
   This means the system is shock resistant, a flash disk will not die like a hardrive when moved or dropped.
    If used mainly for reading (like the typical SYS usage) then a flash  disk will have a very long lifetime longer than normal hardrives.
* Very low power usage.
* No noise.
* In systes which makes sense for an AMIGA SYS partition Flash disks also have a very attractive price.
* Compact Flash controllers support up to 66 MB/sec transfer rate.
   With a better model you can reach about 30MB/sec read speed.
   You can reach this speed both on sequential and on random cluster reads.
There are a few things that need to be taken care if you use a flash disk.
Some pitfalls:
* The flash is organized in chunks and clusters.
On  a read access a flash disk will always read a complete chunks  internally. The optimal filesystem aware of a flash disk will consider  this and align read to 16KB boundaries and always read  whole 16KB  blocks. I simple way to get this is using 16KB block size.
* The  flash in organized in cluster too. A cluster is typical 4MB of size. All  partitions should ALWAYS be aligned on cluster boundaries. A partition  program should always only create partitions aligned on cluster borders  on flash medias. If you misalign a partition the performance will drop  big time.
* Write speed is by design slower on flash disk than read speed.
You  can get quite good write speed of up to 10MB/sec if the OS does control  the writing and ensures that at least 16KB are written in a row.
* Another hitch is that "faking" is common with Flash medias.
There  are a huge number of no name slow disk on the market which were  relabeled as high speed models. So care most be taken when buying a  disk.
For optimal performance on FLASH medias AMIGA OS should slightly be tuned.
Correct partition aligment is very important.
And either setting blocksize to 16KB or implementing a simple disk cache is also important.

So, it seems 16k blocksize is more about keeping things lasting as long as possible and not causing setup to hinder read/write.  I just don't understand enough about drive geometry to calculate how to alter blocks(sectors) per track and # of cylinders to align with the change in block(sector) size.

[TheBilgeRat]

Right, but unless I'm mistaken, you would want to experiement with the filesystem blocksize setting where you create/modify your partitions, not the geometry settings in the drive setup menu.

Interesting.  You don't need them to match?

[TheBilgeRat]

To optimize perfectly for a flash device you'd need to match both sizes. Drive geometry and partition positioning influence the position of the first partition sector which should be a multiple of the flash structure size (block) - it's probably smart to make a cylinder the size of the flash block, so all cylinders will be aligned.

The filesystem sector size influences the alignment of all following sectors. Too small a size will lead to excess rewriting of small sectors, too large a size will waste capacity and IDE bandwidth. You probably won't care about capacity nowadays, so 16 KB may be a good choice.

When you say "cylinder the size of a flash block", then the cylinders should equal (in this case) a multiple of 4Mb?

[TheBilgeRat]

According to Wikipedia, common NAND flash block sizes are 16 to 512 KB, with larger, cheaper chips probably using larger blocks. 4 MB is probably well on the safe side, as is any larger power of 2.

Well with HDInstTools, the only thing which changes the estimated capacity is Block size.  If I leave block size at 512, I can put any number in the other fields and it stays reading the size correctly.  If I bump block size up by any amount, it changes the size accordingly regardless of the other numbers.

[TheBilgeRat]

In fact, neither HDInstTools nor HDToolBox read the correct drive size if alterations are made to the block size.  According to Thomas on the Natami site, its a bunch of hogwash anywas, as long as the numbers when multiplied fall within the proper physical drive size.