Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Feb 2013 17:42:30 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        Paul Schmehl <pschmehl_lists@tx.rr.com>, "'FreeBSD Questions List'" <freebsd-questions@freebsd.org>
Cc:        "dteske@freebsd.org" <dteske@freebsd.org>
Subject:   RE: How to add unused space to an existing install
Message-ID:  <13CA24D6AB415D428143D44749F57D7201EA5CDF@ltcfiswmsgmb21>
In-Reply-To: <6C52D891D96E0ACEBF1531DD@utd71538.campus.ad.utdallas.edu>
References:  <6C52D891D96E0ACEBF1531DD@utd71538.campus.ad.utdallas.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On 7 Feb 2013, Paul Schmehl wrote:
>=20
> --On February 6, 2013 5:21:39 PM -0600 dteske@freebsd.org wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: owner-freebsd-questions@freebsd.org [mailto:owner-freebsd-
> >> questions@freebsd.org] On Behalf Of Paul Schmehl
> >> Sent: Wednesday, February 06, 2013 9:59 AM
> >> To: FreeBSD Questions List
> >> Subject: How to add unused space to an existing install
> >>
> >> I have a FreeBSD 8.3 RELEASE box that we recently discovered only has
> >> part of the "disk" being used.  This box has four 1TB drives in RAID 5,
> >> and df only shows 500MB of disk available.
> >>
> >> fdisk shows this:
> >> # fdisk -p
> >> # /dev/mfid0
> >> g c364602 h255 s63
> >> p 1 0xa5 63 1562363771
> >> a 1
> >>
> >> When I run the fdisk editor in sysinstall I see this:
> >>
> >> Disk name:      mfid0                                  FDISK Partition
> >> Editor
> >> DISK Geometry:  364602 cyls/255 heads/63 sectors =3D 5857331130 sectors
> >> (2860024MB)
> >>
> >> Offset       Size(ST)        End     Name  PType       Desc  Subtype
> >> Flags
> >>
> >>          0         63         62        -     12     unused        0
> >>         63 1562363771 1562363833  mfid0s1      8    freebsd      165
> >> 1562363834 4294981702 5857345535        -     12     unused        0
> >>
> >> I want to capture all that unused space and add it to the server.
> >>
> >> fstab has this:
> >> # cat /etc/fstab
> >> # Device             Mountpoint      FStype  Options         Dump
> >>      Pass#
> >> /dev/mfid0s1b                none            swap    sw              0=
       0
> >> /dev/mfid0s1a                /               ufs     rw              1=
       1
> >> /dev/mfid0s1e                /home           ufs     rw              2=
       2
> >> /dev/mfid0s1d                /tmp            ufs     rw              2=
       2
> >> /dev/mfid0s1f                /usr            ufs     rw              2=
       2
> >> /dev/mfid0s1g                /var            ufs     rw              2=
       2
> >> /dev/acd0            /cdrom          cd9660  ro,noauto       0       0
> >>
> >> When I try to create a new slice using fdisk, it doesn't seem to work.
> >
> > Did you try something like:
> >
> > echo "p 2 165 * *" | sudo fdisk -f- /dev/mfid0
> >
> > ??
>=20
> Thank you for your detailed and informative answer.
>=20
> I did not.  I'm a neophyte in the disk world.  I've always used sysinstall
> to setup partitions and mount points.
>=20
> >
> > Afterward "fdisk -p" should show something like...
> >
> ># /dev/mfid0
> > g c364602 h255 s63
> > p 1 0xa5 63 1562363771
> > p 2 0xa5 <num> <num>
> > a 1
> >
> > And then you'll have /dev/mfid0s2 which you can do-with what you like
> > (directly newfs the slice or create BSD partitions underneath that to
> > further sub-divide into as many as 8 smaller units, /dev/mfid0s2[a-h]).
> >
>=20
> I've been doing some more research on this problem, and I've discovered
> that bsdlabel has a 2 to the 32nd limit on disk size.  It appears I have =
to
> use gpart instead.  Is that not correct?
>=20

Only if your disk is larger than 2TB (or 2048GB). If you try to partition a=
 >2TB disk with fdisk the most you can hope to access is 2TB (the rest will=
 be forever unused).

I was noticing that that the total size for all your partitions is about 74=
4.95GB -- far short of the maximum addressable of 2TB. So you *could* gain =
access to more space with the tricks discussed here, but yes...

You will be required to use gpart to address more than 2TB of storage on a =
single discrete disk. gpart creates a GPT layout versus fdisk which creates=
 an MBR layout. GPT uses length identifiers double that of MBR so you shoul=
d be able to address up to 16 million terabytes on any single discrete disk=
 with gpart. That ought to be enough for a while (the largest storage array=
 known to exist today is in the Petabytes ... thousands of terabytes -- nob=
ody has yet produced a single storage device of contiguous addressable spac=
e matching-or-exceeding 1024 petabytes or 1M terabytes; so we have a ways t=
o go before anybody reaches the limit of 2^64).


> >
> >> If I move to the label editor, I get this:
> >>
> >>  FreeBSD Disklabel Editor
> >>
> >> Disk: mfid0     Partition name: mfid0s1 Free: 0 blocks (0MB)
> >>
> >> Part      Mount          Size Newfs   Part      Mount          Size Ne=
wfs
> >> ----      -----          ---- -----   ----      -----          ---- --=
---
> >> mfid0s1a  <none>       2000MB *
> >> mfid0s1d  <none>      65536MB *
> >> mfid0s1e  <none>       4096MB *
> >> mfid0s1b  swap        65536MB SWAP
> >> mfid0s1f  <none>      10240MB *
> >> mfid0s1g  <none>        601GB *
> >>
> >> As you can see mfid0s1g is 601GB, and according to fstab that's /var.
> >>
> >> Yet df -h shows:
> >>
> >> # df -h
> >> Filesystem       Size    Used   Avail Capacity  Mounted on
> >> /dev/mfid0s1a    1.9G    726M    1.0G    41%    /
> >> devfs            1.0k    1.0k      0B   100%    /dev
> >> /dev/mfid0s1e    3.9G     38M    3.5G     1%    /home
> >> /dev/mfid0s1d     62G    6.6M     57G     0%    /tmp
> >> /dev/mfid0s1f    9.7G    7.5G    1.4G    84%    /usr
> >> /dev/mfid0s1g    582G     39G    496G     7%    /var
> >>
> >> So apparently I'm not creating this new slice?  It should be
> >> /dev/mfid0s1h, correct?
> >>
> >
> > Let's not confuse slices (DOS partitions) with disklabels (BSD
> > partitions).
>=20
> OK.  I've clearly done that.  As I say, I'm a neophyte in the disk geomet=
ry
> and configuration field.
>=20
> >
> > DOS partitions are (maximum 4 per disk):
> >
> > mfid0s1
> > mfid0s2
> > mfid0s3
> > mfid0s4
> >
> > (according to your "fdisk -p" output, you're mfid0 disk is currently on=
ly
> > using mfid0s1)
> >
> > BSD partitions are (maximum 8 per "slice" aka DOS partition):
> >
> > mfid0s1a
> > mfid0s1b
> > mfid0s1c
> > mfid0s1d
> > mfid0s1e
> > mfid0s1f
> > mfid0s1g
> > mfid0s1h
> >
> > (according to your sysinstall output, you're mfid0s1 slice has 5 BSD
> > partitions -- a, e, d, f, and g)
> >
>=20
> I see.
>=20
> >
> >> How to I "recapture" the remaining 2+TB of space that's not being used?
> >>
> >
> > The easiest way to use your extra space is to not adjust one of those 5
> > BSD partitions, but instead create a new DOS partition (mfid0s2 as
> > previously discussed above). However, if you *really* want to "grow" an
> > existing BSD partition, this can be done (very carefully).
> >
>=20
> I'm all for taking the easy way out. :-)
>=20

^_^


>=20
> > First, you'll want to save the output of "disklabel -r mfid0s1" to a te=
xt
> > file.
> >
> > Next, you'll have to re-fdisk mfid0 so that the first slice covers the
> > entire disk. Of course, re-mastering the slices does not affect the dat=
a,
> > but it _will_ wipe out the BSD partition map (the disklabels; in other
> > words, after using fdisk to adjust the slice size of the first DOS
> > partition, "disklabel -r mfid0s1" will no longer return what it had
> > before -- you'll have no disklabels after), so the previous step of
> > backing up the output of "disklabel -r ..." is paramount.
> >
> > Next, you'll have to restore the disklabel (using "disklabel -e mfid0s1"
> > and cross-referencing your backup text file) with one slight adjustment=
...
> >
> > You're going to use the *exact* values you backed up _EXCEPT_ you're
> > going to make the last label (position-wise -- taking care to note the
> > byte ranges of each disklabel -- ignoring "c" which of course is a pseu=
do
> > label for "whole slice") bigger while keeping the same offset (only the
> > size of the last label should change).
> >
> > In your case, given the output you provided from sysinstall, this would
> > likely be your "g" label (but I'd have to see your "disklabel -r" output
> > to know for sure -- again, taking care to analyze the byte ranges).
> >
> > Once you've re-written the disklabels (making sure to change nothing fr=
om
> > your previous backup except the size of the last label to cover the new
> > unused space), you're now at a position where you can "grow" the label
> > with:
> >
> > growfs /dev/mfid0s1g
> >
> > NOTE: Should be done from a LiveFS (read: not while booted from said
> > filesystem).
> >
> > That will zero out the unused inodes and make the new space available.
> > Upon your next boot you'll now have the new storage space available to
> > your "g" label (/var from the looks of it).
> >
> > NOTE: If you wanted to change "g" to your "/usr" partition, rsync is yo=
ur
> > friend -- while booted from a LiveFS like DruidBSD or mfsBSD etc.).
>=20
> Excellent information.  Thank you.
>=20

No problem, glad to help.
--=20
Devin

_____________
The information contained in this message is proprietary and/or confidentia=
l. If you are not the intended recipient, please: (i) delete the message an=
d all copies; (ii) do not disclose, distribute or use the message in any ma=
nner; and (iii) notify the sender immediately. In addition, please be aware=
 that any message addressed to our domain is subject to archiving and revie=
w by persons other than the intended recipient. Thank you.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201EA5CDF>