[..]
> To me this is like saying 'move everything into /usr but because its
> volitile move it back into /var but in a sub-directory from where it
> was so you can keep an image running.' In this case, this doesn't
> sound like any savings and more of a headache of why did it corrupt
> this time.
But this doesn't. Why would you need to move the rpmdb? Users probably
aren't installing rpm packages in containers at run time (particularly
if /usr is read-only); installation typically happens when building the
container image, at which point /usr isn't read-only.
This is all because none of the file systems available on Linux invented volumes properties.
+15 years ago on ZFS introduction on Solaris people had exactly the same problems and all those issues have been resolved by introduction of the volume property marking that exact volume needs to be snapshotted and cloned on making new boot env (global or non-global zone as well).
That issue is not limited only to rpm database content or generally /var content.
In case scenario when new boot env is created and on that new tree would be upgraded majost upgrade of the database engine which on first execution will change format of the database files you want to have some "backup solution" that in case if anything would go wrong you want to be able quickly be able back to original state.
In such cases new upgraded database engine binaries will be on /usr and let's say that database data on /srv/database.
To create new boot env in which not only / and /usr will be mounted from from exact clones all what needs to be done in case Solaris or Linux with ZFS would be mark volume mounted in /var that it needs to be snapshotted and cloned during created new instance of the bootable filesystems tree.
In other words trying to solve the multiple volumes mount problem by moving more and more to a single volume (because that is the easiest case) is pointless because it will solve only the rpm database problem but it will not solve issues of mounting multiple volumes.
Solving that kind of problems on top of all possible to use on Linux like systems is as well pointless because to solve such thing in civilised way it is necessary to have snapshotable FS which in case of linux for now is only btrfs (optionally zfs as well).
Volulumes properties stored in volume metadata inside storage pools solves much more use cases than only /, /usr and /var separation. From that point of view I really do not understand why btrfs developers resist to implement well known ZFS functionality.
In other words when btrfs will have possibility to possibility to describe a set of volumes which will be necessary to snapshot and clone on making new boot env volumes set SuSE will be rolling back move rpm database back to the /var where it should be.
kloczek
--