Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Divying up the root folders across multiple drives
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
ElleStone
Tux's lil' helper
Tux's lil' helper


Joined: 12 Mar 2013
Posts: 106

PostPosted: Fri May 17, 2013 7:44 pm    Post subject: Divying up the root folders across multiple drives Reply with quote

Before asking my questions, first I want to say "Thank You" to the Gentoo developers and all of you Gentooers. When I switched to Linux back in 2005, I really enjoyed Linux. Somewhere along the line Linux stopped being fun. Gentoo has made Linux enjoyable again.

The question is how best to divy up root folders. My main computer has four sata hard drives: two sata 1.5 WD Raptors (70GB each), and two sata 3.0 Seagate Barracudas (120GB and 640GB). I use this computer for image editing, as a test lamp server (only one website, nothing fancy), and for source code modification. Here's my proposed partitioning:

*The first raptor: 4 partitions: swap (12gb), /boot (1gb), /root (35gb), and /virtualm (21gb, for virtual machine disks).
*The second raptor: 3 partitions: swap (12gb), /rwstorage (45gb), and /newphotos (12gb, temporary storage).
*The smaller Seagate: swap (12gb), /home (99gb, www and databases are in my home directory).
*The larger Seagate: /edit (148gb), /store (437gb).

To keep Gimp from totally choking when it runs out of ram, the three swap partitions are "swap-raided" per Daniel Robbins' article: http://www.ibm.com/developerworks/linux/library/l-swaptip2/index.html. So it's really only 12gb of swap.

I've been pondering Mr. Robbins' article: http://www.ibm.com/developerworks/library/l-partplan4/index.html. Mr. Robbins suggests linking /tmp and /var to a partition separate from the root partition. Imagemagick and other image editing programs use /tmp for temporary files, some of which can get very large. So it makes sense to give /tmp a lot of space. Also, I work a bit on source code, which means keeping up with several git repositories and also means frequently recompiling software. I usually install the compiled software in /usr/local.

So the "/rwstorage" partition on the second raptor would have at least three, perhaps 4 subfolders: "tmp" linked to /tmp, "var" linked to /var, "git" for source code and notes, and perhaps "local" linked to /usr/local. I considered real partitions for /tmp, /var, /usr/local, and so on, but that could result in "wasted space/not enough space" issues. So here's my questions:

*Does this seem like a workable partitioning scheme? Or is linking like this just asking for problems? In particular, will it cause problems with routine backups when links are involved?
*Should I link /usr/local to "local" on /rwstorage? Or leave it on "/"?
*Regarding partition sizes, if /tmp and /var and possibly /usr/local are linked to folders on /rwstorage, how big should the "/" partition be?

ElleStone
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43198
Location: 56N 3W

PostPosted: Fri May 17, 2013 9:29 pm    Post subject: Reply with quote

ElleStone,

A few things on drobbins swap document.

I says that swap is set up like raid0. Thats striping for speed, so you get the benefit of all of your swap space but no redundancy.
That gives you 36G of swap.

You do not have the control you think you might today. That document is dated 2000 ... thats before the days of devfs, udev and devtmpfs.
On a modern system, all of your swaps will be mounted automatically with priority -1, so you get the raid0 effect and any entries in /etc/fstab will be ignored.

In the years since 2000, RAM has got about 10 or 15 times faster but HDD only about 3 or 4x faster, your Raptors being the exception.
So, if you make use of swap, you really need more RAM, though I can see how The GIMP will use all of the RAM you can throw at it, then some. Be careful of out of date infrormation.

I would put /boot on one of the slower drives, as its only ever used start startup and donate all of the rest of your disk space to Logical Volume Manager. Since you want to keep track of what goes on which spindle, you would have four physical volumes, from which you make logical volumes to hold your filesystems.

Its important that you choose filesystems that support growing and maybe shrinking. This way you don't have to allocate all your space at the outset and you can add unallocated space to a logical volume and expand the filesystem into the new space. With extX you can do that while the filesystem is in use too. Shrinking is a bit harder but is also supported, so you can move space around.
If you use KVM, you can donates one or more logical volumes as disk space for the VM. I think Virtualbox can work with logical volumes too but I've not checked. You get some performance improvements in your VMs as you don't have a filesystem in a file on the hosts filesystem.

As an example, I have
Code:
$ df -Th
Filesystem               Type      Size  Used Avail Use% Mounted on
/dev/md126               ext4       15G  1.1G   13G   8% /
/dev/dm-0                ext4       40G   29G  8.8G  77% /usr
/dev/dm-3                ext4       58G   32G   24G  58% /var
tmpfs                    tmpfs     7.9G  1.1M  7.9G   1% /run
udev                     devtmpfs   10M  4.0K   10M   1% /dev
shm                      tmpfs     7.9G   76K  7.9G   1% /dev/shm
cgroup_root              tmpfs      10M     0   10M   0% /sys/fs/cgroup
/dev/mapper/vg-home      ext4     1008G  774G  183G  81% /home
/dev/mapper/vg-opt       ext4      9.8G  222M  9.1G   3% /opt
/dev/shm                 tmpfs     7.9G  672K  7.9G   1% /tmp
/dev/mapper/vg-local     ext4      976M   62M  864M   7% /usr/local
/dev/mapper/vg-portage   ext2      2.0G  1.1G  841M  56% /usr/portage
/dev/mapper/vg-distfiles ext4       59G   51G  5.6G  91% /usr/portage/distfiles
/dev/mapper/vg-packages  ext4       59G   36G   21G  64% /usr/portage/packages
/dev/shm                 tmpfs     7.9G     0  7.9G   0% /var/tmp/portage
plus /boot which is not shown.
This lives on a four spindle raid5 setup, which provides 3Tb of useful space. As you see, I can grow into the unallocated apace.
None of it is done with symlinks.
For expendable data, like
Code:
/dev/mapper/vg-portage   ext2      2.0G  1.1G  841M  56% /usr/portage
/dev/mapper/vg-distfiles ext4       59G   51G  5.6G  91% /usr/portage/distfiles
/dev/mapper/vg-packages  ext4       59G   36G   21G  64% /usr/portage/packages
I turn off journaling and fine tune the filesystems.
Be careful of tuning the block size on advanced format HDD. You can save a lot of wasted space in portage by using a 1K block size, but if the drive physical block size is 4k, don't do it.

Using symlinks as you propose, leads to fragmentation as bits of /tmp are written between bits of /var. LVM provides a different trade off, since after you grow a logical volume, its space need not be in a single chunk as it would be with a partition.

Without knowing how much RAM you have and how big some of your /tmp files get, its difficult to advise on sizes.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ElleStone
Tux's lil' helper
Tux's lil' helper


Joined: 12 Mar 2013
Posts: 106

PostPosted: Sun May 19, 2013 2:22 pm    Post subject: Reply with quote

NeddySeagoon, thank you for taking the time to respond in detail. I've been pondering your advice very carefully.

Quote:
That gives you 36G of swap.
Hmm, I tried it, you are right, it's 36G not 12G. Drat.

Quote:
In the years since 2000, RAM has got about 10 or 15 times faster but HDD only about 3 or 4x faster, your Raptors being the exception. . . . I would put /boot on one of the slower drives,
My raptors are the original raptors from circa 2005, and they are the slowest drives on my computer, so I left the /boot partition on the first raptor. Alas, my RAM necessarily is old server ram, as it's an old (circa 2005) server board and only uses DDR1.

Quote:
So, if you make use of swap, you really need more RAM, though I can see how The GIMP will use all of the RAM you can throw at it, then some.
Too true. I have 12GB RAM. Most image processing programs run fine on 4GB ram, but Gimp 2.9 processing multiple layers at 32-bit floating point can chew through 12GB in no time at all, which is when swap comes in handy (only long enough to free up some ram, Gimp on swap is no fun at all). I'm hoping to double the amount of RAM.

Quote:
donate all of the rest of your disk space to Logical Volume Manager . . .
That sounds like excellent advice, but LVM scares me. My drives are old and I'm more comfortable dealing with one failed physical drive than with one failed physical drive in LVM.

Quote:
Its important that you choose filesystems that support growing and maybe shrinking.
I used to use JFS for the partition that used to hold the virtual machine disks. But after reviewing the Phoronix (recent! not outdated!) file system benchmarks, I chose ext4 for everything except the boot partition, which is ext2.

Quote:
If you use KVM . . .
Alas, my processors predates KVM.

Quote:
Be careful of tuning the block size on advanced format HDD. You can save a lot of wasted space in portage by using a 1K block size, but if the drive physical block size is 4k, don't do it.
My drives all predate advanced format HDD. fdisk reports units as sectors of 1 * 512 = 512 bytes, logical, and physical sector size as 512 bytes. The newly formatted drives start at 2048, the one remaining not-yet-newly-formatted drive starts at 63, but that drive (the largest, newest, fastest Seagate) is scheduled to be reformatted today, as soon as I make a second backup on a second external hard drive.

Quote:
Using symlinks as you propose, leads to fragmentation as bits of /tmp are written between bits of /var.
Hmm, obviously my partitioning plan wasn't very good!

Quote:
You do not have the control you think you might today. That document is dated 2000 ... thats before the days of devfs, udev and devtmpfs. . . . Without knowing how much RAM you have and how big some of your /tmp files get, its difficult to advise on sizes.
Unfortunately the size of the /tmp files varies considerably depending on the image editing program being used and the size of the image files, and I've never actually monitored it, so I just don't know.

Quote:
I turn off journaling and fine tune the filesystems.
Is there a reference you'd recommend for learning more about tuning filesystems?

Here's my revised partition plan:

*The first raptor: 4 partitions: /boot (1gb), /var (16gb, maybe also put all the portage files in a folder under /var?), /root (32gb), and /virtualm (20gb, for virtual machine disks).
*The second raptor: 3 partitions: swap (6gb), /tmp (18gb), /coding (45gb, for source code).

Does putting /var and /tmp on separate partitions mean I need one of those initramfs thingies? I'm using eudev and grub-static-0.97, if that makes a difference.

*The smaller Seagate: /home (111gb, www and databases are in my home directory).
*The larger Seagate: /edit (148gb, for editing images - this is the fastest drive), /store (437gb, for storing images).

Thank you again, very much, for reviewing my original partitioning plan and stopping me from doing something unworkable.

ElleStone
_________________
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43198
Location: 56N 3W

PostPosted: Sun May 19, 2013 3:37 pm    Post subject: Reply with quote

ElleStone,

For tuning filesystems, think about what you will put on them, how expendable they are and if you mind long fsck times.
For a large number of small files, you want a small block size and one inode per block. Think of the portage tree as an example.
Most of the files are less than 1k in size. They will each take one block, regardless of the block size. The tree is also expendable. Its well backed up on the web.
So, a 1k block size, no jourmal, one inode per block works well. you can remake this filesystem if it gets in a mess. -O dir_index may speed thinhs up too.

For a filesystem that stores large files, use a 4k block size. If its portages distfiles, its expendable too. A journal will speed up fsck but if you had to throw it away, it too is backed up from the web. You only need one inode per file, so if all the files were say 1Mb each, you need one inode per Mb of filesystem space.
Creating excessive inodes is wasteful. Not creating enough means remaking the filesystem, so have too many rather than too few.

Code:
man mke2fs 
will show you the controls, then its up to you.

When I suggested LVM, I did not intend you to put all your free space (except /boot) from all your drives into a single logical volume. You could but then when a drive dies, as you fear, everything is gone. I intended that you would use LVM in lieu of partitions, so you could move space around withing the same drive. Thats all it would bring.

Don't pay too much attention to what fdisk and friends say about physical sector size. Most advanced format drives lie to the operating system and report 512b/sector.

/boot at 1Gb is huge. I still use 32Mb and have three kernels and their initrd files there, along with grub. 32Mb is getting a bit tight.
/tmp on its own partition is safe. udev needs some writable space before root is read/write so it makes /run in RAM of type tmpfs and uses that.
/var on its own partition is supposed to be safe today, so what you suggest will not need an initramfs.

Starting the first partition at 2048 rather than 63 is more for EFI systems than advanced format hard drives. Anything that is a multiple of 8 is OK for advanced format drives...e.g. 64.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum