SD Card longevity on a real Amiga 1200 or Vampire

[antiriad76]

Does anyone know if using an SD Card on an A1200/Vampire could cause any data issues down the road?

As we are all aware most SD cards have limited number of writes and as with any modern OS quite allot of information that get's written on the disk on a regular basis.

Does anyone know if using any of the classic workbench OS 1.X to 3.9 require a similar amount of writes that could render the disk unusable in a short time?

From personal experience on Linux when an SD card reaches it's write cycles then you cannot delete or copy new data but you can still read. In addition my Samsung EVO 16GB SDHC card lasted about a year on my dash cam but this because it writes constantly.

Does anyone know if the newer/high cost "High Endurance" SD Cards can solve this problem?

Any recommendations?

Thanks

[Daedalus]

It depends on what you're doing with it. AmigaOS isn't really a modern OS, and doesn't have the constant, frequent writes that most modern systems have - it only writes when you tell it to (e.g. saving a file, saving settings etc.), or when some program you've installed does automatic writes (e.g. a network access log). This will limit the number of writes you need to do to a drive, and so it should last far, far longer than if you installed another system on it. If you rarely write to the drive at all, it should last decades.

However, the standard filesystem does have "hotspots" where it writes to the same blocks repeatedly, such as the volume bitmap, which is written to every time a file is written to on that volume. So that could be a potential issue. If the card implements some sort of internal wear levelling mechanism then it'll be fine as overall that's still a tiny amount of writing, but many SD cards don't have this, and the OS has no support for wear levelling at that level either. So if you go with an SD card (or CF card or SSD or whatever), go with one that has its own wear levelling and you shouldn't have any problems for many years.

[mark_k]

All cards will implement wear-levelling, but exactly how good that is will vary. On the plus side, SD cards are so cheap, if one stops working you can just buy another.

As Daedalus mentioned, the normal FastFileSystem updates the root block on every write which could be an issue both with wear and performance.

There are some things about SD cards which you should be aware of....

The SD specification mandates a specific filesystem layout. It's designed so that (for example), the data area of the factory-format FAT32 partition begins at a multiple of 16MB. The flash controller firmware in the card will be designed with that in mind. It will be optimised for small random writes in the before-16MB region where the FATs (file allocation tables) are, and for 32KB-aligned writes in multiple-of-32KB chunks over the rest of the card. (SDXC cards, for which exFAT is specified, will be optimised for 128KB-aligned multiple-of-128KB writes.)

If you examine the filesystem layout/structure of a brand-new SD card you should see that. In fact it's easy to inadvertently cripple the performance of a card by formatting it (on a PC) with a format program which isn't aware of the optimal layout. When re-formatting a card for use on a PC, use SD Formatter which will use the optimal layout.

When you partition/format an SD card on the Amiga, the way it's accessed by the Amiga won't match the pattern which the card firmware is optimised for. Meaning, accesses will be slower and involve more writes to the flash memory. Whether that's a problem in practice may vary depending on how many small random writes the system does, and how the card firmware handles that.

Once a card is filled up with data (i.e. most sectors have been written to at least once), the card firmware has to manage/juggle all that data, since it doesn't know which sectors correspond to deleted files and which are in use. That can reduce card performance, and also its lifespan since there will only be a relatively small number of sectors which the card uses as spares/wear-levelling.

You may have heard of "trim" in relation to SSDs. SD cards do actually support an erase command which you can use to completely erase all sectors. You can "refresh" a well-used card like that, and that should boost its performance. But in order to do that, you need to be able to issue the erase command. Most USB card readers don't have a way to do that. If you have a PC or laptop with a PCI Express-connected card reader though, you can easily erase the whole card using Linux, using the blkdiscard command.

The SD Association recently introduced a spec/certification for high random read/write performance (PDF press release). App performance class 1 (A1) requires random reads IOPS of 1500, write IOPS 500. If buying SD cards in future it may be worth getting an A1-spec one. There's also A2 class which mandates read IOPS 4000, write IOPS 2000 (another PDF press release). A1/A2 cards should perform much better with small random reads/writes.

In summary: when re-using an SD card for Amiga use, erase it (blkdiscard) before partitioning it. Use the QUICK option to the Format command to avoid needlessly writing gigabytes of data to the card. And if buying a new card, look for A1/A2-spec ones.

[antiriad76]

mark_k and Deadalus

Thanks for your explanations.

Does anyone know if the Filesystem makes a difference on the # of writes? If I am not mistaken PFS reserved 10% of the space for directory structure ,which is a fairly big amount by today's standards, and get's updated quite often. Also SFS seems to do on frequent updates of the transaction log(Roll back changes if OS Crashes) and also does de-fragmentation on the fly.


Also in later versions of FFS it seems that there is directory caching
DOS\4: "Directory Cache"
DOS\5: Directory caching with FFS (FFS-DC)

[Jope]

Don't use dircache on hard disks. It is only for floppy disks.

[mark_k]

Directory caching FFS will actually cause more writes to the card. As I understand it, DC-FFS maintains caches for each directory. So when you write/create a file, in addition to the normal file header block being created/updated the directory cache has to be too.

[Predseda]

Originally Posted by mark_k

In summary: when re-using an SD card for Amiga use, erase it (blkdiscard) before partitioning it. Use the QUICK option to the Format command to avoid needlessly writing gigabytes of data to the card.

So it is the same with CF cards?

[mark_k]

Some CF cards support an erase sector(s) command, but others just treat that as a no-op. [I guess it's possible some modern CF cards might support the same method of trim as ATA SSDs???]

Regarding the partition layout, the CF standard doesn't specify a particular layout, so you might expect CF cards to be less sub-optimal with differing layouts. However some cards come factory-formatted with a layout which is optimal for that card.

Also see http://www.hjreggel.de/cardspeed/info-formatting.html and http://www.hjreggel.de/cardspeed/cs_calign.html. At the end of the second page it mentions different SanDisk CF cards having different optimal alignments.

[idrougge]

Doesn't cfd.device support the abovementioned erase function?

[mark_k]

I don't know, but there's no standard way for Amiga filesystems to do that.

It turns out that the CF 5.0 specification announced in February 2010 includes mandatory trim support. So any CF 5.0-compliant card will support that. I don't know of any Amiga tools which support ATA trim, but at least you could rejuvenate a well-used card by trimming it (or issuing a security erase command maybe) when connected to a PC.

Someone should write an Amiga tool to automatically trim free blocks in FFS partitions, maybe PFS3 too? That would be useful.

[jarp]

Originally Posted by mark_k

On the plus side, SD cards are so cheap, if one stops working you can just buy another.

This. Stop worrying about it, just take backups every now and then.

[rare_j]

Thanks mark_k, i didn't know any of that stuff about SD cards.

[idrougge]

Originally Posted by mark_k

I don't know, but there's no standard way for Amiga filesystems to do that.

I think it only works with fat95, in which case the device senses that a format command has been sent.