Suggested Partitioning Scheme

Zepp · 2008-06-12 18:52:33

I don't see where those links explain the major security advantages...

Berticus · 2008-06-12 19:07:29

okay, major was a major overstatement on my part, my bad. I originally wrote that in my reply, but it would seem as though I deleted it.... Now this is just my personal opinion, but having separate partitions is beneficial enough, and the effort put in isn't substantial enough to not do it. My last partitioning scheme wasn't that bad. Sure, I might not have had a big enough /usr and too big of a /tmp, but these mistakes come naturally when you learn. To me, setting up a complex partition scheme is a one time thing, just like installing gentoo, and I guess arch. People always ask me why I use them when there are millions of other distros that are far easier to install. It boils down to having a system I want. Similar thing here, while others may see this as stupid and unnecessary, I have my own personal reasons and opinion on the matter.

Last edited by Berticus (2008-06-12 19:43:01)

tam1138 · 2008-06-12 21:02:32

Berticus wrote:

Similar thing here, while others may see this as stupid and unnecessary, I have my own personal reasons and opinion on the matter.

And that is a good enough reason! But be prepared to justify it when you propose it in response to questions like the OP, and know that some people might not accept it.

violagirl23 · 2008-06-12 21:52:37

Man, I don't have all that many partitions, not even a boot one. When I was installing Gentoo my friend told me a separate /boot partition was no longer necessary and I could just have / and one more partition for swap, so I've been operating like that ever since. Is that really bad or something? *lost*

JeremyTheWicked · 2008-06-12 22:40:57

No, it's not really bad. It's how all Windows users operate, isn't it. And I don't think that most BSODs etc. come from not having folders on separate partitions.

Berticus · 2008-06-12 22:51:58

Before the year 2000, I think, a separate /boot partition was required in Unix and Linux with a size limit of 4 GB. I don't remember why exactly. So that's the only thing I know of your friend would be talking about when s/he said a separate /boot partition is no longer required.

It's not necessarily a bad thing.

This whole thread is basically why people have multiple partitions. The basic minimum partition scheme was, as I was told:

/
/var
/home
swap

No, it's not really bad. It's how all Windows users operate, isn't it. And I don't think that most BSODs etc. come from not having folders on separate partitions.

No... but losing all of your files, programs, configurations, et cetera always sucked.

Last edited by Berticus (2008-06-12 22:53:13)

Zepp · 2008-06-13 01:09:12

Technically all you need is a root partition, anything else is optional. I think you have to use ext2/3 in that case though. I don't believe grub can handle booting a reiser/xfs/jfs/etc partition.

violagirl23 · 2008-06-13 06:34:07

That is probably what he was referring to. He just said it used to be that you HAD to have a /boot partition, and when I first tried Linux (Slackware), it WAS 2002 but he told me to make a /boot partition cuz you have to... maybe he hadn't realized it was already no longer necessary.

Berticus · 2008-06-13 12:38:29

Well, I might've gotten my timeline mixed up. I know it was either 2000 or 2003 when this changed. But yeah, nowadays you can do one large partition instead. If it's 2003, then you friend could have been informed when the change happened.

moljac024 · 2008-06-13 12:48:09

violagirl23 wrote:

That is probably what he was referring to. He just said it used to be that you HAD to have a /boot partition, and when I first tried Linux (Slackware), it WAS 2002 but he told me to make a /boot partition cuz you have to... maybe he hadn't realized it was already no longer necessary.

However, you would do good to separate /var and /tmp and maybe even /home.

dwi · 2008-06-13 12:58:07

Disclaimer: this is mainly in regards to servers...

The reason *I* have multiple partitions:

/var - tons of stuff ends up here, often databases, mail spools, root app caches[pacman for example]
/home - obviously, usually user data
/srv - not really used on Arch, but many distros use this as the place that 'services' serve/operate from.
/tmp - temp files generated by apps.

^^ I almost always have those be different partitions, the rest can be on the / partition. Of course I have a swap as well. In practice I often have even more.

Now 90% of the time I build boxes for servers. So while not technically necessary for a workstation; The reason I have multiple partitions is so that say, a user, can not fill up the disk and cause MySQL to run out of space and crash/shutdown/etc. Or so that some script/person filling up /tmp won't cause problems. Quotas solve this, but depending on the nature of things, having as single partition makes quotas not as fine tunable. Quotas are on a partition level, so if I want to limit user X to 5GB of storage for /home, and also limit them to 512MB of web space, I can't do that on partition that has /home and the webroot on the same partition.

In some file systems were quotas aren't used, it allows a user to totally fill up the filesystem leaving no room for root to be able to make changes. Ext2/Ext3 allow you to reserve space for the root user, but not all filesystems allow this.

As far as /boot being on it's own, I do that too mainly out of habit. Back in the day BIOSes could not load bootloaders from partitions beyond a certain point in the disk, this limit varied from BIOS to BIOS. Some it was really small, like 512MB, others 2GB, or 4GB. Today though nearly all BIOSes can handle accessing partition level bootsectors very deep into the disk device, so it's generally not an issue.

Berticus · 2008-06-13 13:37:45

dvi wrote:

As far as /boot being on it's own, I do that too mainly out of habit. Back in the day BIOSes could not load bootloaders from partitions beyond a certain point in the disk, this limit varied from BIOS to BIOS. Some it was really small, like 512MB, others 2GB, or 4GB. Today though nearly all BIOSes can handle accessing partition level bootsectors very deep into the disk device, so it's generally not an issue.

Yeah, that sounds similar to what I read. It had to be the first partition, and less than 4 GB.

Berticus · 2008-06-16 14:19:15

Instead of starting a new thread, I think I'll siimply post my question here since it's pretty relevant. Back in 2006, I looked at some file system benchmarks, and saw that XFS was a pretty good choice. And it was good for a lot of things, ecept when I had to delete large files. I switched to ext3, because I was hoping to be able to access my stuff while in Windows. Since I'm having no luck with getting windows to read ext3, I'm abandoning the idea and going with performance again. However, newer benchmarks, particularly from T2 Magazine indicate that XFS is the worst filesystem in terms of performance.

The only time I guess I would need the kind of performance from these benchmarks is once I start migrating my data from my previous installment. For example, I'll be moving about 450 very large files (around 2 GB) in a 3 or 4 deep subdirectory. Next I would be moving roughly 2500 smaller files that are 4 subdirectories deep. Then I'll be moving about 3,000 even smaller files of about 12 MB in a 3 or 4 deep subdirectory. So in total, I'm moving around ~1.3 TB.

One thing that has remaind constant is that although reiserfs is fast, it tends to lose data. I know file systems that don't do journaling are faster, but journaling is something I want too.

So far I have:

swap - swap
/ - ext3
/boot - ext2
/var - undecided
/usr - undecided
/opt - undecied
/tmp - ext2 (would do tmpfs, but I would prefer more RAM, even though I have 2 GB)
/home - undecided
/data - undecided

It would seem JFS is a nice file system, but supposedly you lose performance after many years, and the defragging utility won't help.

Last edited by Berticus (2008-06-16 19:41:05)

zephyrus17 · 2008-06-19 14:07:54

Would having partitions in addition to
/
/home
swap

improve speeds?

Berticus · 2008-06-19 14:45:14

No, there is no performance increase. The only thing that's affected is the available disk space, restricting space, and minimal secuirty increases.

Larger partition schemes require a larger table, so you lose space there. Having /var and /tmp limits the space that they chew up, so you have more space for other directories. As for the minimal secuirty increases, basically it's just another layer if you mount some partitions as read-only.

zephyrus17 · 2008-06-19 14:55:51

What if you get the /var and /boot into different filesystems like XFS? Still no performance boost?

Zepp · 2008-06-19 15:53:09

Well technically it could maybe provide minor increases if say your /home tends to fragment a partition more. So theoretically say /tmp would never really get fragmented while other more active parts would. Instead of just the entire partition fragmenting. But that is a pretty minor theoretical increase .

zephyrus17 · 2008-06-19 16:13:24

So it's just nitpicking, eh?

In that case, if I do a
/
/home
swap

partition strategy like what I'm doing now in Ubuntu where all except swap are ext3, how much faster is Arch? Still a minor theoretical increase?

Berticus · 2008-06-19 16:32:50

faster compared to what?

iBertus · 2008-06-19 16:38:39

I'm using the following partition layout to run a software RAID10 setup on the desktop in my sig:

Disk /dev/sda: 91201 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+    186     187-   1502046   fd  Linux raid autodetect
/dev/sda2        187    1182     996    8000370   82  Linux swap / Solaris
/dev/sda3       1183    3672    2490   20000925   fd  Linux raid autodetect
/dev/sda4       3673   91200   87528  703068660    5  Extended
/dev/sda5       3673+   4917    1245-  10000431   fd  Linux raid autodetect
/dev/sda6       4918+   5913     996-   8000338+  fd  Linux raid autodetect
/dev/sda7       5914+  91200   85287- 685067796   fd  Linux raid autodetect

Disk /dev/sdb: 121601 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+    186     187-   1502046   fd  Linux raid autodetect
/dev/sdb2        187    1182     996    8000370   82  Linux swap / Solaris
/dev/sdb3       1183    3672    2490   20000925   fd  Linux raid autodetect
/dev/sdb4       3673   91200   87528  703068660    5  Extended
/dev/sdb5       3673+   4917    1245-  10000431   fd  Linux raid autodetect
/dev/sdb6       4918+   5913     996-   8000338+  fd  Linux raid autodetect
/dev/sdb7       5914+  91200   85287- 685067796   fd  Linux raid autodetect

Disk /dev/sdc: 91201 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdc1          0+    186     187-   1502046   fd  Linux raid autodetect
/dev/sdc2        187    1182     996    8000370   82  Linux swap / Solaris
/dev/sdc3       1183    3672    2490   20000925   fd  Linux raid autodetect
/dev/sdc4       3673   91200   87528  703068660    5  Extended
/dev/sdc5       3673+   4917    1245-  10000431   fd  Linux raid autodetect
/dev/sdc6       4918+   5913     996-   8000338+  fd  Linux raid autodetect
/dev/sdc7       5914+  91200   85287- 685067796   fd  Linux raid autodetect

I love how the linux MD RAID driver works! All but / are on RAID10, f2. / is on RAID1. The swap partitions are not raided, but rather have pri=1 for all in /etc/fstab. MD's are created by combining /dev/sd[a-c]1 for /, /dev/sd[a-c]3 for /usr, /dev/sd[a-c]5 for /opt, /dev/sd[a-c]6 for /var, and /dev/sd[a-c]7 for /home. This isn't the most optimal setup, but I'm concerned more with data protection than uber performance. I'll probably add a fourth drive eventually.

Zepp · 2008-06-19 16:42:27

zephyrus17 wrote:

So it's just nitpicking, eh?
In that case, if I do a
/
/home
swap
partition strategy like what I'm doing now in Ubuntu where all except swap are ext3, how much faster is Arch? Still a minor theoretical increase?

Uhm unless there is something wrong with one of the programs you are running the same programs on arch will be as fast as that same set on ubuntu/debian/fedora/gentoo/etc. The only difference in the binaries might be minor compile time optimizations which provide negligable increases on average.

zephyrus17 · 2008-06-20 03:04:21

I see. So the slimming of the kernel isn't going to show significant speed improvements? But I though Arch was touted as extremely fast and lean?

Zepp · 2008-06-20 03:09:47

Arch starts of with a very minimal base and the tools it uses are pretty minimalist in design. So yes by default it is very lean and fast, but if you go and install a full DE and all those other services and programs there will be negligable difference. Kernel size doesn't really affect system performance. I have compiled custom kernels that were very small, smaller then archs, and i have used kernels from like fedora/ubuntu which are huge in comparison, I didn't notice any performance increase or decreases from kernel size.

Last edited by Zepp (2008-06-20 03:10:30)

zephyrus17 · 2008-06-20 03:39:27

When you say "DE" you mean like Gnome or KDE?

iBertus · 2008-06-20 04:46:46

Arch's major advantage has always been the simplicity of design more than speed. This is especially true with the x64 distros, as all of these are pretty good performers. This was more true when other distros were compiled for i386 and Arch was i686. Still, I think Arch is faster than other distros I've tried. If you run a lightweight window manager and simple apps you can expect excellent performance.

Arch Linux

#26 2008-06-12 18:52:33

Re: Suggested Partitioning Scheme

#27 2008-06-12 19:07:29

Re: Suggested Partitioning Scheme

#28 2008-06-12 21:02:32

Re: Suggested Partitioning Scheme

#29 2008-06-12 21:52:37

Re: Suggested Partitioning Scheme

#30 2008-06-12 22:40:57

Re: Suggested Partitioning Scheme

#31 2008-06-12 22:51:58

Re: Suggested Partitioning Scheme

#32 2008-06-13 01:09:12

Re: Suggested Partitioning Scheme

#33 2008-06-13 06:34:07

Re: Suggested Partitioning Scheme

#34 2008-06-13 12:38:29

Re: Suggested Partitioning Scheme

#35 2008-06-13 12:48:09

Re: Suggested Partitioning Scheme

#36 2008-06-13 12:58:07

Re: Suggested Partitioning Scheme

#37 2008-06-13 13:37:45

Re: Suggested Partitioning Scheme

#38 2008-06-16 14:19:15

Re: Suggested Partitioning Scheme

#39 2008-06-19 14:07:54

Re: Suggested Partitioning Scheme

#40 2008-06-19 14:45:14

Re: Suggested Partitioning Scheme

#41 2008-06-19 14:55:51

Re: Suggested Partitioning Scheme

#42 2008-06-19 15:53:09

Re: Suggested Partitioning Scheme

#43 2008-06-19 16:13:24

Re: Suggested Partitioning Scheme

#44 2008-06-19 16:32:50

Re: Suggested Partitioning Scheme

#45 2008-06-19 16:38:39

Re: Suggested Partitioning Scheme

#46 2008-06-19 16:42:27

Re: Suggested Partitioning Scheme

#47 2008-06-20 03:04:21

Re: Suggested Partitioning Scheme

#48 2008-06-20 03:09:47

Re: Suggested Partitioning Scheme

#49 2008-06-20 03:39:27

Re: Suggested Partitioning Scheme

#50 2008-06-20 04:46:46

Re: Suggested Partitioning Scheme

Board footer