>> I personally like the block layer solution better and would be >> happiest if all unionfs and aufs users switched to it and no one >> needed union mounts. :) I think that the safety of personal data and the ability to make changes to the layers independently are very important features that justify union mounts. If you do block-level COW and then lose the lower filesystem layer (e.g. lose the LiveCD or lose network access to the NFS master), then you have no guarantee of being able to access the data you added (e.g. your /home) since you'll only have a corrupted "filesystem piece" that fsck may or may not be able to fix. Also, you can't modify the lower layer at all (without rebuilding the upper layer from scratch), while with an union mount minor changes can be done with no issues (e.g. replacing the LiveCD with a new minor update, or applying a security update to the NFS master), and major ones can be done with some care. Hence, in any case where the layers are even slightly separated, or where you need to modify them independently, or extract the changes, union mounts/unionfs are much better, and often actually the only viable solution. This includes the LiveCD case, the NFS mount case and some use cases with virtual machines. This would be the case even more strongly if additional features like online modification of lower layers, or path resolution to the most recent file instead of the one in the highest layer, were added. Of course, this is why people currently use unionfs or aufs, and a VFS-based solution seems just better, since it is going to be more efficient and guaranteed to be relatively bug-free once it satisfies the high quality requirements for inclusion in the core kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html