Re: similar lvm tool on openbsd??
On 11/11/2011 03:48 AM, Nick Holland wrote:
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.
Thanks Nick. growfs suites my needs. Is this the correct procedure??
http://wiki.arpnetworks.com/wiki/ResizeOpenBSDRootFilesystem
--
CL Martinez
carlopmart {at} gmail {d0t} com
Re: similar lvm tool on openbsd??
On 11/11/11 04:34, carlopmart wrote: On 11/11/2011 03:48 AM, Nick Holland wrote: [bla bla bla] Thanks Nick. growfs suites my needs. Is this the correct procedure?? http://wiki.arpnetworks.com/wiki/ResizeOpenBSDRootFilesystem the correct procedure is a big phrase. :) It's _A_ procedure, and for some people, it may be right. I'd not bet that the ramdisk file system on bsd.rd has the space available to pull over growfs on all platforms. And I don't like the step-by-step without the discussion of why. Your needs will probably be different from the author's, or mine, so make sure you understand, and if it is important, practice on a non-critical machine first. growfs has to be used on an idle file system. If your goal is to enlarge root (or /usr, or /var or ...), you need to be running in a strange mode -- single user with / unmounted, bsd.rd, booted from another file system, etc. Personally, I'd boot off my live USB disk, but since growfs is a static binary and based closely on newfs, it will probably run just fine from bsd.rd, so one could potentially boot from bsd.rd, mount / somewhere, mount /tmp (or whatever) elsewhere, save a copy of growfs to this other file system, unmount /, then do your twiddling. Exactly how you do this will depend on your environment. but again...when messing with your file systems, errors can be really bad, so rather than asking my or google's advice...build up a test machine, and practice on that before you do it on a production box. Nick.
Re: similar lvm tool on openbsd??
On 11/11/2011 03:40 PM, Nick Holland wrote:
On 11/11/11 04:34, carlopmart wrote:
On 11/11/2011 03:48 AM, Nick Holland wrote:
[bla bla bla]
Thanks Nick. growfs suites my needs. Is this the correct procedure??
http://wiki.arpnetworks.com/wiki/ResizeOpenBSDRootFilesystem
the correct procedure is a big phrase. :)
It's _A_ procedure, and for some people, it may be right. I'd not bet
that the ramdisk file system on bsd.rd has the space available to pull
over growfs on all platforms. And I don't like the step-by-step without
the discussion of why. Your needs will probably be different from the
author's, or mine, so make sure you understand, and if it is important,
practice on a non-critical machine first.
growfs has to be used on an idle file system.
If your goal is to enlarge root (or /usr, or /var or ...), you need to
be running in a strange mode -- single user with / unmounted, bsd.rd,
booted from another file system, etc.
Personally, I'd boot off my live USB disk, but since growfs is a static
binary and based closely on newfs, it will probably run just fine from
bsd.rd, so one could potentially boot from bsd.rd, mount / somewhere,
mount /tmp (or whatever) elsewhere, save a copy of growfs to this other
file system, unmount /, then do your twiddling. Exactly how you do this
will depend on your environment.
but again...when messing with your file systems, errors can be really
bad, so rather than asking my or google's advice...build up a test
machine, and practice on that before you do it on a production box.
Nick.
Thanks Nick. But my needs are only for filesystems with multiple data
files or configuration files, never for the root partition.
--
CL Martinez
carlopmart {at} gmail {d0t} com
similar lvm tool on openbsd??
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??
--
CL Martinez
carlopmart {at} gmail {d0t} com
Re: similar lvm tool on openbsd??
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?? Nope, there is no such thing. Regarding your second question, see the 14th FAQ section for a general overview and then the fdisk(8), disklabel(8) and growfs(8) manpages. Good reading.
Re: similar lvm tool on openbsd??
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.
