»

[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?

[Gavilan]

I THINK Thomas is the man for answering and clarifying all this....

[Damion]

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).

[Zac67]

Hmm - most flash media are probably optimized for ~4k block sizes (the Windoze default), but due to the flash file system sitting in between(!) the host addressable block structure and the physical blocks the actual block/cluster size may not really be the most important thing.

However, it's a smart move to not use the full capacity of a card but leave 10-20% empty. This ensures that the flash controller has ample blocks to choose from when storing new or changing existant data. In addition to being faster on writes this will also further reduce wear and tear of the flash cells. (The flash controller reserves some capacity of the actual chips anyway but adding to this reserve will help it do a better job.)

[TheBilgeRat]

Originally Posted by Damion

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.

[Damion]

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.

[TheBilgeRat]

Originally Posted by Damion

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?

[orange]

I never had problems with auto configuring geometry.

think it works like this:
sector is smallest part of disk = 512bytes
track is all sectors in one circle (similar to tracks in olympics)
cylinders is track*number_of_heads (try to imagine it, its cylindrical, in 3D, if there are more heads/platters than 1)

I've heard it doesn't really matter what numbers you chose, as long as total number of sectors (heads*cylinders*sectors/track) is less or equal to real disk size.

[Thomas]

Originally Posted by TheBilgeRat

Obviously the 4 things relate to each other, but I'm not positive how.

Just mutiply them all to get the size of the disk in bytes.

[Zac67]

Originally Posted by TheBilgeRat

Interesting. You don't need them to match?

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.

[Zac67]

Originally Posted by orange

I've heard it doesn't really matter what numbers you chose, as long as total number of sectors (heads*cylinders*sectors/track) is less or equal to real disk size.

With magnetic media it really doesn't; SCSI disks have never had a host observable geometry, neither have later IDE drives. However, flash memory can't really be written to in sector sizes = 512 bytes (the flash controller just makes you believe), and this is about optimizing for this factor.

[TheBilgeRat]

Originally Posted by Zac67

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?

[Zac67]

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.

[TheBilgeRat]

Originally Posted by Zac67

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.