data loss by improper unmount of savefile

[kirk]

Some minutes ago I received a EMail about a corrupted save-file of Puppy 2.17.
Maybe the fscheck was removed at that version already?

If I remember right, 2.17 did not run fsck. If you use a ext2 pup_save, fsck on boot is a must. If you switch to ext3, then it not needed. Puppy 3 does run fsck at every boot and should not have problems. I haven't had any problems with seamonkey.

[MU]

Puppy 3 does run fsck at every boot and should not have problems. I haven't had any problems with seamonkey.

Do you have 3.02?
In 3.01 (base for Muppy) I had to add a check to initrd.gz.


Beem,

As is done in alpha 7 (and before already)

yes thanks, good to know it is back again

Mark

[MU]

Kirk,

If you switch to ext3, then it not needed.

At moment I run tests with ext3 and fsck.ext3, and it fixes the lost inode-entries at startup.
I don't know how the journaling mechanism works, but at moment I think it might be better to run the check, just to be shure.
Restoring from a journal is fine, but a real cleanup of the filesystem might be "cleaner"?
I might exagerate it a bit now, but when I saw how just the deleted inode-entries could completely confuse unionfs as described above with fixmenus, I now am somewhat paranoid

Also, a journal has just limited size, especially in small filesystems like .2fs.
So it might easily "overgrow" with heavy disk-usage like from a database I fear.

Thanks for any suggestions though
Mark

[Béèm]

Hi Mark, while we are at the pup_save issue, I have a side question.
Having heard (well read) different stories about the max size of the pup_save, I didn't find the correct info and I am confused.

When resizing the pup_save file there is a remark about 1,8GB, but kinda unconfirmed.

Others say it depends on the file system used, so being different for fat16, fat32, ext2, ext3 or reiserfs.

Do you know more about this?

[MU]

Salut Bernard,
you can create a second one, and try it yourself.

Boot from CD wth
puppy pfix=ram

So you can create a new one with a different name.
Then resize it.

I had one in Puppy 1 with over 1.8 GB on a fat32 partition.
-rwxr-xr-x 1 root root 2040074456 2007-02-04 16:21 pup003

I think old windows filesystems have limits.
I was not able to extract an archived forum with 240.000 messages in one folder in fat32,but in ext2 it was no problem.

This might help to find out the limits:
http://en.wikipedia.org/wiki/Fat32

Mark

[Leachim]

I had some strange problem using ext3 with aufs. (I do not know whether this will occur with unionfs, too.)

Whenever a process ended up in "disk sleep" state then all its in-use-files (and directories!) seemed to stay in a locked state. So any other process (e.g. the save-script!) accessing one of these files or directories entered "disk sleep"-state, too!

With ext2 the same "disk sleep"-situation did not cause any other process to hang. Since I returned to ext2 everything looks stable again.

[floborg]

For very important data (this is all user generated data) I do not rely on unionfs. E.g. /root/.mozilla is a symlink to a place outside the savefile on my system. Other experienced Puppy users do it the same way. This has a couple of advantages: You can reuse your data in various places, the savefile does not need any repairing and firefox (1.5 + 2.0.0.11) never forgets something.

I love it! Just put it into practice on a fat32 partition. Keeping my fingers crossed. Now, I'll be able to determine who is at fault for the missing cookie problem, Puppy or Seamonkey.

Well, this went nowhere. Somehow, Puppy began thinking /mnt/home was read-only while .mozilla was on it. I had to delete it from Windows. The home partition I use is fat32.

[PaulBx1]

One of the geeks said ext3 does not make any sense in a squashfile - but I never understood exactly why. Does anyone remember this subject ?

Well, I don't think of myself as a geek, but I think I am the one at fault. As I wrote in another post, "In theory you shouldn't have a journaling (e.g. ext3) pupsave filesystem over an underlying non-journaling disk file system..." This came up in researching encrypted pup_saves although it has nothing to do with encryption per se.

There was also another set of discussions about using ext2 vs ext3 or reiserfs as the underlying filesystem in full installs, with some folks reporting the journaling filesystems simply not working. This is unrelated to the other.

I have had problems with ext2 filesystems just stopping working, myself. Last time it stopped recognizing the keyboard in my laptop and started printing multiple characters on the screen, who knows why. I might try ext3 to see if that is any better even though it violates the theoretical prohibition mentioned above.

I think we should just blame it all on unionfs.

In the meantime, backups are good to have. Too bad pupsaves are somewhat inconvenient to backup (requires reboot into ram) which means it doesn't get done as often as it should. Maybe we should start a poll here: "How long ago did you back up your pupsave?"

[urban soul]

I love it! Just put it into practice on a fat32 partition.

Of course you may want to use the same filesystem (eg. one which supports permissions natively) as inside the savefile! BTW /mnt/home is not a real directory. Did you know that? Avoid doing 'nasty' things with your computer while we are discussing other things here...

All these spooky observations don't tell me nothing about what is going on really. To cleanly unmount drives one has to go the setup progress backwards: remove branches from the union, pivot root, ramdisk, shutdown. Removing ('hotswapping') branches was a topic erlier on the forum when it was announced by the unionfs mailing list. It was announced several times though.

It will come. Just wait six month.

[Béèm]

Salut Bernard,
you can create a second one, and try it yourself.

Boot from CD wth
puppy pfix=ram

So you can create a new one with a different name.
Then resize it.

I had one in Puppy 1 with over 1.8 GB on a fat32 partition.
-rwxr-xr-x 1 root root 2040074456 2007-02-04 16:21 pup003

I think old windows filesystems have limits.
I was not able to extract an archived forum with 240.000 messages in one folder in fat32,but in ext2 it was no problem.

This might help to find out the limits:
http://en.wikipedia.org/wiki/Fat32

Mark

Bonjour Mark, Merci pour la réponse.

I should have thought to make a try on a copied pup_save. When crashing there is no harm.
4ill make the test and might push eventually a bit.

Bernard

[MU]

Muppy meanwhile uses ext3 as filesystem in the savefile, and in addition runs fsck.ext3 at startup.
This solved several issues, we still encountered problems though.

Firefox freezed after a while, especially, if you ran several other applications.
Also Wine (Internet Explorer) showed such behaviour.

I think, Barry cannot reproduce this, as Puppy is much smaller than Muppy (100 MB vs 600 MB).
Maybe unionfs gets "broken", if a certain amount of files is reached.
The solution seems to be pretty simple:
use "aufs" instead.
More:
http://murga-linux.com/puppy/viewtopic. ... 675#203675

Mark

[Dingo]

So, I, booting Puppy 3.01 from CD can use aufs instead unionfs typing these lines at boot screen?

puppy layerfs=aufs

[MU]

Yes, this should work.
I just tested it with the Grub entry myself.
You can check it like this:
after you booted with that option, type in a consolewindow:
lsmod

You now should see such a line:

aufs 105988 1

Mark

[Dingo]

Thanks, now I will try. if fully working it's a way to avoid to typing this command

puppy layerfs=aufs

any time I boot from CD?

[MU]

Thanks, now I will try. if fully working it's a way to avoid to typing this command

puppy layerfs=aufs

any time I boot from CD?

No, I don't think so.
I have no knowledge, how syslinux works, or other ways to boot a CD.
So I must look at this until weekend, so that I can modify Muppy to use aufs as default.
It might be required to patch initrd.gz for this, so that it is fooled to believe, that the option "layerfs=aufs" was passed by the boot-mechanism.

I will add a note on how I changed it, when it is done.
Mark

[MU]

ok, concerning the CD it should be easy.
I am not sure, but this might work:
Copy all files from the CD to a folder called "iso-files".
Then edit isolinux.cfg
from:

Code: Select all

append initrd=initrd.gz pmedia=cd

to:

Code: Select all

append initrd=initrd.gz pmedia=cd layerfs=aufs

Then rebuild the iso:

Code: Select all

mkisofs -o test.iso -l -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table iso-files/ 

Mark

[jcoder24]

Thanks, now I will try. if fully working it's a way to avoid to typing this command

puppy layerfs=aufs

any time I boot from CD?

1. mount the iso and make a copy of isolinux.cfg
2. edit isolinux.cfg and add layerfs=aufs to the end of the line that starts with append
3. use isomaster to delete the old isolinux.cfg and add your new isolinux.cfg
4. burn the updated iso

[MU]

yes, works with that entry, just tested it with qemu.
I checked it with "lsmod" without running X, as qemu is very slow on my 256 MB machine.
Mark

[Dingo]

I have tried booting from CD with option

puppy layerfs=aufs

typing lsmod aufs is showed as running, the system works fine, the speed is pratically the same, all seems work better and more fine, I think that next days I will biuld my custom ISO adding this boot parameter

[urban soul]

Maybe unionfs gets "broken", if a certain amount of files is reached.

I use unionfs with 1GB in the union (3.02alpha1.sfs, muppy8.sfs, kde3.sfs, devx.sfs) and I don't have problems with it. It would be a very poor design if unionfs fails at 1GB, if so.

I see severe problems with unionfs and (the various flavours of) ntfs, however.

Urban