(old)Puppy Linux Discussion Forum

If you google for something like "journaling file systems" with "loop device" you see a lot of comments such as this one:

2.2. Use of journaling file systems on loop device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't use a journaling file system on top of file backed loop device. Device
backed loop device can be used with journaling file systems as device backed
loops guarantee that writes reach disk platters in order required by
journaling file system (write caching must be disabled on the disk drive, of
course). With file backed loop devices, correct write ordering may extend
only to page cache (which resides in RAM) of underlying file system. VM can
write such pages to disk in any order it wishes, and thus break write order
expectation of journaling file system.

http://loop-aes.sourceforge.net/loop-AES.README

This comment even claims it is dangerous to do so:

Absolutely - journaling filesystems depend upon the maintenance of
the order of device write operations. Where this is not the case, file
system recovery based upon the journal has the potential to be very
dangerous.

http://mail.nl.linux.org/linux-crypto/2 ... 00027.html

Thus journaling in a file-backed loop device (such as Puppy uses) has the potential to cause the very problem journaling was supposed to prevent!

This has nothing to do with encryption per se. It does turn up in encryption discussions though, because that is where file-based loop devices are often used.

I mentioned this on the other forum but it drew no comments. Is this something that should be re-thought? Should we be using ext2? Or am I completely missing some point here? I'm wondering if the operative phrase is "on top of", that is, the file system underlying the loop device can be journaling, but creating another loop device within, that is journaling, is the problem?

Well, we could go back to ext2.... it's easy enough to do, as a pre-
existing ext3 f.s. can be mounted as just ext2.

Too bad so many pup_saves are sitting on (non-journaling) FAT filesystem. Those sitting on ext3 or ntfs file systems can (I think) get the benefits of journaling from the underlying file system and thus could be mounted as an ext2 (and get better performance besides). But there is no such protection for pup_saves on a FAT filesystem.

But if what these guys are saying is true, there is no protection anyway.

All the above assumes I understand what they are talking about!

Maybe we should run pup_saves as ext2, and then tell people it is OK to leave the thing sitting on their FAT32 c drive but that it will have no more protection than any other file on that filesystem. And that the way to go is to create a small partition that is ext3 and put it there, if they want more protection. Of course then you don't really need the pup_save at all, but I like having it anyway for portability, backup, etc.

Or another thing would be to leave it on the FAT32 system but back up frequently (pup_saves are nice for backup). A simple script to automate that might be handy.

Here's another post that explains in more detail:

Jani Averbach wrote:
> Is there any way to mix loop-device (and in particular) loop-AES and ext3
> together in data journaling mode?

Device backed loops (ext3 -> loop -> device) don't have issues with ext3 or
any other journaled filesystems.

However, if loop is file backed (ext3 -> loop -> ext3 -> device), the
underlying file system must be mounted data=journal or data=ordered. If
underlying filesystem is mounted data=writeback or if it is plain old ext2,
write ordering expectation by journaled filesystem (ext3, reiserfs, jfs,
xfs, or whatever) on top of loop driver is not guaranteed, and journal
replay may corrupt data. Use of non-journaled file systems on top of file
backed loop don't have above mentioned write ordering issues, as they must
be repaired using fsck, not by replaying journal.

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

BTW, I have noticed when I decrypt my pup_save file, and go look at the file info with Rox, it says "Linux rev 1.0 ext3 file system data (needs journal recovery)". I don't know how it got that way, but anyway, with that warning above (that the journal can actually corrupt your filesystem if used for recovery), I am afraid to run a journal recovery on it!

As an experiment, I created an ext2 copy of my 512MB pupsave, and did a e2fsck on it. It took only a second! So, if I may be so bold, I'd like to suggest that for Puppy 213, the boot process should always do an e2fsck on any ext2 pup_save it is about to use since the journalling will not be there.

Being even more bold, we might advise (require?) everyone on the upgrade to convert to an ext2 pup_save, maybe make it part of the upgrade process. There will be the advantage of higher performance since journaling filesystems are slower than non-journaling filesystems.

<later>
Woops, doing an fsck on a non-encrypted pup_save is no big deal, but it ain't exactly trivial on an encrypted one <sigh>:
http://mail.nl.linux.org/linux-crypto/2 ... 00010.html
I'm guessing it would be slow too.

I'm wondering if the operative phrase is "on top of", that is, the file system underlying the loop device can be journaling, but creating another loop device within, that is journaling, is the problem?

Is this still problematic and could someone explain the issue in a "noob-friendly" language?

The latest pups all work great on ext3 or ext4 file systems.

Noob-friendly:

The device (partition on the drive where you store your pupsave) has a file system that is either journaling (e.g. ext3, ext4, ntfs) or non-journaling (e.g. FAT32 or ext2). The pupsave file has within it another file system also, either journaling or non-journaling.

Journaling file systems offer better likelihood of recovery when things go bad (e.g. power outage) at the cost of size and performance, and also faster wearing out of NAND based memory devices like USB flash drives.

The bad combination is having a pupsave with a journaling file system sitting on a device that has a non-journaling file system. I doubt there has been any change in this problem but don't know for sure.

It's hard to say if this is merely a theoretical concern or actual. If you are recovering from a power loss and the recovery goes bad, do you know why? Are you even aware of a bad recovery? People have run with the "bad" configuration for a long time and not complained of any problems. Nobody really knows the answer to this.

My advice these days is run it the way you want to run it, and don't worry too much about this problem - but back up your pupsave frequently. Personally I keep important stuff outside my pupsave so if it goes bad I don't care much, just make another one. I always use ext2 in the pupsave and on the device because I'm usually booting from flash drives. Also I have done several recoveries using e2fsck and it always worked; I think the rarity of disk writes in Puppy and in the general home computer environment helps here. Journaling may have a lot more application to big multiuser machines...

Another thing to do is run your machine on battery backup, which are getting pretty cheap these days. I should follow my own advice.