1. The great thing about the way I use my Puppy Linux:
Stuff loaded to RAM from the [Puppy "live" optical disk, and also the] pupsave file runs in RAM.
My Puppy is set up to NEVER auto-save session changes. [ I REALLY LOVE THAT. ]
Neither during the session, nor at shutdown/reboot.
So changes made during a session are never copied back to the pupsave unless I choose to do it manually by clicking on the "Save..." icon on the desktop.
That means:
a. Screw-ups [or ANY changes, like saved super cookies] are normally LOST at shut-down/reboot.
b. An improper-poweroff causes no problem, because it only causes a loss of whats in RAM; it is most unlikely to catch a manual copy-back in mid flow, because copy-backs are most infrequent events.
Hence, no corruption of what's in the pupsave file, and also [of course] no corruption of the Puppy files on the opical disk.
c. Hence, I could never suffer the loss of file content, or am I wrong?
2. What if I had [for example] a text document open and in use...
Whilst that document was held somewhere outside of the pupsave file.
What would happen to the file at improper poweroff?
File corruption at "Improper poweroff"?
Re: File corruption at "Improper poweroff"?
Power loss - You will suffer data loss of anything that you moved/ copied/downloaded to / or /root of the running system (effectively to the save file) if you haven't saved it during the session. Data that was transferred to a location outside the save file like /mnt/home for example will not be lost. The file outside the save file (an existing one) will remain in its original state (like before you started the session) but any changes to it will be lost if you haven't saved it. You will lose the text file if it is a totally new one you are creating and you have not saved it yet. When you are working on a document, it's a good idea to use a decent word processor program that has a back-up feature. You can enable this feature to backup your work after certain intervals (eg. Every five minutes) so if you have a power outage you will at least have the last backup file to fall back on.Sylvander wrote:1. The great thing about the way I use my Puppy Linux:
Stuff loaded to RAM from the [Puppy "live" optical disk, and also the] pupsave file runs in RAM.
My Puppy is set up to NEVER auto-save session changes. [ I REALLY LOVE THAT. ]
Neither during the session, nor at shutdown/reboot.
So changes made during a session are never copied back to the pupsave unless I choose to do it manually by clicking on the "Save..." icon on the desktop.
That means:
a. Screw-ups [or ANY changes, like saved super cookies] are normally LOST at shut-down/reboot.
b. An improper-poweroff causes no problem, because it only causes a loss of whats in RAM; it is most unlikely to catch a manual copy-back in mid flow, because copy-backs are most infrequent events.
Hence, no corruption of what's in the pupsave file, and also [of course] no corruption of the Puppy files on the opical disk.
c. Hence, I could never suffer the loss of file content, or am I wrong?
2. What if I had [for example] a text document open and in use...
Whilst that document was held somewhere outside of the pupsave file.
What would happen to the file at improper poweroff?
Busy today.... 
Thee demon of corruption is during writing basically..... powerloss during a write be it file data or the filesystem indexes will cause losses... a journalled filesystem is designed to help with this by repeating any actions not completed during a power off.
Just to mention with my sfs save system I make the new save sfs BEFORE deleting the old one so if power loss occurs at shutdown there will still be a valid uncorrupted save either way...either the previous one or the new one. So a little scripting can make life a little more robust.
The save file is less protected since its permanently mounted so a journalled filesystem helps.
Saving data outside of any systems filesystem is a good idea for various reasons.
mikooooo
Thee demon of corruption is during writing basically..... powerloss during a write be it file data or the filesystem indexes will cause losses... a journalled filesystem is designed to help with this by repeating any actions not completed during a power off.
Just to mention with my sfs save system I make the new save sfs BEFORE deleting the old one so if power loss occurs at shutdown there will still be a valid uncorrupted save either way...either the previous one or the new one. So a little scripting can make life a little more robust.
The save file is less protected since its permanently mounted so a journalled filesystem helps.
Saving data outside of any systems filesystem is a good idea for various reasons.
mikooooo
@mikeb
1. "Thee demon of corruption is during writing basically..... powerloss during a write be it file data or the filesystem indexes will cause losses..."
That's what I thought.
2. "...a journalled filesystem is designed to help with this by repeating any actions not completed during a power off."
How can it help IF....
The action interrupted was a copy back from RAM to the [contents on the] pupsave file?
When the contents of RAM have been lost, how can the action be repeated?
3. "Just to mention with my sfs save system I make the new save sfs BEFORE deleting the old one so if power loss occurs at shutdown there will still be a valid uncorrupted save either way...either the previous one or the new one. So a little scripting can make life a little more robust."
I wonder whether my old brain would be capable of grasping the concept and method you are using?
I like to keep things no more complex than my mind can grasp. [I like K.I.S.S.]
4. "Saving data outside of any systems filesystem is a good idea for various reasons."
Such as?
@nic007
5. " The file outside the save file (an existing one) will remain in its original state (like before you started the session) but any changes to it will be lost if you haven't saved it."
GOOD!
I deduce that file corruption would only happen if a write-back of such a file was interrupted.
1. "Thee demon of corruption is during writing basically..... powerloss during a write be it file data or the filesystem indexes will cause losses..."
That's what I thought.
2. "...a journalled filesystem is designed to help with this by repeating any actions not completed during a power off."
How can it help IF....
The action interrupted was a copy back from RAM to the [contents on the] pupsave file?
When the contents of RAM have been lost, how can the action be repeated?
3. "Just to mention with my sfs save system I make the new save sfs BEFORE deleting the old one so if power loss occurs at shutdown there will still be a valid uncorrupted save either way...either the previous one or the new one. So a little scripting can make life a little more robust."
I wonder whether my old brain would be capable of grasping the concept and method you are using?
I like to keep things no more complex than my mind can grasp. [I like K.I.S.S.]
4. "Saving data outside of any systems filesystem is a good idea for various reasons."
Such as?
@nic007
5. " The file outside the save file (an existing one) will remain in its original state (like before you started the session) but any changes to it will be lost if you haven't saved it."
GOOD!
I deduce that file corruption would only happen if a write-back of such a file was interrupted.
I think you will find that just about EVERY file system saves the new copy and checks it before changing the pointer to it from pointing to the old one.3. "Just to mention with my sfs save system I make the new save sfs BEFORE deleting the old one so if power loss occurs at shutdown there will still be a valid uncorrupted save either way...either the previous one or the new one. So a little scripting can make life a little more robust."
I wonder whether my old brain would be capable of grasping the concept and method you are using?
I like to keep things no more complex than my mind can grasp. [I like K.I.S.S.]
The only time that data loss should occur (when updating) is if the power loss just happens during the minuscule time it take to change the pointer.
"Just think of it as leaving early to avoid the rush" - T Pratchett
well I was not referring to this rather to saving to partitions outside of the puppy system.The action interrupted was a copy back from RAM to the [contents on the] pupsave file?
When the contents of RAM have been lost, how can the action be repeated?
In the case mentioned here then yes it would be lost if the intitial write never made it to the save file journal. By the same token my save sfs would not get the data if the powerloss happened during writing...but in either case the resultant filesystem would remain uncorrupted and the only data affected would be the lost file.... ie no joke funnies like losing the pinboard and unrelated corruption. The journalling idea is to complete half finish writes if possible but primarily to preserve the healthy state of the filesystem as a whole if that makes sense.
The save sfs is a about half a dozen lines of code.... it actually took more effort to include it in the save options.
Saying that I did not try to implement it with the puppy 4+ code as i deemed it far too messy to work with...having seen the fun and games adding a save folder this confirms my reluctance...instead I use code based on puppy 2....simpler and works fine.
4..... fragmentation for one.... makes a big difference having windows and a separate data partition for example.
In puppy case there is the save file space limitation, speed of shutdown for usb, corruption considerations...ie this topic,
Easy of system changes...can wipe / reinstall the system leaving data alone.
Simpler backup stratergy.
eggs in one baskets syndrome really.
mike
save file on fat?I think you will find that just about EVERY file system saves the new copy and checks it before changing the pointer to it from pointing to the old one.
... but effectively if a file is being rewitten and power is lost during the event what do you end up with?
And what about the case of several files and perhaps within a single partition image... is this a sequential event?
Puppy save file corruption is common so it seems with the standard setup life is not that predictable....I assume motivation for this topic.
Perhaps you would indeed end up with the old file on ANY system though my aim was to be certain that the new file was 100% valid before removing its predecessor rather than simply overwriting and possibly ending up with nothing or a corrupt file. Just seemed prudent to handle the creation of a new file as a separate event to deletion of the old one. A bonus would be if renamed rather than deleted you have an instant backup.
Well a subject worth discussion anyway.
mike
I think we sort of a gree there .... so really its about getting files safely from layered filesystems with tmpfs into something more solid and predictable. Must say over the years inspite of powerloss and lockups I don't recall loosing files except from FAT partitions (unless you count those recovered fragments that never seem to help) but can definitely not say the same about save files.
In this specific case any interruption in the process of saving a file from tmpfs/ram is pretty much going to result in its loss.... but at least the host partition stays healthy and the loss is ONLY from the current session ...my save file allergy is that corruption can result in loosing everything....more pain.
I never bothered to implement it but a save sfs could be made at any time.... only fiddly bit is puppies pointless .xloaded i believe interfering with a reboot.
Another specific point is with usb mode the save file IS mounted though only gets writes during those save periods. (they used to crash out when I was using the GIMP...I removed that mode altogether )
mike
.... so really its about getting files safely from layered filesystems with tmpfs into something more solid and predictable. Must say over the years inspite of powerloss and lockups I don't recall loosing files except from FAT partitions (unless you count those recovered fragments that never seem to help) but can definitely not say the same about save files.In this specific case any interruption in the process of saving a file from tmpfs/ram is pretty much going to result in its loss.... but at least the host partition stays healthy and the loss is ONLY from the current session ...my save file allergy is that corruption can result in loosing everything....more pain.
I never bothered to implement it but a save sfs could be made at any time.... only fiddly bit is puppies pointless .xloaded i believe interfering with a reboot.
Another specific point is with usb mode the save file IS mounted though only gets writes during those save periods. (they used to crash out when I was using the GIMP...I removed that mode altogether
)mike
I have my Puppy [Slacko-5.7.0-pae] set to treat the pupsave on the internal HDD as though a pupsave on a Flash Drive.mikeb wrote:...with usb mode the save file IS mounted though only gets writes during those save periods.
Hence there is a "Save..." icon on the desktop.
But I have it set to NEVER autosave...
And also to ask at shutdown/reboot if I want "to save or not to save"...
With the default as "Don't save".
Hence it never saves unless I choose to do so manually, and 99.9+% of the time I don't do so.
Yep...just pointing out the setup with usb....the save file is sort of dormant really just providing previous sessions data to be read.
Must say I never found a need for intermediate saves.
Data is something that gets saved to a hard drive...or dropbox, or sent as an email. In other words the most I would lose is a browser bookmark I suppose. (though I tend to email those now so accessible from anywhere )
mike
Must say I never found a need for intermediate saves.
Data is something that gets saved to a hard drive...or dropbox, or sent as an email. In other words the most I would lose is a browser bookmark I suppose. (though I tend to email those now so accessible from anywhere
)mike
Puppy has a nasty habit of leaving saved data in memory for quite some time before writing it out to usb. Any power loss during this delay results in corruption or complete loss of that data. This appears to be true even when writing to an external disk that does not contain the savefile. (ie: it is not just the pupsave timer that creates this delay)Burn_IT wrote:The only time that data loss should occur (when updating) is if the power loss just happens during the minuscule time it take to change the pointer.
I have found it necessary to manually issue a 'sync' command to force the 'write to external disk' to complete. It is interesting to watch how long it takes before the command prompt reappears after issuing a sync command when copying a large file to a slow usb stick. Interesting also to see that the sync is sometimes immediate - indicating the write already took place, and seeing that it is sometimes slow - indicating that the data was just sitting there in ram, queued but not going anywhere.
Lately I have been using 'Live" puppies extensively and testing the risks to data stored on external disks. I think the key to data integrity is to ensure that a 'sync' is performed, and that the shutdown waits for the sync to complete. When I am running Live I do these functions manually now.
eg:
- sync
- unmount all
- shutdown
Normal puppy shutdown is designed to do all this - but I just don't know how well it works in every pupmode.