AmigaOS 3.3 Feature Request [Shutdown]

[abu_the_monkey]

It could be tied to the 'Quit' option that already exists, that probably no one uses?

[Dragorth]

I don't think a button is needed. I think a question at install of is this hard disk on flash media of some type? and a check box in settings for if you make a copy for spinning rust, then intercept the common amiga magic reboot and add in the 3 second wait to reboot.
Those that want it will use it, those that don't won't, and you don't have something screaming in your face you won't use.

Fair enough?

[ljmarent]

@dragorth
I think you are talking about the reboot \ reset
We don't need to intercept that, as the power to the drive is not lost..
We only need the ability to warn the controller inside the NAND flash storage device before power-off

Hope I've not miss-understood where you were going.

[meynaf]

Originally Posted by Dragorth

I don't think a button is needed. I think a question at install of is this hard disk on flash media of some type? and a check box in settings for if you make a copy for spinning rust, then intercept the common amiga magic reboot and add in the 3 second wait to reboot.
Those that want it will use it, those that don't won't, and you don't have something screaming in your face you won't use.

Fair enough?

Not really. The problem is for power off, not for reboot.

[abu_the_monkey]

that is why I suggested the 'quit' menu option in workbench as it is a useless option anyway past a vanilla install and does not open a shell/command line window for you even then. just add an extra requester option to 'shutdown'
and use it /don't use it, jobs a good un.

[Dragorth]

Nope, your right, I was confusing reboot and shutdown.

I wonder if the AmigaOS can just be made to turn off most everything, and just power the disk for an extra few seconds, then shutdown?

[ljmarent]

@Dragorth

The trouble is ... keeping the power alive does not warn the controller inside your NAND flash device that you are about to kill it..

NAND flash controllers run tons of background operations when you are not looking at them...

They are scanning through the array looking for blocks that are about to fail ECC recovery, marking them for copy to freshly erased blocks.
They are transferring weak blocks to fresh blocks.
They are erasing weak blocks and testing that they are all FF or marking them as bad.
They are removing bad blocks permanently from the available block table.
They are transferring fresh data from the pSLC cache to to the TLC array blocks.
They are managing the FTL table that keeps track of the Physical Block to Logical Block table.

This is just some of the background or BKOPS activity that is going on while the HDD LED is dark
So .. you have no idea what the NAND flash device is doing, or what data at rest is in jeopardy when you decide to rudely cut the power...

This used to be a bigger issue.. but modern devices have all come to grips with using NAND flash storage. As a result, NAND flash storage manufacturers have cost reduced their products, and are protected by modern software technique. We're not going to suddenly start adding cost to NAND flash storage to behave like an old HDD, when the engineering world and customer cost demand already drove us to where we are.

We do make enterprise class NAND flash storage devices for more demanding environments.. but we charge a significant up-charge for that class of product and it's a tiny portion of the client class product volume. Eventually it too will likely be gone from the market.

So .. the key to using commonly available, reasonably priced NAND storage technology is simply to tell it you're about the switch off the power before you do and give it three seconds to react.

[Minuous]

The devices are defective by design if they really cannot handle a loss of power, as there is always the possibility of blackouts. And obviously nothing can be done by the OS or driver software to help with that.

[ljmarent]

@Minuous

You likely didn't read the whole thread ?
I explained already what is done at startup, using software (BIOS), to mitigate harm in your stated situation.

However .. for a very long time .. many, many SSDs suffered data corruption from asynchronous power loss.
Thumb drives and SD cards still do, but users are more accepting of this.

And .. it's not a defect .. it's a market induced compromise.
Made by the electronics industry and consumers demanding lower cost.

Like .. knots in lumber...
Sure you 'can' buy a perfect piece of lumber without knots, however it is ten times the cost of a knotty piece of lumber, and very few people buy this from a specialty wood store and only for select applications.

MLC SSDs from about 2014 and earlier could actually be destroyed by asynchronous power-loss, not just suffer data corruption.
Some progress was actually made in the drive designs, to ensure their 'survival', but your data is a lower priority.

[Thomas Richter]

Originally Posted by Dragorth

I wonder if the AmigaOS can just be made to turn off most everything, and just power the disk for an extra few seconds, then shutdown?

There is no hardware facility to shut down the machine. There is, at SCSI level, the possibility to park and shutdown a device, and for that, there are already solutions, for example this one:



http://aminet.net/disk/misc/Park.lha


It would then be the responsibility of the user to park (shutdown) drives properly. I had BenchTrash arranged such that it parks drives if you move the icon to the trashcan. All it does is that it stops the file system, flushes its buffers and then either sends a TD_EJECT or SCSI START/STOP command to the exec device. That works well for SCSI, but...



However, that leaves the problem open that either TD_EJECT or the SCSI START/STOP command needs to be forwarded and translated to the IDE/SATA/whatever level, and this is a driver issue, and not an Os issue. I do not know what most SCSI to SD/IDE to SD adapters do with this command, either. The Amiga hardware and firmware is not really up to the task at this point, I afraid.

[Jope]

Originally Posted by Minuous

The devices are defective by design if they really cannot handle a loss of power, as there is always the possibility of blackouts.

What values of cannot handle a loss of power are we talking about? It was already outlined how the drives do in fact recover from a power loss, and also a scenario was presented how the user can unwittingly cause harm to the recovery process when using the drive with an old computer.

[Minuous]

A "recovery" that still results in data corruption isn't very satisfactory even if the device is not bricked.

[Jope]

Using the drive out of spec and then being dissatisfied is difficult to relate to for me.

I hadn't personally considered this failure mode with SSDs and old computers, it's good that this post raised awareness.

[Minuous]

Any specification that mandates 100% power availability is not realistic; nowhere has 100% reliable electricity.

If it's fine to lose or corrupt the contents when power is lost, then why not just use ordinary RAM?

[Jope]

Well I'm sure you read the description. Several consecutive power losses each while it's recovering its journal is when the data corruption happens.

They will recover from isolated power loss incidents.

[ljmarent]

I 'feel' this thread accomplished many things.

1) It brought awareness to how AmigaOS 3.1.4 -> 3.2.2.1 active development and distribution, could potentially help its modern NAND flash storage users,
in the form of a feature request to let NAND flash controllers 'know' you are about to flip the power switch.
If and how the dev team tackle the issue of making future distributions more NAND flash aware and mitigate user data loss, is of course entirely up to them.

2) It brought awareness to the Amiga community that there is 'magic' going on inside their NAND flash devices, especially when the activity light is dark.

3) It brought awareness to the Amiga community that some enterprise grade NAND flash storage solutions have hold up power to more gracefully handle asynchronous power loss, but that most of the NAND flash storage they buy is client grade and compromises have been made, over time, between the electronics industry, NAND flash storage manufacturers and consumers, in order to drive costs down.

4) It put Amiga client grade NAND flash storage users on notice that they are not in the clear, just mostly lucky, and you should not be flipping that power switch on-off-on-off-on-off-on when things don't go right..
Give your SSD some time (minutes) to recover and reset instead of power cycle, when you can.
AmigaOS doesn't know you have a specific drive in a specific place, so it's not going to warn you a drive is likely repairing itself and tell it's waiting to boot.
or.. any of the other cool strategies that modern BIOS's use to help the SSD get back on track after an asynchronous power loss.

5) It helped to inform users, so they could ultimately decide if they personally want to use client NAND flash based storage,
opt to pay the extra for enterprise options, or just forego NAND flash storage altogether..

6) It gave many people a chance to howl at the moon their displeasure in how we got here,
what industry acceptable practices are,
the very real idea that data might get lost or corrupted in a storage device,
(all storage since the dawn of 'storage' has suffered loss),
that market consensus to compromise comes with costs,
that those compromises increase the requirements on the systems they are used in,
what a spec is or isn't,
which specs they think are good,
what is or isn't a design flaw,
.. all sorts of ARWOOOOOW'ing happened here.

I'm going to gather up a package of documents (white papers, tech-notes) that I can legally share with the AmigaOS dev team and feel this is all I can do.

Thank you for sharing your time with me.