Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Unix Operating Systems Software

Unionfs for Linux? 41

Lukey Boy asks: "A machine in my network is currently a large fileserver, and holds many hard disks full of media (namely my music and what not). Each drive is running a standard EXT3 filesystem with the same layout (/media, /media/mp3, and so on). My problem and question is how do I join these drives to look like a single hierarchy? I would like to, when I check /all/mp3, view the contents of each drive in this combined directory. FreeBSD has a unionfs filesystem type which supports the unioning of two drives - but only two is a fairly bad limitation, especially when I add a new drive. It appears that Al Viro is working on a unionfs for Linux 2.5, with again only two mount points supported. I was also considering using the Linux Volume Manager system, or possibly a software RAID striping arrangement; does anyone have any experiences doing anything similiar? Is there any decent inheritable filesystem (IFS) available for Unix machines?"
This discussion has been archived. No new comments can be posted.

Unionfs for Linux?

Comments Filter:
  • I belive that this is what the Mosix file system does. You can find out at the Mosix website (sorry I don't know the URL off the top of my head).

    Of course, you could always port unionfs ;)

  • by 0x0d0a ( 568518 ) on Saturday September 21, 2002 @07:02PM (#4304836) Journal
    This is *exactly* what LVM is designed to do. Multiple physical volumes comprising one logical volume. Follow up on your own suggestion. :-)
    • I believe he meant under the one mount point.
      • by |_uke ( 158930 ) <thealterself@hotmail. c o m> on Saturday September 21, 2002 @07:59PM (#4304984) Homepage Journal
        So does the previous poster. LVM is great because it virtualizes the hardware side of things. A volume (virtual partition) can be spread out over any number of drives. I was using LVM a while ago, it works quite well.

        The only real problem is volume resizeing. Although LVM has great support for resizeing the actual volumes, there is always a little trickery involved with resizeing a filesystem ON those volumes =)

        Anyways, I believe LVM is now part of EVMS.

        I would give it a try, LVM is quite cool to use. I was using it when I had to switch all my drives around on a regular basis. Its nice to have a single device for my root partition and not have to make large changes to fstab and whatnot just to get my system to boot =)

        (Now with a stable drive layout, I am back to using normal partitions... but thats just because I was too lazy to setup LVM again =)

        BTW, nice nickname Lukey Boy :P
        • by Polo ( 30659 ) on Saturday September 21, 2002 @08:28PM (#4305084) Homepage
          I believe resizing with LVM is quite easy now. The command is e2fsadm and it knows about both ext2/ext3 and lvm.

          Although LVM doesn't join two filesystems at the directory level, what it will do is allow you to have separate disk partitions and allocate and deallocate space from them from a pool made of of all your physical disks.

          You can still have your /usr and /var (or /music or /video), but you can also add a new disk and give 20% of it to /music and 60% to /video and leave the rest unallocated for later. Or maybe shrink /music by 10gig and give it to /video.

          I'm using redhat 7.3 and lvm is included. The only problem was that I didn't know how to load the lvm module at boot time. In the end, I mucked with /etc/rc.d/rc.sysinit to change this line from:
          if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then
          to:
          if [ -x /sbin/vgchange -a -f /etc/lvmtab ]; then
          and everything worked fine.
        • I use LVM with reiserfs on all my boxes - resizing both the volume and the filesystem is easy. For instance, if I want to grow my MP3 volume by 10G: "umount /riaa; lvextend -L +10G /dev/quadcuda/riaa; resize_reiserfs /dev/quadcuda/riaa; mount /dev/quadcuda/riaa /riaa". Done. Shrinking is just as easy, but in that case the filesystem resize happens before the volume resize instead of vice versa.

          Looks like you could do the same with ext2 and resize2fs if you wanted. If I recall correctly, when I set up my first box with LVM, resize2fs had lots of "beware, this is somewhat experimental code" warnings and I was reluctant to use it, which was one reason why I used reiserfs instead. Maybe a couple more years of testing have increased confidence in the utility, since those warnings aren't there now. I'd rather use reiserfs anyway.
          • You can resize ReiserFS volumes online!

            lvextend -L +10G /dev/tardis/stash
            resize_reiserfs /dev/tardis/stash

            There's no need to unmount a volume before growing it. You still have to unmount it before shrinking it, though; resize_reiserfs will refuse to work if you don't do so.

    • I think you're right. I'll probably go with LVM, it looks fairly stable now (I've looked into it a while ago, and it was a little unstable - problems with the device-mapper).
    • If I understand LVM correctly, it doesn't do what the poster wishes. It will allow him to choose which logical subdirs reside where, but not have all his files everywhere.

      It seems like a distributed filesystem, like InterMezzo [inter-mezzo.org] or Coda [cmu.edu] would be a better match. That way his files are everywhere and the fs automatically manages updates regardless of where changes are made - including after disconnected operation.

    • The bad thing about LVM is something I've experienced first hand. Harddrive failiure. I lost 200G of data because the first disk on a LVM failed and took the others with it. Since then I've stayed away from it.

      Otherwise it's a nice system though. But I'd say use RAID5 to create redundant storage, then use LVM to put these together into one logical unit.
  • I'm not quite sure, but I think this is one of the things CXFS [sgi.com] is trying to do. Now if I could only connect to the SGI site...
  • symlinks? (Score:1, Informative)

    by Erebus ( 13033 )
    rm /all/mp3/*
    for f in /media/*
    for g in /media/$f/*
    ln -s /media/$f/$g /all/mp3/$g
    done
    done
  • Comment removed (Score:4, Informative)

    by account_deleted ( 4530225 ) on Saturday September 21, 2002 @07:22PM (#4304890)
    Comment removed based on user account deletion
  • there's an old joke about a guy going to a doctor who complains that it hurts when he holds both his arms above his head and yodels. (or something like that) the punch line?

    don't do that.

    unionfs with two fs's really isn't all that great idea. and no offence, but unionfs with more then two fs's is monumentally stupid. where do new files get created? how do you deal with conflicts? what happens with files that you edit? what if you remove a file that exists on more then one fs?

    there are a slew of different answers to these questions so either the kernel inflicts (and yes, i mean inflicts) policy or you have to provide a way to configure all those options. should mounting fs's get as complicated as firewall rules?

    there are lots of solutions to your problem. pick one of them rather then a bigger problem.
    • In most IFS projects, the upper layer accepts new files while the lower layers are generaly mounted read-only.


      Besides, telling me not to do it - what's with that? Everyone knows the Perl motto - there's more than one way to do it. Unix is the same - look at all the different variants out there.

      • what he's saying is that unionfs is not the way to do it here.

        what he wants can easily be done with regular old mounts, eg he could sort his mp3s into 'classical', 'jazz' etc.. and have each one in a seperate dir and on a seperate disk. or he could symlink into the various disks. finally the most transparent way to merge the disks into one is LVM.

        --paulj
    • unionfs with two fs's really isn't all that great idea. and no offence, but unionfs with more then two fs's is monumentally stupid. where do new files get created? how do you deal with conflicts? what happens with files that you edit? what if you remove a file that exists on more then one fs?

      I think a union/overlay/translucent filesystem is a natural and useful construct. I think having N readonly layers below one writable layer is as intuitive as for 1 readonly layer.

      I dont think problems with name conflicts are necessarily much worse than having to map to 8.3 names, or names which differ only by case on a filesystem which is not case preserving.

      Having to choose whether or not to have copy on write, or choose a z value for each layer, does not seem like a problem which makes the cost of overlay filesystems more than the benefit.

      Larry
    • Witty. Constructive. +4.

      I like it. Not.

      If "there are lots of solutions" to the problem, showing at least one of them would perhaps turn outright discouragement into something useful.

      The problems are obvious. And they have been solved for a long time - witness TVFS under OS/2. Does something similar exist for a free OS? LVM might be close.

      Mounting filesystems should be no more nor less complicated than is needed to achieve the desired goal. If this means that it's "as complicated as firewall rules," so be it.

      Seems that this is already the case, anyway. I've got three lines of firewall rules. The fstab on the same machine trounces that handily, without doing anything creative or silly - just mounting various partitions to various points.

      (and before anyone asks how it can possibly be secure, I'll say this: It's -STABLE, and that's good enough for me.)

  • if they can be chained...

    For example, maybe you have

    /dev/hda1:/media/mp3 as /tmp/a/mp3

    /dev/hdb1:/media/mp3 as /tmp/b/mp3
    /dev/hdc1:/media/mp3 as /tmp/c/mp3
    /dev/hdd1:/media/mp3 as /tmp/d/mp3
    ...
    /tmp/join/a unions /tmp/a/mp3 and /tmp/b/mp3
    /tmp/join/b unions /tmp/c/mp3 and /tmp/d/mp3
    /all/mp3 unions /tmp/join/a and /tmp/join/b

    Mind you, I haven't looked at whether any given unionfs implementation would support this configuration, but loopback-type support typically isn't hard.

    As as aside... wherever I type "space slash", slashdot eats the space, making the above a little harder to read than it should be. Anyone know why that is, and/or a workaround?

    • / / / / / You could always use monospacing / / / /

      / / / / / The space eating has nothing to do with Slashdot, it has to do with font Slashdot uses (Times New Roman is the default, if I'm not mistaken). Go ahead and type " /" in your word processor of choise and it will have the same effect in TNR, Aral, Georgia, MS San Serif, etc. / / / / /

  • Thanks for the suggestions everyone, some of the ideas look pretty decent!
  • how about organizing your files so you dont need some exotic system?

    use LVM and make one large volume, create /media /media/mp3 /media/video /media/images ...etc..etc..

    very easy, very simple..
  • One insanely great use for a union filesystem would be fully usable, ramdisk-free systems that boot from CD-ROM. Union mount a ramfs over the iso9660 filesystem and you end up with the same semantics of a normal system, but without all of the wasted memory of ramdisks. This would be great, but I think only the BSDs have this. The only patches I found for Linux dated back to like 1997.
    • You can do this with User-Mode Linux. Just put your root FS on a CD (you can even make it ext2 instead of iso9660), and then use UML's copy-on-write filesystem driver. Put the COW file in a ramdisk on the host OS. Voila!

      I actually plan to implement just such a hack so I can use UML jails more safely on services, and still do useful things that need the occasional temporary file. (I don't think I'll put the COW file on a ramdisk specifically, but I will delete it post-use.)

      --Joe
    • What about using it with Wine ?
      You could have a single image of the Windows filesystem, then keep multiple overlays, each containing the changed files for that instance. This would keep multiple virtual Windows systems going in their own jails, making it easier to recover from failures without having to trash unrelated projects.

  • The Toronto Virtual File System for OS/2 does exactly this. It lets you combine multiple directories into one mount point. You can even designate individual directories as read/write or read-only. It's used by OS/2 developers a lot. You can overlay a read-write empty directory onto a read-only directory that has the SDK in it. Whenever you change a file, the changed file gets written to the read-write directory, hiding the read-only version.
  • Forget about UnionFS, and read about vinum [vinumvm.org].

    It does exactly what you want.

    You can create virtual disks that span several hdd's, and create one huge filesystem.

    D.
  • Not exactly a solution to your problem, but you might consider AutoFS. I got fed up with having multiple pools of storage at home and no sensible way to back data up over many machines. All my machines are NIS clients to my Qube which is the NIS master. Any machine which exports a filesystem via NFS gets given a NIS entry in auto_master/auto_direct (Solaris/Linux). Everything is available, in my case via /han.

    /han/mp3
    /han/code
    /han/divx
    /han/pr0n etc. etc.

    The nice thing is, you never have to su to root in order to mount anything - you just cd into the directory (on any machine) and it gets mounted in the background. You still get UNIX file semantics and permissions, the normal NIS & NFS behaviour.

    On the machine with the DDS3 drive. I just kick of a script which traverses the NIS map and catches all the directories which I deem worth backing up. Works a charm, but really only on UNIX, which suits me. There are windows clients for much of this stuff (reflection, Solstice network client if you can still find it) but they're mostly crap.

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...