Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Nov 2012 14:37:55 +0100
From:      Polytropon <>
Subject:   Re: [Bulk] Re: Manually partitioning using gpart
Message-ID:  <>
In-Reply-To: <1353847426.2508.35.camel@q>
References:  <1353842774.2508.18.camel@q> <> <1353847426.2508.35.camel@q>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 25 Nov 2012 13:43:46 +0100, Ralf Mardorf wrote:
> On Sun, 2012-11-25 at 13:29 +0100, Polytropon wrote:
> I'll read this. I want to test what's possible and/or impossible
> regarding to MIDI and audio productions using FreeBSD.

Will be interesting. I know there is some good support for this
case in specialized Linux distributions.

> > Doing "functional partitioning" requires at least an idea
> > of how much disk space will be needed per functional part,
> > and this can differ from use as server or desktop, or what
> > kind of software you run.
> On Linux I only use /.

Yes, this is common, even though Linux can support functional
partitioning as well, still ext2/3/4/... partitions != UFS partitions.
And with GPT partitioning, it's even easier to separate parts
of the system across partitions and devices (which _can_ provide
you performance boosts).

> So I don't have to think about how much space
> what directory might need and I never run into issues, when the file
> system hierarchy does change. Off cause I've got special partitions for
> audio productions mounted with noatime and a own partition for emails,
> but anything else, including /home is inside /.

This _could_ develop into disadvantages, like some "half-dead"
process filling the whole partition until problems arise. But
for common desktop use, it should not be problematic.

> >  The advantage is that you can
> > backup data partition-wise (using dump + restore) and have
> > a functional base system on / in case there's a severe
> > disk corruption. The disadvantage is that if finally one
> > partition is "too full", you cannot easily resize them
> > (even though this is possible).
> On Linux I can backup partition-wise too, but it's also possible to
> backup directory-wise ;).

Tools like rsync or cpdup make selective backing up and restoring
easy, that's true. :-)

The idea is that if there is some damage, all you need to boot
your machine in a minimum and _defined_ state is on /. No need
for /usr or /var at this point, so you could - if required - do
analytics and recovery from this point on. As all 3rd party software
is in /usr/local, there won't be a problem as nothing of that
stuff is needed to perform the boot into this early stage (the
single user mode). If you don't have to experience such a situation,
the better.

> Btw. I never sync backups, I always keep several backups of the system,
> since setting up a hard real-time jitter free DAW is a special task for
> modern computers. In the 80s hard real-time really was hard real-time
> (C64, Atari ST), nowadays it is hard work to get something similar.

There are specialized operating systems emphasizing real-time use.
Still those more simple computers required a "close to the hardware"
programming that modern OSes will hardly allow, so if you don't have
this kind of access from the OS level, how would you get it from the
application level, with tons of dependencies unter your hands? :-)

BTW, I still have some Atari ST hardware here. Impressive what has
been possible with this (quite limited) machines, but with _efficient_

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>