From: Stan Hoeppner <stan@hardwarefreak.com>
To: "Fitzgerald, Dan" <dfitzger@nvrinc.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: noob question
Date: Mon, 06 Jan 2014 19:58:59 -0600 [thread overview]
Message-ID: <52CB5F63.3040204@hardwarefreak.com> (raw)
In-Reply-To: <15F45A6CEAEFE340A264C3346D71EF04C4C339@DCEX01PRD.nvrinc.com>
On 1/6/2014 4:11 PM, Fitzgerald, Dan wrote:
> I had our VMWare admin extend the file system on which /space is
> mounted (/dev/sda8).
Repeat at least three times: Storage requires planning.
xfs_growfs only works on contiguous LBA sectors. The free space to be
grown into must begin one LBA sector after the last LBA sector of the
current XFS filesystem. If XFS resides on a partition, then the
partition itself must be expanded into the free space before XFS can be
grown into the newly expanded partition. This seems to be your
situation. Resizing partitions is not a fun exercise, and if not done
properly you can lose everything, literally.
If a block device is directly formatted with XFS things are easy.
Simply expand the block device capacity, then run xfs_growfs.
Because of the limitations up above, those wishing to add capacity using
partitions, in an ad hoc manner, such as you seem to desire here, put
their block device space in LVM volumes. LVM can create a linear LBA
address space from little pieces of capacity strewn all over the place
on many different storage devices, regardless of their native LBA
addressing. I don't really care for this method either.
I've worked with ESX and bare metal hosts on FC SANs fairly extensively.
For each of my guests/hosts I assign a 10GB LUN for the guest's
boot/root filesystems, and a separate LUN(s), sized appropriately, for
its data volume(s). I directly format each LUN, no partitions. In the
event I need to expand a LUN to increase capacity, xfs_growfs simply
works, the way it should, with no hoop jumping.
If you need PIT snapshot capability you must use LVM, unless your
storage has a PIT snapshot facility, or you use VMware's snapshot utility.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-01-07 1:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 22:11 noob question Fitzgerald, Dan
2014-01-06 22:43 ` Chris Murphy
2014-01-07 1:58 ` Stan Hoeppner [this message]
2014-01-07 15:22 ` Fitzgerald, Dan
-- strict thread matches above, loose matches on Subject: below --
2012-12-21 1:07 Noob Question awingnut
2012-12-21 1:43 ` Andrew Ardill
2012-12-21 13:27 ` W T Riker
2012-12-21 22:38 ` Andrew Ardill
2011-01-13 23:58 noob question Harry Johnson
2011-01-14 11:10 ` Thomas Rast
2011-01-14 21:32 ` Harry Johnson
2003-10-31 17:03 Noob Question Kevin Smith
2003-11-01 3:26 ` Alistair Tonner
2003-10-31 14:13 Kevin Smith
2003-10-31 14:25 ` Ray Leach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CB5F63.3040204@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=dfitzger@nvrinc.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.