[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Minimum size for /home?

If you intend to use the same filesystem types for both home partitions and maybe even the shared one, you could just format a single filesystem and bind some subdirectories from each system.

In case you're not familiar with mount binding, it would look like this:

From the first distro, try it by doing:
# mkdir /mnt/homes
# mount /dev/disk/by-label/homes /mnt/homes
# mkdir /mnt/homes/{distro{1,2},xp}
# mount --bind /mnt/homes/distro1 /home

Now every file you write in /home from the first distro will be, in fact, written to /mnt/homes/distro1. You get the point.

You could achieve the same thing with symbolic links, but bound mountpoints make more sense in this case, IMHO:
* You avoid the little overhead of a symlink (and maybe some issues?)
* You get more transparency
* You don't mind doing this operation in this "heavier" way, as it's really a system-level thing you have to do at boot-time

Of course, you'll want to edit the /etc/fstab files of the two systems so you don't need to do this manually each time you boot them.

-- If you like the idea and are satisfied with that, you can already stop here --

XP is the bad boy here, so if you want it to share this filesystem with the other distros, you might want it to be FAT32 (shouldn't be a problem for a 12G volume).

If you don't like it, you could format it as NTFS and use the ntfs-3g fuse-based driver for the Linux systems, which works like a charm. Maybe someone can comment on the state of the kernel driver, which should be faster, but was quite unreliable at least in the past.

I wouldn't recommend ext3 in this case, as the only good driver currently available for Windows (to my knowledge) [1] doesn't support journaling and probably other features* (but it works in my experience).

*A somewhat extreme solution would be to use coLinux, which basically runs a Linux kernel as a Windows process - you would be able to perfectly read and write any filesystem supported by Linux. But I don't think that's worth it, I just thought I'd mention it.

[1] http://www.fs-driver.org/

If you want to do it properly on the XP side, you'll probably want to move your Documents and Settings folder to that xp/ directory in the shared filesystem [1]. If that sounds like too much hassle, moving the My Documents directory is way easier [2].

[1] http://support.microsoft.com/kb/314843/
[2] In the Start menu, just right click My Documents, then Properties, then Target, and point to the directory.

Alright, now you have:
hda1  6GiB  XP
hda2  extended
  hda5  8GiB   distro1
  hda6  8GiB   distro2
  hda7  12GiB  shared
  hda8  1GiB   swap

I think this already makes it much simpler to maintain.

-- Again, you can stop here as well --

The debate is open, but you might consider using a swapfile instead of a dedicated volume and allocate that file only when necessary, with the appropriate size (there are programs out there to do this automatically, which can also grow the swapspace dynamically). You can then gain another gibibyte when the system doesn't need it for swapping, and you can now fit all your partitions entries in the MBR (arguably safer).

-- Want to continue? --

A completely alternative solution would be to virtualize a thing or two, have you considered it?

I know you're not sure about keeping Lenny for the two systems, but if you can manage to keep the same kernel for both, you could put them inside containers managed by this kernel. You would then only need one filesystem for these two systems, and they would be completely isolated without any performance hit. Another advantage is that you could run them simulatenously.

Have a look at LXC (Linux Containers), OpenVZ or VServer (there are some others). In fact, a simple chroot could do, if you know what that implies.

You now have:
hda1  6GiB  XP
hda2  xGiB  distro1 & distro2
hda3  xGiB  shared

-- Might want to stop here --

If you need different kernels and/or different filesystems and/or also want to virtualize XP (I understand you use it less often, but it can work the other way around), you could use paravirtualization software such as KVM (if you have the hardware) or kqemu (if you don't). Xen can do either way, and takes a different approach. VirtualBox is also very simple.

The virtual volumes containing the filesystems containing the two distros would be stored in files dynamically growing/shrinking in a single filesystem.

Now, you effectively have a single filesystem with every component taking up *exactly* the space it needs, at the price of a certain amount of CPU cycles and memory.

hda1  35GiB  everything

-- Can't think of anything else at this point --

In the end, it depends on what is the most important for you:
* Performance?
* Disk space?

According to that choice, you can stop at any point in the "tweaking". Presumably, the sooner you stop, the better performance you get, but the more disk space you waste.

Another thing to consider is that while this can look tedious to setup such environments, it might save you from the hassle of having to deal with filled up filesystems. As such, if you decide to keep your original layout (separate swap, root and home filesystems), I recommend using LVM for everything except of course XP and the shared data volume.

Before anyone says "WTF, he doesn't need all that", let me point out that I'm just exploring the possibilities, and I'm not forcing anyone to read nor to agree with me. I'm saying this because of the somewhat similar discussion we had on single root filesystems this week [1].

[1] http://lists.debian.org/debian-user/2010/02/msg01945.html

Hope this helps in one way or the other.


Reply to: