On 11/10/11 14:49, carlopmart wrote:
Hi all,
is it possible to work under OpenBSD with disk volumes?? Like in linux
world does LVM... If not, how can I expand/resize a disk partition??
In the way LVM or Veritas products or some other systems do, no.
However, most use of resizing partitions is usually a way of saying, "I
screwed up, maybe I can fix it". May I instead suggest...not screwing
up in the first place, or designing the system knowing the unknowns you
will run into?
For enlarging a partition with space available after it, there is
growfs(8). You can't change the beginning of a partition with growfs,
you can't shrink a partition with growfs, but you can enlarge it at the
end, if you have space available.
On a modern hard disk, it is easy to have ten or more times the space
you will ever need. DON'T ALLOCATE IT! Fill your /usr partition? make
a new (bigger) one in the free space, copy over the old /usr to the new
one, change your /etc/fstab to point to the new one, reboot, done. Be
careful with it, you don't even need console.
If you have an app where you know you will be filling disks, plan ahead
there, too. A few years ago, I built an e-mail archive. We didn't try
to pretend we would make one file system that would hold years of data,
we made lots of 500GB partitions, filled 'em, moved on to the next one,
filled it, so on. Each partition filled after a few months. When we
ran out of empty disk space, we took entire arrays off the machine and
put them on the shelf (alternates: new machine, additional external
arrays, etc).
Sometimes, you just don't know exactly how needs are going to break
down, but even then, you can do some guessing. For example, I help run
an OpenBSD mirror. We opted to cut the array (about 420G) that holds
the primary things it deals out (anoncvs& FTP) into two chunks, one for
each of its primary functions. We opted to give about 20G to the
anoncvs repository and 350GB of OpenBSD FTP space. We figured at some
point, we'd run out of one or the other, but we weren't sure which. We
put the bigger, FTP slice at the beginning of the disk, and the anoncvs
chunk at the end, and 50GB of UNUSED SPACE in the middle. The plan is
this: if we run out of FTP space, we put the 50GB on FTP space, and
growfs it. If we run out of anoncvs space, we create another 20GB space
"under" the existing partition, fill it with data, delete the old one,
add the old one's space to the "new" anoncvs partition, growfs it,
ta-da, doubled space.
As it turned out, we are running tight on ftp space -- each OpenBSD
release has more than doubled in size since the mirror was installed,
and we'll probably need to add-in that 50GB before 5.1 comes out, but
that should hold us a while.
The biggest advantage I see to volume managers is the ability to grow a
mount point from one set of disks over to a new set of disks. However,
I really think you are usually better off organizing your data into
multiple chunks than to add new failure points and complexity to a
system. Plan on this from the beginning..."WHEN I run out of space, I
will do ...", as opposed to, "Oh, poo. I'm out of space...and my app
wasn't designed to be multiple storage space aware..."
In short...I just haven't found need for most of the things people do
with "volume managers". But the lack is hardly a show stopper for
anything I have tried to do. Plus...I've seen problems CAUSED by volume
managers: file systems made up of chunks here and there are more complex
and more likely to do something Really Unhappy than simple, single-chunk
file systems, and seen people try to reassembly very complex systems
from bits and pieces when a few cables got confused...
Nick.
