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.