Can you mount two partitions on the same mount point?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Pardon me? I'm not flaming, and I'm not waving an e-peen. I merely put forward a suggestion; OP can take it or leave it.
Again: pardon? I never stated anything along those lines, nor intended to imply it.
Union mounts are very common in LiveCD/DVD/USB environments, and UnionFS and aufs are the two most prevalent in-kernel implementations of the concept for Linux.
A union mount allows multiple filesystems to be mounted simultaneously; the end result looks like a single filesystem, with a single mountpoint. This concept is commonly used in Unix-like operating systems; Plan 9 - Bell Labs' successor to Unix - makes extensive use of such filesystem combination, and is an awesome example of union mounts done right. There are multiple methods of implementing union mounts in Linux, two of them being UnionFS and aufs.
In the case of UnionFS, then - so long as your kernel supports it - you can easily make two filesystems accessible with one mountpoint:
mount -t unionfs -o dirs=/mnt/user-partition-1:/mnt/user-partition-2 none /home
mount -t aufs -o br=/mnt/user-partition-1:/mnt/user-partition-2 none /home
Both of the above assume that you've already established mountpoints for your two partitions that need to be mounted as /home.
There's also unionfs-fuse if your kernel doesn't include UnionFS or aufs and you don't feel like compiling kernel modules. That tool is also quite simple:
I'm not sure about the availability of any of these in Slackware, though I do know that Slax (which is based on Slackware) previously used UnionFS and now uses aufs as of version 6. Debian has both unionfs-fuse and aufs.
This is an excellent follow up post, thanks for providing information on your solution +1 rep. Again, lets all get along and try to help each other
without going into detail, I see two options for your 'merge'
lvm and btrfs
btrfs would be easier on a 'live' system,
assuming ext3/4 you can convert to btrfs, you would then remove the ext3/4 snapshot ( you now have a 'none-reversable' btrfs )
then add devices, bad example assuming home is sda1 and your extra partition is sda2
btrfs device add /dev/sda2 /home
in real life more complicated, since you should make backups etc.
the lvm route is probably considered more stable, I like btrfs but not documented as much as lvm
with lvm you would be best starting from scratch, I.e. backup everything. and then apply lvm
as initially stated, I offer no real detail
set aside some time to read about both lvm and btrfs and consider the pros and cons of each
hope that helps
PS in all honesty I would start from scatch with either lvm or btrfs
or even just go traditional ext4 with a sain partition layout, especially if you have only the one drive
Again, lets all get along and try to help each other
Originally Posted by dederon
This is offtopic, but: i really like this feature in plan 9. one consequence is, that you dont need a $PATH variable - just mount every directory, which contains binaries, to /bin.
Yup. You can also union-mount the /net directory with those of remote machines as a quick-and-easy way of implementing NAT, firewalls, VPNs, and other network goodness, too; you can do the same thing with /proc for distributed computing. Really cool stuff.
Originally Posted by moisespedro
The plan was: delete Windows partitions, merge it with /home partition.
Do you already have an existing /home? If not, then LVM would, in fact, be a good solution for this. Assuming the partitions are /dev/sda2 and /dev/sdb2...
pvcreate /dev/sda2 /dev/sdb2 # establishes the old partitions as LVM physical volumes
vgcreate LVM /dev/sda2 /dev/sdb2 # creates a new volume group with the above-created PVs
lvcreate -n home -L 20G LVM # creates a 20GB logical volume on the above-created VG
vgchange -ay # activates any available volume groups
mkfs.ext4 /dev/LVM/home # creates an ext4 filesystem on the above-created LV
mount /dev/LVM/home /home # mounts the above-created filesystem on /home
If you do, then the above steps are still useful, but you can replace the "mount" with a union mount like I've been advocating:
mv /home /opt/ # move your documents to a new spot
mkdir /mnt/extra-home # create the intermediate mountpoint
mount /dev/LVM/home /mnt/extra-home # mount the above-created LV
unionfs-fuse -o cow /mnt/extra-home:/opt/home /home # merge the above-created LV and your existing documents
This will overlay your newly-created LVM-based home partitions on top of your existing documents. The "-o cow" enables copy-on-write, which means that - instead of the old home being modified - any modifications to your files will take place on the new partitions. What's handy about this is that you can adapt this to hack together a quick-and-dirty snapshotting system for your /home (which - along with the ability to transform a read-only CD FS into a read/write FS for live environments - is another common use of union mounts).
It might be possible to skip the step involving the moving of your original /home; most of my own use of union mounts on Linux involves distinct filesystems being merged on boot, so I haven't played around with a command like "unionfs-fuse -o cow /mnt/extra-home /home" to see if it will do as asked (put differently: I don't know for sure if it will behave like Plan 9's "bind" command).
Alternately, it's probably better if you just move the entirety of your /home onto the LVM VG in your case. Depends on how much there is to move, as well as your existing /home setup.
Last edited by YellowApple; 02-06-2014 at 07:09 PM.