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.
-thib
Reply to: