Apologies if this has been raised previously, but all I can find is discussion of specific OSs, mostly relating to flash drives (where the issues are different). I'd like to limit this discussion to hard disks. Here's the best of my current understanding, but I'm not sure whether it's correct:
Journaling is desirable on the main guest filesystem, and on both the host vdi file and on any snapshot folders (the costs are low, and there are no undesirable interaction effects).
There's worthwhile speedup if you separate out swap into a separate guest partition and put it on a separate host partition with no filesystem, set up as writethrough (I've done this, and it seems to work well, for both linux and windows guests on linux hosts).
On linux guests, it might be useful to separate out /tmp and put it on a separate guest and host partition with writethrough and without guest journaling. The costs would presumably be longer fsck time at startup, and the need to reinstall the guest /tmp filesystem if corruption occurs. I haven't tried this, and don't know whether it's worth the effort. I'm not too sure how it would play with snapshotting.
Do any of the answers change if the host partition is on a RAID array or an LVM logical volume rather than a bare partitioned disk?
I see no benefit to having that discussion here. It is beyond the scope of VirtualBox, which works at a hardware level. At the guest hardware level there are no filesystems, journalled or not. What the host does with it's filesystem is the host's business, not VirtualBox's. Whatever filesystem you install in the guest is your business, not VirtualBox's.
At best your discussion is one for a general PC or Linux forum, but it has nothing to do with virtualization.
My apologies, mpack, it wasn't my intention to create a problem. Thanks for your reply, the implication of which is that there are no interactions between host and guest journaling, or other host filesystem characteristics (if there were such interactions,I'm assuming this would be the right place to discuss them, is that right?). This is useful for me to know, since I hadn't been able to figure it out for sure before - I'm probably not alone in this. It's useful to me to know that there are no possible negative interactions between host and guest journal recovery. It's also useful to know for sure that host and guest journaling are separately needed, that neither will cover for the other (I'd read this before, but wasn't completely convinced). Finally, it's also useful to know that there are no possible interactions between guest journaling and host RAID behaviour. I'll just relax and not worry about such issues in the future .
A virtual disk is just an ordinary file as far as the host is concerned. As such it will be managed however the host filesystem sees fit (different for different hosts). Files inside the virtual disk are not visible to the host. Files inside the virtual disk will be managed as the guest OS sees fit. VirtualBox itself doesn't know anything about files, just disk sectors A.K.A blocks in a host file.
Thanks mpack, I really appreciate all the effort you guys go to with these forums. However please forgive me, but I wonder if it's possible that I'm not explaining my point clearly enough. Of course you are right that when host and guest are behaving normally, there is little interaction between host and guest setup, and we don't need to worry about it, we can just optimise them separately. But journaling (and journal recovery) isn't about normal behaviour. It's only there to handle hardware abnormalities. Is it really so obvious we can ignore interaction effects when, by definition, neither host nor guest hardware is behaving normally? For example, suppose there is a recoverable disk failure while the guest (and therefore usually also the host) is writing. In that case, both host and guest will have corrupted filesystems. It's very clear that recovering the guest filesystem first would be a bad idea, because that would involve writing to an already-corrupted host filesystem, which risks making it irrecoverable. So in that case, clearly there is an interaction effect. In fact, we should recover the host filesystem first. I'm sure that's obvious to you - but I'm not so sure that it's obvious to all us mere mortal virtualbox users. What worries me more is whether there are any more such gotchas, in the complex interactions between journaling, RAID, LVM, snapshot rollback etc. My head hurts when I try to think about it. Some reassurance on this from the experts would be great...
A similar point relates to swap files. Just putting them on the same vdi as the rest of the system generally leaves them sitting on top of a journaling filesystem, in about the worst possible speed case for journaling. I've seen quite large speedups from reallocating the swap partition to a writethrough partition. But is it the only possible solution? Or is there some way to use the host swapping as an alternative way to provide additional memory pages to the guest?
Best Wishes
Bob
As I said above, the virtual disk is just a file as far as the host is concerned. That file can be recovered or repaired in the same way as any other host file. Once recovered I expect you wouldn't have to care too much about what additional protections the guest OS has. Although if the guest OS filesystem also has a robust design then that probably doesn't hurt.
I will jump in here to say there can be interactions between the guest file system and the host disk activity in one way that I have directly seen:
I have a Windows Small Business Server 2003 32-bit guest (amongst others) on a Windows 7 Professional 64-bit host. All of my guests use dynamic VDI disk files. The SBS2003 guest has Previous Versions enabled, where files within that guest OS that are marked as dirty and in need of backup are saved into some sort of database (maybe the journaling file system) so one can access previous versions of a file.
If I shut down the SBS2003 guest and I then clone & compact the VDIs (I've only used mpack's CloneVDI for this) immediately thereafter Previous Versions in the guest is hosed. All the present data is still there and completely usable, but all attempts to access previous versions of files datiing from earlier than the time I clone/compact the virtual drive result in errors and failure.
Not of course in the least implying that mpack's tool is in any way defective, I still use it all the time and never have any other problems, but there is something about re-arranging the chunks of data in the VDI from a tool on the host that messes up Previous Versions in my guest. (So I just save the original uncompacted VDIs for a few weeks until the previous Versions database rolls past the compacting date - no biggy.)
I don't know if this has anything to do with your journalling-filesystem concerns, urilabob, but I'd say, regularly back up anything you want to keep relying on, so if anything experimental does mess something up for you, you can recover easily.
That is a different discussion. Unlike VirtualBox, CloneVDI does care about the guest filesystem - though only when you ask it to compact, and you are basically saying that CloneVDI manipulates the guest filesystem incorrectly. That may well be true, but CloneVDI is not part of VirtualBox, it's just a third party tool (albeit one rather dear to my heart) which happens to be made available on these forums.
.