Porteus

Hi gang,

At least four times in the last two days, I've disturbed my thumb drive while running Porteus (and Win7 in VirtualBox, for that matter).

The result is something like a crash and (thus far) minor file system corruption. I'd like to minimize this risk.

I'm using EXT4 for Porteus and within an encrypted save.dat file.

Using EXIT with the changes cheatcode appears to be a robust option, but carries risk of loss of work. In the end, that's probably the way to go but I'd like to know if there is a practical alternative.

I've searched around and found some general advice, but not finding the zings (or even the proper files to modify) for Porteus. Note I was heavy into BSD a good 25 years ago, back when just about everything was in rc.local and I'm a bit lost since. Overlay and automounting filesystems were just getting a foothold as I turned my attentions away from UNIX.

So, a few questions:

1). Is there some underlying, possibly FS-independent way to make Linux tolerant of yanking and replacing the USB drive? I'd imagine you'd have to turn off the flash drive's internal cache, if any, but beyond that, file servers go up and down and lose and re-establish connectivity all the time, and even a PXE booted, diskless system will just wait until the resources are back online, as I recall. It's not too hard to imagine that similar functionality could be written in to the kernel (and possibly mount) to support any file system, or at least some cooperation between the kernel/mount/FS could be implemented. Has this been done, and how do I get in on it?

2) Is this issue reason enough to go with XFS, BtrFS, or some other more exotic FS over EXT4?

3) What, if anything, has already been done/tuned in Poteus (vs. most other out of the box Linux distros) to help with this problem? Where can these mods be examined or tuned further?

3) What FS specific parameters should I tune, and just as importantly: what Porteus files, command lines (w/in files) or options should be modified/added? Where can I find more info?

4) What special considerations might be needed to ensure that the filesystem within the save.dat file is also optimized against accidental removal? IE: answers to question #3 specific to save.dat files: what line(s) of what file(s) should I be looking at to modify save.dat mount parameters?

I've also noticed that from within Win7/Virtualbox guest OS, you can't optimize for quick removal or disable write caching. I wonder if there is some combination of Linux/mount options that will disable caching and make win7/Vbox aware of this fact, allowing for improved yank tolerance for Win as well. But that's a bit beyond the scope of this question, and I may find the answer incidentally while fiddling with basic FS options as implied above.

Thank you in advance for any insight! If an exhaustive discussion can't be managed, tips and hints appreciated.

-jeff

@jeff,

Using EXIT with the changes cheatcode appears to be a robust option, but carries risk of loss of work.
maybe you could use changes EXIT + cron job which would call 'dump-session' script every X minutes? or just run this script on demand ...

that should minimize the risk of loosing data

@fanthom:

Had thought about doing _exactly_ that, will try and most likely use this solution until and unless something more interesting comes along.

Certainly I'll be very curious to see how the system will react to the drive being yanked and replaced under these conditions. But unless EXIT actually unmounts the filesystem between dumps, I suspect default mount options will run interference by dropping the disk when accidentally removed and presenting it as new/dirty/cleaned when re-inserted: I anticipate some trouble "hooking up" with files (and their pending blocks) after such a "catastrophe." This behavior may be buried too deep for me to tamper with: indeed, there may be something about the USB or flash drive protocols that flat out forbid it.

On the other hand, I can't be the first UNIX head to think about this kind of thing so maybe there's a canned solution I'm missing.

Now I'm curious about unmount/mount penalties and if this approach is already incorporated in Porteus or elsewhere.

I might be able to harness some sort of cloud or RAID based solution as well but haven't thought much about it yet.

-jeff

@fanthom:

BTW, by "on demand" do you mean manually? If not please explain.

-jeff

I imangine that is meant by on demand is when desired, or when you decide to do it. This would be instead of every x minutes.

However, I do not see exactly what script you have to call. I imagine that you have an idea. If this is the case just write it down for the community.

Thanks.

francois wrote:
However, I do not see exactly what script you have to call. I imagine that you have an idea. If this is the case just write it down for the community.

Thanks.

/opt/porteus-scripts/dump-session

after some thinking:
replugging the usb where data are saved will create new node in the system so dump-session may not work correctly.
maybe you could tweak the script to find current device name (parse dmesg output) and dump the session on it?

please let us know if you got it to work.

thanks

@fanthom:

I'll fiddle with it some. I've been thinking about trying a mount:dump:unmount cron job, for example.

But you're closer to where the rubber meets the road.

I suspect the real problem is that it might be tough/impossible to ensure stateless behavior from a USB drive.

I've been thinking about it from an "absurd limits" perpective. I've come to the tentative conclusion that regardless as to what kind of script I come up with, I'll ultimately be left more vulnerable than if I just adjust the sync values to mount. Although I'm pretty skeptical, I hear ext4 is more resistant to corruption (due to power outages vs. earlier systems. A lot of this info has been anectdotal so I take it with a grain of salt. I didn't have any trouble for 15+ years when I lost power on my UNIX systems in the 80's and 90's: until I did.

That having been said, "background" and "soft" mount options might be handy to have for local disks much as they are for NFS mounted file systems.

Something I'll have to ponder on. I'm sure I'm not the first. It's porbably either been done, or there are very good reasons why it can't be done.

-jeff