Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Amigaz on February 24, 2007, 08:51:30 PM
-
Have had some weird problems lately on my A1200, I've copied lots of stuff from the AmiKit package to my Prefs/Presets folder but after a reboot some if it is gone! and if I delete all of it some of it is there again after a reboot :crazy:
Weirdness aplies also when saving my startup-sequence in OS3.9 editpad...sometimes the saving has no effect :-?
Have noticed this one some rare occasions on my other Amiga's but not as much on this one...I'm starting to suspect that the filesystem is the bug
Anyone have any clues?
-
Definitely sounds like a corrupt file system or a dying hard drive.
-
Now I noticed I can't add anything to the HD, it's just not there after a reboot.. :boohoo:
-
Which filesystem are you using?
-
PFS3, '060 version
-
try from shell:
diskvalid PART: ANALYZE
(where PART: is the PFS3 partition name to check)
Most likely the HD is dying.
-
Maybe not. I run PFS3 and have this same trouble. If I wait long enough before rebooting it doesn't happen. It has to be a cache issue, there's some critical thing PFS isn't writing directly to disk, it's going in the HD's cache instead of the disk.
-
Turn OFF your PFS3 write cache.
The write cache is totally unsafe.
-
ChaosLord wrote:
Turn OFF your PFS3 write cache.
The write cache is totally unsafe.
How do I do that?
-
Framiga wrote:
try from shell:
diskvalid PART: ANALYZE
(where PART: is the PFS3 partition name to check)
Most likely the HD is dying.
Will try, thanks :-)
-
hmm..diskvalid analyze turned out ok
And tested with a cold reboot after adding files and it works...so warm reboots doesn't save changes/files! :getmad: :getmad: wtf1?!!
-
Sounds like a sack of {bleep}e to me. Doesn't 3.9 come with a nice modern FFS? Once a file system displayed this kind of behaviour to me it'd be out faster than you can say "ZX Microdrive".
-
NoFastMem wrote:
Sounds like a sack of {bleep}e to me. Doesn't 3.9 come with a nice modern FFS? Once a file system displayed this kind of behaviour to me it'd be out faster than you can say "ZX Microdrive".
Yeah, but FFS sucks...it's too slow in every aspect
PFS3 has worked very well for me but on this config somethings
fishy..but don't know what yet :-(
-
Its the HD... don't listen to the .... ;-)
Theres nothing mentioned by ChaosLord switchable in PFS3 (btw ChaosLord, where have you found that ...?)
The only thing that can break PFS3, its a knackered HD.
Obviously you can try to backup and reformat, before to trow the HD away! but i doubt that it will solve the issue.
-
@ChaosLord
Turn OFF your PFS3 write cache.
There is no way to turn off the write cache in PFS.
The write cache is totally unsafe.
BS.
-
I have never found a way to get around this problem. It does happen on every hard drive I've ever used with PFS3. It does not make PFS3 not worth using, AT ALL!
You just have to give your Amiga a minute or two before you reboot it. It's still less painful than rebooting a peecee.
-
@AMC258
You just have to give your Amiga a minute or two before you reboot it.
You need to wait 3 seconds, or have some app send ACTION_FLUSH to the handler, flushing any pending writes immediatelly.
Hardly a real problem, you just need to be aware of it.
-
Gonna switch to SFS on my Workebench partition since the other partitions aren't acting weird
I just think it's odd that this symptom is so severe on this setup...I guess Framiga is right also, it's an old IBM 4 gig SCSI drive
-
Piru wrote:
You need to wait 3 seconds...
Yes, waiting the 3 seconds before reboot always worked for me with PFS3 harddrives.
-
Theory:
Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs. Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.
Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS. Yet other people such as Piru swear that PFS is 100% reliable. So there must be something different between your system and Piru's to cause this problem. If you figure out what is different then you will find the problem and permanently alter the course of Amiga history forever more.
-
ChaosLord wrote:
Theory:
Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs. Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.
Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS. Yet other people such as Piru swear that PFS is 100% reliable. So there must be something different between your system and Piru's to cause this problem. If you figure out what is different then you will find the problem and permanently alter the course of Amiga history forever more.
Something evil was sure causing it :-P
Just switched to SFS on the "evil" partition, it works so far..let's so how long...if it starts acting up again I'll bin the harddrive for sure
Not using any fancy sys hacks just Blizkick with some "safe" modules which I'm using trouble free on my other Amiga's ;-)
-
Maybe you are running some EVIL hack on your computer, such as Executive or MCP or whatever... and this hack is somehow interfering with or slowing down the write cache so that instead of it being written out in 3 secs it gets written out in 30 secs. Perhaps some evil prog is generating some enforcer hits to nonexistent memory or who knows what, and it slows your PFS down.
Lots of people have told me about the disappearing files problem on PFS and the disappearing dirs problem on SFS. Yet other people such as Piru swear that PFS is 100% reliable. So there must be something different between your system and Piru's to cause this problem.
Never underestimate the ability of reckless users to not wait at least five seconds after a write before rebooting or turning off their Amiga. It happens all the time.
In any event, there is at least one hack that causes problems similar to this no matter how long you wait; DiskSafe. Version 1.14 of DiskSafe causes copies involving many files at a time to fail silently without setting a return code. This happens with the shell copy command and with copies done by Installer. I don't recall if using Workbench to drag a drawer from one partition to another also failed, and I never tested multiple deletes. This was discovered on an A3000 using AmigaOS 3.1 and FFS.
-
Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm
@AMC258
You need to wait 3 seconds, or have some app send ACTION_FLUSH to the handler, flushing any pending writes immediatelly.
Hardly a real problem, you just need to be aware of it.
-
There are some reset handlers that can postpone reset up to 10 seconds when ctrl-a-a is pressed, some of them allow execution of commands or scripts too, but the case of pfs, just the 10 seconds wait should be cool enough. One such reset handler is kbd, written by an old friend of mine a long time ago :)
http://aminet.net/package/util/boot/KBD
-
Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm
This is for PFS3 right? Some of my Amigas do use PFS and when you write to the disk there is definitely a delay before the HDD light illuminates, probably 2-3 seconds as said. People should just be more aware that if you write to a disk then you should wait for the HDD light to illuminate and then deluminate before turning off. There have been times when I've forgotton this myself and thought 'what the hell? Where's my edits to the Startup-sequence?' :lol:
I use SFS too. Never have I ever seen missing dirs or files or any such strange magic on my Amigas. ChaosLord (God bless him) may have been onto something though regarding the software environment and all, should there actually be a problem with PFS that is, and not the users...
-
Anybody have a CLI util that does this? Not sure how hard it is to write. Failing any answers I'll see what I can find in regards to dev docs. Hmmm
DiskSafe does this for you. Note, however, that ACTION_FLUSH does not write out data immediately under FFS versions prior to 3.9. This particular bug was fixed, and DiskSafe includes a workaround for older versions.
What was stated above ("Disksafe invalidates copies") is something that would really surprise me because I'm using it on a daily basis. If you have a copy running, of course, and *then* reset the machine while the copy process is in progress, it will clearly abort the copy operation. That's the point because otherwise the copy might be aborted the hard way and the system could reboot before the copy is finished.
-
DiskSafe does this for you.
I notice that if I run LoadModule to load a module, and have workbench up and running, the icons for all the disk partitions turn into "NDOS" like icons for a brief moment before the system resets. Is this a similar "sync" like thing going on? And if yes, would it not be neat with a C:reboot that would do the same? :)
-
Is this a similar "sync" like thing going on?
Yes. DiskSafe first forcibly (sp?) closes all files, sends an ACTION_FLUSH to the file system, then waits for the file system to shut down motors (as a work-around against FFS versions < 44 ACTION_FLUSH not being synchronized as it should), then inhibits all file systems listed.
Ideally, this should really be part of a file system function (ACTION_SHUTDOWN or something like it), but it isn't.
And if yes, would it not be neat with a C:reboot that would do the same? :)
If the reboot goes through exec/ColdReboot(), then this is exactly what it does. ColdReboot() is patched to a small function which signals DiskSafe to take over and shut down the machine instead.
If, however, C:Reboot simply runs into a RESET instruction, then there is nothing I can do. It probably won't work in first place on a couple of machines anyhow. The reset instruction resets the external hardware, but not the CPU.