Encryption for 2.14

[PaulBx1]

Fsck takes me about 30sec with 512MB save file that has 93MB free in it.

Ah, so that is what is taking the time. It wasn't like that before the ext2 change. I hadn't noticed more than a couple seconds extra to fsck a non-encrypted pupsave. Must be the combination of encryption with fsck that's taking the time?

Barry had earlier experimented with the tune parameter that sets how frequently the file is fsck'ed. I talked him into just doing it every time. Well, that was a good choice with unencrypted pupsaves! Perhaps he can use the tune parameter only on encrypted pupsaves, to fsck only every 10 or 20 boots.

I don't think going back to ext3 is the right general answer; there were good reasons for getting away from it. However I believe users who want it can still go that route, right? The support is still there I think. Anyway I gave the option for an ext3 pupsave in the convert-pupsave script, and it seems to work. Convert-pupsave is available here:
http://www.puppyos.net/forum/?1170535852

[kirk]

That 30sec is with a non-encrypted pup_save file. Just a lot of little files in there. Ext3 worked very well for me. I'd crash quite a lot between video games and my battery going dead. Never lost any thing with ext3.

[John Doe]

I never had any trouble with ext3 either.

From memory I believe the basis of the problem which was presented was that if one had a journaled file system mounted as a loopback device on a non-journaled file system which happen to be in the process of being defragmented (or rearranged in some way) while one were accessing the loopback device something bad MIGHT happen to the loopback file system.

The only time I could even imagine this could happen is with a network puppy boot where the save file is on a windows share that was fat and it was being defragged.

Or maybe I misunderstood the problem, I didn't go back and read the thing again.

[BarryK]

Perhaps, if a user chooses to create a pup_save file in a ext3 or reiserfs hard drive partition, then Puppy could automatically make it a ext3 f.s. in the pup_save file. In all other conditions it will be ext2.
It would be easy enough to add this logic to the shutdown script -- and I would rather not offer the choice, want to keep everything as simple and automatic as possible.

[GuestToo]

i don't suppose it matters much ... a fsck repair of an ext3 drive is usually much faster than on an ext2 drive, and it is usually more likely to be able to fix the file system properly

i am using a pup_save.3fs file, because i upgraded it from Puppy 213 (or 212?)

i have never had any problems with ext3 either

i know that it has been said that there can be problems with journaled file systems mounted on loop devices ... personally, i have never noticed any problems with ext3 pup_save files, but that doesn't mean that there can't be problems

anyway, i don't think Puppy needs to force a full file system repair on every boot ... when the file system is created (ext2 or ext3) it was automatically configured to do a full file system check every 28 mounts or so, by default ... otherwise, fsck should just check if it was unmounted cleanly, and if it was unmounted cleanly, it won't bother to do a full file system check

so something like this should take less than a second or 2:

e2fsck -y -p pup_save.2fs

because it's not forcing a full file system check on every boot, on a file system that was unmounted cleanly

oh, by the way, i don't have any ntfs partitions, but for some people who do, the home partition might not be unmounting properly when Puppy shuts down ... i think it needs a fusermount -u command at the end of rc.shutdown, with the option to remount read-only, if necessary (i don't remember the read-only option ... -z?) ... because umount works on vfat but not on ntfs partitions

[BarryK]

If I recall correctly, fusermount doesn't have an option to remount read-only. That was the problem, and I think this is mentioned in the rc.shutdown script. I tried to do the next best thing, kill all processes running on the mounted ntfs partition and of course flush the f.s.

[BarryK]

Okay, it's done. Automatically it will be ext3 as mentioned in my earlier post. This can be tested in 2.16pre-alpha due in a few days.

[GuestToo]

according to the fusermount man page:

-z lazy unmount (works even if resource is still busy)

i'm not exactly sure what that means

it does say somewhere that you can force an unmount, like this: umount-FULL -f $FS and that it always works ... except when it has been lazy unmounted first

so maybe for ntfs drives, you could do something like this at the end of the shutdown script:

fusermount -u $FS || umount-FULL -f $FS

or maybe:

fusermount -u $FS || fusermount -z $FS

i don't really know, i do know that at least one person was complaining that their ntfs home dir seemed to be not unmounting cleanly, and the pup_save file always had some orphan inodes ... i don't even have any ntfs partitions ... oh, and i was wrong when i wrote e2fsck -y -p ... those options are mutually exclusive

in any case, i think it's better if the drives are unmounted, whether a lazy unmount or a forced unmount, because it often leaves an incorrect inode count from deleted files that were not completely deleted, which causes error messages, which bothers people, even though it is not a serious error

i don't care whether you use ext3 or ext2 ... i think i prefer ext3, i just think it is probably not necessary to force a full file system check on every boot ... an encrypted file system is probably easier to damage if the file system is not unmounted cleanly, but if it is unmounted cleanly, e2fsck should know and it should be ok to skip the full check ... and this is all done automatically with the one e2fsck command

[fudgy]

[...] that at least one person was complaining that their ntfs home dir seemed to be not unmounting cleanly, and the pup_save file always had some orphan inodes ...

hello, i think this person was me. The ntfs home dir is in the union-fs... so remounting ro would be probabely the best thing.
Isn't it possible to remove branches from the union and then unmounting them ? (I think Nathan F is already testing aufs, very interesting!)

i want to mention that Puppy is my working system for a year now and it runs at least 14h a day. So - relyability is one of the things i have an eye on.

- fudgy

[PaulBx1]

This is the tread where I dug out the information earlier:

http://www.murga-linux.com/puppy/viewto ... 53&t=13508