HD space planning for new installation

M

mefizto

Greetings all,

given that I am running out of HD space and FreeBSD 8.1 has been released, I am planning to move from release 7.1 to release 8.1.

Currently, I have a mirrored disk array comprising all OS files, /home, which contains my day-to-day used files, and /data, which contains other, less used files, i.e., music, photos, laptop backup, and the like. What I am proposing is:
1. mirrored USB CF for / and /usr (UFS);
2. mirrored HDs /var, /tmp, /home (ZFS);
3. mirrored HDs /data (ZFS).

The idea is to separate OS related files for easier update/upgrade, day-to-day used files (/home), and once-in-a-while used files (/data). Since there is some evidence that spinning up and down HDs causes mechanical wear, and also spinning disks use power, I would like to not spin up the /data containing HDs upon boot, but only when/if I need to access such data.

So the questions are: do you see any issue with this scheme that I have overlooked, and
is there a way to prevent a mirrored HDs from spinning up upon boot?

Thank you,

M
 
Personally, I'd use tmpfs(5) (or look into the tmpmfs stuff in /etc/defaults/rc.conf (see also mdmfs(8))) for /tmp/, but that's me.

As far as not spinning up a drive on boot, every machine I have ever used spins up the drive during POST*, no way I know around that besides pushing the drives out to a NAS or iSCSI or something alike. I guess hotswap or USB (or firewire(4) & good luck) would work.


*old proliant with 7 scsi drives would test every drive sequentially during POST, took about 12 seconds per drive too.
 
What disk do you have available and what sizes are they?

The easiest option might just be to make a huge zpool with all your disks, with a sensible layout of ZFS's within it, making all your disk space available for all filesystems.

I expect all disks will spin up on boot so that the OS can enumerate the filesystems and labels thereon, and populate /dev/gpt/, /dev/ufs etc
 
Dear fronclynne,

thank you for the reply. Yes I am using tmpfs(5) for mounting /tmp; I forgot to mention it in my post.

Regarding the spin-up, yes it appears that there is no way to prevent the HDs to spin-up on computer start-up.

Dear jem,

I have 2*500 GB and 2*1TB.

Kindest regards,

M
 
One of the big advantages of zfs is the ability to dynamically allocate filesystems & mounts. As jem said, just throw it all into one big pool. If your /var/ is too big or too small you can change it on the fly. The same with /data/ or whatever. Instead of doing # rm -r /usr/obj/usr to clean your object directories, just make /usr/obj/ its own filesystem and destroy it when you're done with it.
 
Dear fronclynne, jem,

thank you for your recommendation, which I will follow with the exception of using ZFS for the entire file-system. I am fairly new to ZFS (having used it only since 7.0 release), and although I experimented with having even the / on ZFS, I had some problems and it took me lot of research and effort to fix it.

Kindest regards,

Pavel
 
jem said:
Hi Mefizto,

With your disks, I'd be inclined to set up two mirrored zpools, one 500GB and one 1GB. I would install a Root-on-ZFS FreeBSD installation on the 500GB zpool and dedicate the 1GB zpool to /data.

There is an excellent guide for setting up FreeBSD on a mirrored pool at http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror.

(I also have my own basic guide with a few minor differences here)
Click to expand...

I have set up my system using the wiki instructions and I followed them exactly and now I have a filesystem hierarchy zroot zroot/usr zroot/var etc. What if I want to change that without redoing everything from scratch? Can I just boot to Fixit and rename the filesystems to lets say zroot/ROOT/freebsd zroot/ROOT/freebsd/usr etc. (and change the mountpoints of course)?
 
You can't rename zroot to a subordinate ZFS, because it's the top-level dataset in your pool. Instead, you'd have to use zfs send and zfs receive to copy its contents to a new ZFS, zroot/ROOT/freebsd, then delete the original zroot contents manually.

Then, you can use zfs rename to move zroot/var to zroot/ROOT/freebsd/var, zroot/usr to zroot/ROOT/freebsd/usr etc.


My view is that using the default top-level dataset in a pool it makes it very difficult to rearrange or swap things around in the future. You can't do things like set up a parallel sets of filesystems containing seperate OS installations and switch booting between them, mimicking OpenSolaris' boot environments, or upgrading a system by installing a entirely fresh copy of the OS alongside the existing one, like this:

Code: 
pool0
pool0/ROOT
pool0/ROOT/freebsd80
pool0/ROOT/freebsd80/usr
pool0/ROOT/freebsd80/var
pool0/ROOT/freebsd81
pool0/ROOT/freebsd81/usr
pool0/ROOT/freebsd81/var
pool0/HOME
pool0/HOME/user1
pool0/HOME/user2

I also like to keep different types of data (OS files, user files) in entirely different branches of the ZFS hierarchy, so that things like recursive snapshots or sends can be limited to only the data type I want.

Don't worry too much about how you've set things up already though. There are plenty of people who have done it as described in the wiki and would say that my way is rubbish. I'll just politely disagree with them :)
 
You must log in or register to reply here.
Back
Top