Hyperion Entertainment Message Boards

maybe a volunteer can add all this stuff to AmigaOS Wiki?
including a step by step description of what to do and why?
that would be highly appreciated!

thanks and regards
michael

Very interesting read. Thank you.

That's a lot of stuff I missed completely.
I added an SSD, and set it up just like any other HD.
Perhaps a dozen partitions, and about 40% left unused.

Either I've been very lucky, or it's not going as fast as it could and I have not noticed.

In any case, I think I'll leave it be until better options present themselves.

All backups are automatically saved to two separate drives. One is stilll magnetic.

tonyw wrote:I have two Kingston SSDs, a 120 GB and a 340 GB. Both identify themselves as having 512-byte blocks, so I can't use them in a native 4096-byte manner.

Perhaps the device drivers have to be enhanced to enable "native" operation? Is it disabled by default and must be enabled by the driver?

BTW, a user should not *have* to do anything especial to use a device that plugs into a standard SATA port and uses a standard device driver. It's a hardware issue and should be handled at that level.

I remember in a post TommySammy posted about the fact that formatting a CF card as FAT in AOS was not recognised in GParted. I also have noticed that I can remove a CF card and by using OS X's Disk Utility, can fully Erase it, format it, partiton it as MBR (FAT) and so on but in Media Toolbox the only erase is low-level and the only formatting is Quick Formatting. That being said. I agree with tonyw. Maybe an SSD.device driver can be created and Media Toolbox updated in order, not only to setup SATA, IDE HDD's, but to properly Setup and handle SSD's, USB Thumbdrives and the CF Card in order to be recognized across all platforms - more unified. I just don't know how difficult that would be to "redesign" Media Toolbox and device drivers under AOS4.1FE and still keep intact Amiga Filesystems and respective devices in Media Toolbox. Just a quick thought that crossed the mind.

Cheers!!

I think you may be a little confused about MTB. It does not offer erasure or formatting at any level - were you thinking of the "Edit RDB/Install" window?

MTB is only for defining partitions, although you can use it at a low level to redefine block and cylinder sizes. The name is perhaps inadequate, but the name "Partition Wizard" was already used at the time that MTB was written.

This thread has made me put a lot of thought into "proper" support of SSDs. I believe that "proper" support can be implemented by judicious choice of the cache size, in the device driver and/or the file system. I am looking into it.

tonyw wrote: This thread has made me put a lot of thought into "proper" support of SSDs. I believe that "proper" support can be implemented by judicious choice of the cache size, in the device driver and/or the file system. I am looking into it.

/me hugs TonyW

tonyw wrote:I think you may be a little confused about MTB. It does not offer erasure or formatting at any level - were you thinking of the "Edit RDB/Install" window?

MTB is only for defining partitions, although you can use it at a low level to redefine block and cylinder sizes. The name is perhaps inadequate, but the name "Partition Wizard" was already used at the time that MTB was written.

This thread has made me put a lot of thought into "proper" support of SSDs. I believe that "proper" support can be implemented by judicious choice of the cache size, in the device driver and/or the file system. I am looking into it.

Yes, Thank you tonyw! Appreciate you!

Cheers!!

John

The way I see other OSs do it is to what extent you're willing to support and even make a transition: EXT4 supports SSDs via a hidden trigger that you need to search in order of activate and even then you need to fiddle with mount options. BTRFS have included built-in switches that are automatically turned on at boot, while F2FS is a file system completely dedicated to nand and built around it.

From the article I posted the most difficult thing for me to understand seems to be the most basic: why fat? how come it seems like fat was meant all along for those usb sticks... what is it about the allocation in fat that fits?

You can choose a different storage model if you know the device you are talking to is an SSD. The old FAT file systems were designed to run on floppy disks of varying capacity, so they left all the disk-oriented data and root directory at the beginning. It probably works just as well (or badly) if you use a partition ten or a thousand times the size. If all your meta data (root block, root directory, etc) is in a fixed place, then the disk firmware can make allowances for it and optimise transfers.

Who knows, maybe disk firmware is already optimised for file system data at the start of the disk, without our knowing it? Maybe SSD firmware is optimised for FAT32 file systems?

I must do some experiments reading and writing various sizes and alignments of disk transfers to see if I can get a worthwhile improvement in cache performance that way. It may be that if you have a given partition, you can get better performance by ignoring the un-aligned area at each end of the partition and just use the portion in the middle, aligned to 1-MB disk addresses (or whole cylinders, or whatever size).

In any case, it has to be automatic. You can't expect the average user to properly set mount options to optimise disk performance.

Partitions are always aligned to whole cylinders. That's why I suggest to make cylinders = megabytes. That's the easiest way to align partitions properly. And it can be done by the partitioning tool, it does not need code changes in drivers and file systems. Only Media Toolbox should be changed to use proper cylinder sizes. I find these 48-block cylinders with immensly high cylinder numbers strange anyway. From a recovery point it is much better to have big cylinders and let the first partition always begin at the same cylinder number (e.g. 2, like HDToolbox did it).