Disk, filesystem, slices

jemate18

jemate18

Please correct me if i understood the disk, FS and slices wrong.


First IDE master (ad0)
First IDE slave (ad1)
Second IDE master (ad2)
Second IDE slave (ad3)

ad0 - Can only have 4 primary slices s1, s2, s3, s4
ad1 - Can only have 4 primary slices s1, s2, s3, s4
ad2 - Can only have 4 primary slices s1, s2, s3, s4
ad3 - Can only have 4 primary slices s1, s2, s3, s4

Each slice can have partitions from a to h s1a, s1b, s1c, s1d, s1e, s1f, s1g, s1h

Of the 4 slices, one of them could be logical and inside them the number would be s5 and up......

If I create two slices in ad0 (s1 and s2) can I do this.
ad0s1a /
ad0s1b swap
ad0s1e /tmp
ad0s2a /usr/home
ad0s2b swap
ad0s2e /opt

for the installation of FreebSD

Thanks...
 
That sounds about right, yes. You'd typically only use one slice, though - it's easier to just create one that covers the disk, and then all the partitions inside that one.

Note that FreeBSD doesn't use /opt for anything by default, so unless you plan on doing something with it by hand, you can skip it. On the other hand, having /usr on a separate partition is common - it can get quite large, since installed ports generally go in /usr/local (and there's a bunch of base system stuff in /usr to begin with).
Oh, and if you're going for a very small / , you probably want to split out /var as well.

There's also no good reason to have two swap partitions on one physical disk. Trying to load balance the two will lead to a lot of seeking and slow things down compared to having just one. (On the other hand, if you've got two physical disks it will speed things up to have one swap partition on each.)


Personally, I tend to use a somewhat large / (these days, a 10GB root partition is both quick to fsck and a rather small part of a typical disk), a swap partition, and the rest for /usr. No need to make it complicated, really.
 
I have always chose the "A" to load defaults, so all my FreeBSD systems have 512MB of /. What are the disadvantages of having just a 512MB of /. My /usr is large like 34GB.
 
The main downside is that you have separate maximum sizes for /var and /tmp, so you risk one of them running out of space while the other has a lot spare. You've also got a severely limited /root, which can be annoying if you use the root account to set things up, though that's fairly easy to work around.

Is /boot on a separate partition? If not, you also risk running low on space if you compile/install new kernels, especially if you use one with debugging symbols. (One kernel + modules + symbols for 8.0 on i386 takes 134 MB at the moment. 96MB of that is the symbols, so a plain non-debugging kernel is much smaller.)


Still, you'll probably be ok with 512MB. Looking at one of mine, it uses about 300MB for /, then 65MB for /tmp and 441MB for /var.
The main reason I use a large / is that it's simpler - when you have as much space to play with as you find on a new HD these days, there's not really any reason to start fiddling with how many hundred MB you think /var needs - just create a / that's definitely big enough, and let /usr have the rest.
 
If the disk is under 40 gigs, just give it a swap partition, and the rest a big "/" partition. I know that goes against conventional wisdom, but partitioning a small hard drive won't get anyone anywhere.
 
Unless the system panics in the middle of a buildworld, then you stand to lose the whole filesystem in one fell swoop. Happened to me on a 36Gb drive, so since then, I create separate partitions for / /var /tmp /usr /usr/ports and /home.

As for sizes, a little trial and error over several weeks was required, so yes, it takes a little experience and experimentation.
 
Go for the installer's auto defaults. If you have specific needs (like webserving, etc) do take a look for advices in the Handbook.

Don't for a big fat / with everything on it. It's so wrong at some many levels.
 
This is the list of partitions that I usually make: /, /tmp, /usr, /usr/ports, /usr/home, /usr/src, /usr/obj, /var

If you're doing them out in a fixed way you're not going to want one for /usr/ports, /usr/src or /usr/obj, but I'd definitely make the other ones.

Considering that FreeBSD now supports booting from GPT, I'd consider skipping the traditional slices and just use that. You'd end up with things like ad0p2, ad0p3, ad0p4, ad0p5, ad0p6.
 
One of the pleasant things with ZFS root is that you can create all the partitions you want without the fixed-size problems. :)
 
Then what would be your recommendation for the partition layout and sizes for an 80GB HD for general usage of FreebSD....
 
Pushrod said:
Please.
Click to expand...

Want reasons? Fine:
- security: partitions with user data should not have setuid programs. Easy as pie to enforce that with partitions
- flexibility: if the disk is damaged, most likely the damage is confined to a single partition. Hence you can boot the system from an intact partition and try to recover data. On a single partition any damage to that partition is instantly damage to the entire system
- maintainability: Logs to occasionally fill up an entire hard drive if left unattended. With partitions that damage is confined to a subset of the system.
- backups: dump works great at partition level. With it you can just backup specific partitions and use different backup strategies for different types of data
- file systems: different partitions can have different file systems. Inodes size can be set according to data plus you can optimize the system for small or large files. You can some partitions with UFS, other with gjornal, gmirror, etc.

To each its own. Want to stick with a single partition? Fine do it. I just hope that God forbid you don't have to reformat or reinstall you OS sometime down the line.
 
tangram said:
To each its own. Want to stick with a single partition? Fine do it. I just hope that God forbid you don't have to reformat or reinstall you OS sometime down the line.
Click to expand...

I am well aware of the benefits of partitioning a disk. In fact, I have the typical setup with /var, /usr, and so forth on my file server.

What I disagree with is partitioning a small (<40G) disk. All that is going to do is leave you with one partition that inevitably fills up while another is mostly free, so you get to use symlinks or repartition. Obviously there are times when you can get away with it, such as when the role of the computer is well known, but sometimes not. Some ports take many gigs to build.

A monolithic disk not "wrong on so many levels". The entire contents of a small hard drive can fit on a handful of DVDs, so there is no backup issue.

Having a monolithic partition is excessively feared, just like changing root's shell. I've pulled off both for the last 10 years with no problems from either.
 
re: original poster, I believe you are correct regarding disks, slices, and partitions. I regularly make a lot of partitions and end up needing two or more slices.

We use amanda to do per filesystem dumps over our network, so I am under a lot of pressure from my boss to keep individual partition sizes under control. So, I separate a lot of things, especially things that either don't need backed up, or only need a level 0 once in a blue moon.

Typically go with a 2gb /, swap is double the size of actual memory, more if I expect the machine to get a mem upgrade in the foreseeable future, and I have disk space to burn.

I always separate /tmp from /, 2 GB is nice for most machines, more for webservers, and anything with a dvd burner I up that to 6gb or more.

I keep /usr and /usr/local separate as well, again, we do filesystem backups, and this keeps the size of an individual backup smaller and more manageable. I also keep /usr/ports on its own chunk, and we never back that up. if I have enough disk space I also separate /usr/src and /usr/obj, though I want to move all our src builds to a central machine that just compiles world, and everyone else installs from an NFS mount..... someday.

Most of the machines I admin don't need much for /home, just scratch space for myself, and the boss, so a 2gb /home is more than enough. My home and office fileservers on the other hand get an entire huge disk for /home.

I also tend to bust /var and /var/spool apart, not much reason to backup /var more than rarely for most machines, no reason at all to backup /var/spool. Neither need much at all in terms of space, unless you are running a dedicated syslogger, in which case I also partition a /var/log.

The rest is mission specific. My web server has 4 30gb partitions on /www/0, /www/1, /www/2, and /www/3, and a little directory hashing magic to make that work as a decent structure for apache and virtual hosts. database servers get extra /var.... and so on.
 
Pushrod said:
A monolithic disk not "wrong on so many levels". The entire contents of a small hard drive can fit on a handful of DVDs, so there is no backup issue.
Click to expand...

Yes there is a backup issue: data that is not yet backed up may well become a victim in the monolithic partition scenario. With daily backups, it may not be a huge issue, but it's still an issue. How many people do daily or even weekly backups? I don't see many raising their hands.

Having a monolithic partition is excessively feared, just like changing root's shell. I've pulled off both for the last 10 years with no problems from either.
Click to expand...

Trying to extrapolate from a single user's experience, to justify other users doing the same thing is flawed when counter examples invalidating such an approach have already been given.

It's no different to saying "avoid brand X disk drives because I have experienced multiple failures" or "use brand Y hard drives because I have never had one fail".

Sure, some may "get away" with it. Before choosing this path, ponder your answer to the question "How would you cope if your file system became corrupted and unrecoverable overnight" or its corollary "How valuable is your data?".
 
trev said:
Sure, some may "get away" with it. Before choosing this path, ponder your answer to the question "How would you cope if your file system became corrupted and unrecoverable overnight" or its corollary "How valuable is your data?".
Click to expand...

To which I'll answer "Just fine - I keep the hard-to-replace data on the file server, anyway". Desktop filesystems are there for my convenience, and the average (or cumulative) annoyance of dealing with many small partitions outweighs that of the (very) occasional harder to recover from crashes of a disk that only contains applications and their configuration, anyway. To answer more directly: "The data I'd lose if my desktop HD died overnight is not especially valuable".

Not that this is a good solution for everyone or everything - but for a throwaway desktop installation, it works for me.

Of course, what I do with the data on said file server is suddenly very important - but that's a different issue.
 
one benefit of different FS on partitions is
that a "df" will show space remaining on,
specifically, /var (for example) so one can
manage it efficiently. /var/account/ , for
example, if /var is with /usr, one would
not notice the large files accumulating by
a 'df'
 
tangram said:
Just go the Auto-defaults and relax ;)
Click to expand...

I haven't used auto-defaults for a while, but if 1G /var is still the default, I would recommend against that. Many programs use /var/tmp as scratch disk and while logs accumulate, the 1G is gone very quickly.
 
You must log in or register to reply here.
Back
Top