noob question

noob question

[Fitzgerald, Dan]

[-- Attachment #1.1: Type: text/plain, Size: 3481 bytes --]

I had our VMWare admin extend the file system on which /space is mounted (/dev/sda8). I'm trying to expand the file system. In the short time I've been researching, it appears that I want to use xfs_growfs.

I'm both a debian and xfs noob, used to AIX. This is the first day of my second week here, and as I'm the closest thing here to a linux admin, I get the opportunity to learn. This is a box that is not yet in production, and the anticipation is that the /space directory will need to be twice its' current size once the real data starts showing up.

System specifics:

root@thisbox:/# xfs_repair -V
xfs_repair version 3.1.7

root@thisbox:/# uname -a
Linux vmdamims01apl 3.10-0.bpo.2-amd64 #1 SMP Debian 3.10.5-1~bpo70+1+ims1 (2013-08-19) x86_64 GNU/Linux

Here's what I get when I try to use xfs_growfs, both the -d and the -D option (the 25000000 size is an arbitrary number above 19323392):

root@vmdamims01apl:/# xfs_growfs -d /space
meta-data=/dev/sda8              isize=256    agcount=4, agsize=4830848 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=19323392, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=9435, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data size 19323391 too small, old size is 19323392

root@vmdamims01apl:/# xfs_growfs -D 25000000 /space
meta-data=/dev/sda8              isize=256    agcount=4, agsize=4830848 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=19323392, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=9435, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data size 25000000 too large, maximum is 19323391

df -k . says this:

/space# df -k .
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda8       77255828 15375660  61880168  20% /space

Any help in getting me on track appreciated: don't mind doing the work & the reading, quite willing to be self-sufficient, but a shove in the right direction would be a great help. One thing I'd like to do is see what space is actually available: I'm told that the presented disk was extended by 150Gb in VMWare. How can I verify that? Thanks!

Regards,

Dan




_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ This email is confidential and intended solely for the use of the individual to whom it is addressed. If you have received this email in error please contact the sender and be advised that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. The terms for the purchase and sale of any property referenced in this email shall be solely determined by a ratified Purchase Agreement. Any information provided in this email, including but not limited to, pricing, financing, features of a property and/or community, is not to be construed as the basis of the bargain for the purchase and sale of any such property.

[-- Attachment #1.2: Type: text/html, Size: 9686 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: noob question

[Chris Murphy]

[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]


On Jan 6, 2014, at 3:11 PM, "Fitzgerald, Dan" <dfitzger@nvrinc.com> wrote:
> 
> data     =                       bsize=4096   blocks=19323392, imaxpct=25

It's a 73.7GiB file system.
> 
> /space# df -k .
> Filesystem     1K-blocks     Used Available Use% Mounted on
> /dev/sda8       77255828 15375660  61880168  20% /space

On a 73.7GiB partition. 

You need to make the partition bigger if you want the file system bigger.

>  I’m told that the presented disk was extended by 150Gb in VMWare. How can I verify that? 

Something's confused. Have you restarted the VM and then check with:

parted -l /dev/sda u s p
or
gdisk -l /dev/sda    #if gpt partitions, gdisk is friendlier than parted, same syntax as fdisk

Chris Murphy

[-- Attachment #1.2: Type: text/html, Size: 3715 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: noob question

[Stan Hoeppner]

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

RE: noob question

[Fitzgerald, Dan]

Yeah, I walked into this one.  Today's my 7th day at a new job, came into this with it already built, and now the business wants to expand the size of the file system that will house pictures served up on the web. I'm pretty sure I wouldn't have chosen xfs for this app; overkill.

It is a VMWare VM, so we do have snapshots. First thing I did when I inherited this was to test those.

Everyone here is calling this thing an "appliance", and the version of Debian doesn't have parted or gdisk.

I'm thinking I'll go into the meeting I have on this in 40 minutes and ask for a vendor contact, and work with them to rebuild the whole thing with better planning.

-----Original Message-----
From: Stan Hoeppner [mailto:stan@hardwarefreak.com]
Sent: Monday, January 06, 2014 8:59 PM
To: Fitzgerald, Dan; xfs@oss.sgi.com
Subject: Re: noob question

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


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ This email is confidential and intended solely for the use of the individual to whom it is addressed. If you have received this email in error please contact the sender and be advised that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. The terms for the purchase and sale of any property referenced in this email shall be solely determined by a ratified Purchase Agreement. Any information provided in this email, including but not limited to, pricing, financing, features of a property and/or community, is not to be construed as the basis of the bargain for the purchase and sale of any such property.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs