Noob Question

Noob Question

[Kevin Smith]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Does IPtables need to be recompiled every time you roll a new kernel?
I just compiled 2.4.22 and when my firewall (Shorewall) started, it spit
some "device busy" errors with ip_tables.o. 
Kev

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 1500 bytes --]

Re: Noob Question

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Fri, 2003-10-31 at 16:13, Kevin Smith wrote:
> Does IPtables need to be recompiled every time you roll a new kernel?
> I just compiled 2.4.22 and when my firewall (Shorewall) started, it
> spit some "device busy" errors with ip_tables.o. 
> Kev
No. The kernel source includes (at least as far as I recall) the
iptables kernel space drivers/programs/libraries.

The userspace tools (the iptables executables used to manage rules) are
separate, and do not get recompiled every time you recompile the kernel.

The exception would be if you have iptables v0.1.0 (for example)
userspace programs and in your kernel have iptables v1.2.8 source code,
then there would be a mismatch, and the userspace programs may be
incompatible with the kernel modules.

Best to keep them all the same.
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Noob Question

[Kevin Smith]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

Ok thanks, I think I had to but wasn't 100%. Now I can eliminate that is a
possibility (Iptables 1.2.8). 
I finished it late last night so I wasn't in the mood for Googling anything.
but tonight I shall. But I would turn away any tips. ;-)
Thanks


--__--__--

Message: 5
Subject: Re: Noob Question
From: Ray Leach <raymondl@knowledgefactory.co.za>
To: Netfilter Mailing List <netfilter@lists.netfilter.org>
Organization: Knowledge Factory
Date: Fri, 31 Oct 2003 16:25:39 +0200


--=-p9AU5830cWaY0P2ToPWv
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2003-10-31 at 16:13, Kevin Smith wrote:
> Does IPtables need to be recompiled every time you roll a new kernel?
> I just compiled 2.4.22 and when my firewall (Shorewall) started, it
> spit some "device busy" errors with ip_tables.o.=20
> Kev
No. The kernel source includes (at least as far as I recall) the
iptables kernel space drivers/programs/libraries.

The userspace tools (the iptables executables used to manage rules) are
separate, and do not get recompiled every time you recompile the kernel.

The exception would be if you have iptables v0.1.0 (for example)
userspace programs and in your kernel have iptables v1.2.8 source code,
then there would be a mismatch, and the userspace programs may be
incompatible with the kernel modules.

Best to keep them all the same.
--=20
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint =3D 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--


[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2600 bytes --]

Re: Noob Question

[Alistair Tonner]

On October 31, 2003 12:03 pm, Kevin Smith wrote:
> Ok thanks, I think I had to but wasn't 100%. Now I can eliminate that is a
> possibility (Iptables 1.2.8).
> I finished it late last night so I wasn't in the mood for Googling
> anything. but tonight I shall. But I would turn away any tips. ;-)
> Thanks
>
>
> --__--__--
>
> Message: 5
> Subject: Re: Noob Question
> From: Ray Leach <raymondl@knowledgefactory.co.za>
> To: Netfilter Mailing List <netfilter@lists.netfilter.org>
> Organization: Knowledge Factory
> Date: Fri, 31 Oct 2003 16:25:39 +0200
>
>
> --=-p9AU5830cWaY0P2ToPWv
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Fri, 2003-10-31 at 16:13, Kevin Smith wrote:
> > Does IPtables need to be recompiled every time you roll a new kernel?
> > I just compiled 2.4.22 and when my firewall (Shorewall) started, it
> > spit some "device busy" errors with ip_tables.o.=20
> > Kev
>


	That error usually is generated when one has both iptables and ipchains in 
the tree.

	if ipchains loads ... iptables *coughs* and exits stage left.





> No. The kernel source includes (at least as far as I recall) the
> iptables kernel space drivers/programs/libraries.
>
> The userspace tools (the iptables executables used to manage rules) are
> separate, and do not get recompiled every time you recompile the kernel.
>
> The exception would be if you have iptables v0.1.0 (for example)
> userspace programs and in your kernel have iptables v1.2.8 source code,
> then there would be a mismatch, and the userspace programs may be
> incompatible with the kernel modules.
>
> Best to keep them all the same.
> --=20
> --
> Raymond Leach <raymondl@knowledgefactory.co.za>
> Network Support Specialist
> http://www.knowledgefactory.co.za
> "lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
> Key fingerprint =3D 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
> --

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!

noob question

[Harry Johnson]

I am completely new to git and have only read the tutorial as well as
some git for subversion users documentation. Our company is
considering switching from subversion to git and I have been doing
some experimenting and have run across a potential problem. Our
systems are kubuntu/linux.

I have used git-svn to create a git repo from our subversion repo. I
have done this as user foo which is just an account that is used for
doing central builds. I have then cloned this as repo as myself,
harry. My thought is that the repo owned by foo would be a central
repo that all of the developers, including myself, could clone and to
which  we could then 'git push' our changes. The nightly builds would
then simply build whatever was currently in the foo repo. This of
course completely ignores the complexity of branches at this point but
like I said, I am experimenting. I did a test of this and what I found
when checking the git log is that while the changes I made and checked
into my repo clearly showed me as the author, the same changes after
being pushed to foo's repo showed a different author.

So two things.. First should the author have been preserved? How can I
make sure that it is?

Second, and probably the better question. Am I too focused on the
subversion methodology? Is there a better way of managing a central
build scheme using git?

Thanks!
-Harry

Re: noob question

[Thomas Rast]

Harry Johnson wrote:
> 
> I have used git-svn to create a git repo from our subversion repo. I
> have done this as user foo which is just an account that is used for
> doing central builds. I have then cloned this as repo as myself,
> harry. My thought is that the repo owned by foo would be a central
> repo that all of the developers, including myself, could clone and to
> which  we could then 'git push' our changes.
[...]
> when checking the git log is that while the changes I made and checked
> into my repo clearly showed me as the author, the same changes after
> being pushed to foo's repo showed a different author.
> 
> So two things.. First should the author have been preserved? How can I
> make sure that it is?

Yes, absolutely, and since the author is encoded in the commit objects
it's impossible to change it without also changing the commit sha1s.

Can you spell your experiments in actual commands and output snippets
so we can see what happened?

Did you ever run 'git svn dcommit', 'git rebase', 'git commit --amend'
or similar in foo's repo?  All of these rewrite commits.  As part of
their rewriting they set the *committer* to the identity of the
current user.  'git svn dcommit' sets author&committer to the identity
coming back from SVN.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: noob question

[Harry Johnson]

>> I have used git-svn to create a git repo from our subversion repo. I
>> have done this as user foo which is just an account that is used for
>> doing central builds. I have then cloned this as repo as myself,
>> harry. My thought is that the repo owned by foo would be a central
>> repo that all of the developers, including myself, could clone and to
>> which  we could then 'git push' our changes.
> [...]
>> when checking the git log is that while the changes I made and checked
>> into my repo clearly showed me as the author, the same changes after
>> being pushed to foo's repo showed a different author.
>>
>> So two things.. First should the author have been preserved? How can I
>> make sure that it is?
>
> Yes, absolutely, and since the author is encoded in the commit objects
> it's impossible to change it without also changing the commit sha1s.
>
> Can you spell your experiments in actual commands and output snippets
> so we can see what happened?
>
> Did you ever run 'git svn dcommit', 'git rebase', 'git commit --amend'
> or similar in foo's repo?  All of these rewrite commits.  As part of
> their rewriting they set the *committer* to the identity of the
> current user.  'git svn dcommit' sets author&committer to the identity
> coming back from SVN.

Ah that does sound like the issue then. I did in fact do a git svn
dcommit to commit the changes from the foo repo to our subversion
repo. If dcommit rewrites the commit changing the author then that
would explain it.

So I did a new test. I made a change and committed it to my local
repo. I then did a git pull to bring my repo in sync with the foo
repo, then did a push to the foo repo. Before doing anything else I
checked the author of my changes in the foo repo and sure enough I am
the author! Yay for that.

Now I try to git svn dcommit and I receive the following error:
Merge conflict during commit: File or directory 'bar' is out of date.
Try updating ...

So I do a git svn rebase, followed by git svn dcommit which works. Now
looking at git log I see that my changes are 'authored' by some else.
All that to say that you seem to hit the nail on the head and the git
svn rebase and git svn dcommit are rewriting the commits and changing
the author.

If we do indeed adopt git as our version control system then we would
freeze the subversion repo and not worry about git svn any further so
I think this is ultimately a non-issue and just something we will deal
with during this hybrid testing period.

Thanks!!
-Harry

>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>

Noob Question

[awingnut]

I have not used git yet but am planning to. I am trying to get my head
around how it will work and the documentation I found so far is of
modest help. I currently have a Java application developed using Eclipse
on Windows. However, the project is located on a Linux shared drive
which is my Eclipse workspace. I do my builds using ANT on the Linux
host. My main questions center around the git repository and accessing it.

1) Should I install git on Linux or Windows or does it matter?
2) How will my build scripts access the source? Will it be the same as
now (my scripts 'cd' to the Eclipse project directory and run there) or
do I need to add a wrapper to my script to check out the entire source
for the builds?
3) How do I move my current Eclipse project into git after I create the
empty repository? I can only find info on how to import git into Eclipse
not the other way around.
4) Do I need to checkout the entire project from Eclipse to modify and
test it or only the classes I want to change? Does the plugin get the
others as needed when I run the app within Eclipse for testing?

Thanks for any help understanding how I need to configure all this.

Re: Noob Question

[Andrew Ardill]

Hi!

On 21 December 2012 12:07, awingnut <wtriker.ffe@gmail.com> wrote:
> My main questions center around the git repository and accessing it.

The main thing you need to know is that you can work on your code base
in the *exact* same way while using git. You don't *have* to change
anything about how you work, as git's primary purpose is to store
snapshots of your work so that you have a history of what has changed.

That being said, you can (and maybe should) change how you work to
take into account the power of git. Most of what you do will stay the
same, however.

> 1) Should I install git on Linux or Windows or does it matter?

Install git wherever you need to access the code. From the sounds of
it you will want git on both machines, as you are working on windows
and but keeping the code on the linux shared drive. When working on
the windows machine you will use a windows copy of git to manipulate
the workspace, though I'm not sure if there are any gotchas with the
interaction with a linux shared drive.

If you want to manipulate the repository from the linux machine you
will need git on it as well.

Unless you're using a git server, manipulating the repository is a
local action and so is performed by the client. That is, when working
on windows use the windows client, if you also work on the linux
machine then you will need a client there as well.

> 2) How will my build scripts access the source? Will it be the same as
> now (my scripts 'cd' to the Eclipse project directory and run there) or
> do I need to add a wrapper to my script to check out the entire source
> for the builds?

It's the same as now. Git uses the concept of a 'work tree' to talk
about the actual files you are working on now. The work tree
corresponds exactly to your current project files. When you create a
git repository you gain the ability to store snapshots of this working
tree into the 'object store', as well as metadata about the snapshots,
so that you can restore that snapshot later.

Your actual files keep their current layout and format, until you change them.

> 3) How do I move my current Eclipse project into git after I create the
> empty repository? I can only find info on how to import git into Eclipse
> not the other way around.

You have two options. Create the git repository in the same location
as your Eclipse project. Navigate to the project folder using git bash
and do a 'git init' inside it; voila! you now have a git repository.
You can choose to create a 'remote' repository somewhere to store a
backup of your code as well, but this _still_ requires you to init a
local repository to backup.

The other option is to create a blank repository somewhere (anywhere)
and then tell that repository to use your Eclipse project as its
working tree. The benefit to doing this is being able to keep your
snapshots and metadata in a different location to your working
directory (say keep the snapshots on a local windows drive while your
working directory is on the linux share). Unless you shouldn't or
aren't able to create the repository within the Eclipse project, I
would recommend against this.

> 4) Do I need to checkout the entire project from Eclipse to modify and
> test it or only the classes I want to change? Does the plugin get the
> others as needed when I run the app within Eclipse for testing?

Not sure exactly what you are asking here, but in general people will
'clone' an entire repository including all its history. If you want to
update only certain files that is fine, but the commit object stores
the state of the entire tree of files. Note that a commit object does
_not_ store the difference between two snapshots, but stores the
entire state of the files. You can grab a file from a given snapshot
and test that along side files from a second snapshot, but if you
wanted to commit the resulting tree to the repository it would store a
third snapshot containing the exact state of all files.

Hopefully that clears it up for you?

Regards,

Andrew Ardill

Re: Noob Question

[W T Riker]

Hi Andrew,

Thank you for a great explanation. It clears up a number of things but
also creates some new questions. However, armed with this I am going to
run through the documentation again and perhaps it will make more sense
to me. One basic question, since I don't make changes from the Linux
side, only builds, do I need to install anything git related on that
machine?

On 12/20/2012 8:43 PM, Andrew Ardill wrote:
> Hi!
>
> On 21 December 2012 12:07, awingnut <wtriker.ffe@gmail.com> wrote:
>> My main questions center around the git repository and accessing it.
> The main thing you need to know is that you can work on your code base
> in the *exact* same way while using git. You don't *have* to change
> anything about how you work, as git's primary purpose is to store
> snapshots of your work so that you have a history of what has changed.
>
> That being said, you can (and maybe should) change how you work to
> take into account the power of git. Most of what you do will stay the
> same, however.
>
>> 1) Should I install git on Linux or Windows or does it matter?
> Install git wherever you need to access the code. From the sounds of
> it you will want git on both machines, as you are working on windows
> and but keeping the code on the linux shared drive. When working on
> the windows machine you will use a windows copy of git to manipulate
> the workspace, though I'm not sure if there are any gotchas with the
> interaction with a linux shared drive.
>
> If you want to manipulate the repository from the linux machine you
> will need git on it as well.
>
> Unless you're using a git server, manipulating the repository is a
> local action and so is performed by the client. That is, when working
> on windows use the windows client, if you also work on the linux
> machine then you will need a client there as well.
>
>> 2) How will my build scripts access the source? Will it be the same as
>> now (my scripts 'cd' to the Eclipse project directory and run there) or
>> do I need to add a wrapper to my script to check out the entire source
>> for the builds?
> It's the same as now. Git uses the concept of a 'work tree' to talk
> about the actual files you are working on now. The work tree
> corresponds exactly to your current project files. When you create a
> git repository you gain the ability to store snapshots of this working
> tree into the 'object store', as well as metadata about the snapshots,
> so that you can restore that snapshot later.
>
> Your actual files keep their current layout and format, until you change them.
>
>> 3) How do I move my current Eclipse project into git after I create the
>> empty repository? I can only find info on how to import git into Eclipse
>> not the other way around.
> You have two options. Create the git repository in the same location
> as your Eclipse project. Navigate to the project folder using git bash
> and do a 'git init' inside it; voila! you now have a git repository.
> You can choose to create a 'remote' repository somewhere to store a
> backup of your code as well, but this _still_ requires you to init a
> local repository to backup.
>
> The other option is to create a blank repository somewhere (anywhere)
> and then tell that repository to use your Eclipse project as its
> working tree. The benefit to doing this is being able to keep your
> snapshots and metadata in a different location to your working
> directory (say keep the snapshots on a local windows drive while your
> working directory is on the linux share). Unless you shouldn't or
> aren't able to create the repository within the Eclipse project, I
> would recommend against this.
>
>> 4) Do I need to checkout the entire project from Eclipse to modify and
>> test it or only the classes I want to change? Does the plugin get the
>> others as needed when I run the app within Eclipse for testing?
> Not sure exactly what you are asking here, but in general people will
> 'clone' an entire repository including all its history. If you want to
> update only certain files that is fine, but the commit object stores
> the state of the entire tree of files. Note that a commit object does
> _not_ store the difference between two snapshots, but stores the
> entire state of the files. You can grab a file from a given snapshot
> and test that along side files from a second snapshot, but if you
> wanted to commit the resulting tree to the repository it would store a
> third snapshot containing the exact state of all files.
>
> Hopefully that clears it up for you?
>
> Regards,
>
> Andrew Ardill
>

Re: Noob Question

[Andrew Ardill]

On 22 December 2012 00:27, W T Riker <wtriker.ffe@gmail.com> wrote:
> One basic question, since I don't make changes from the Linux
> side, only builds, do I need to install anything git related on that
> machine?

You don't need to install it, but there is no harm in it. If you ever
start doing a build from the linux box and decide you have the wrong
version of your code, it would be useful to have git installed so you
can checkout the right version. Installing git is quick and painless,
however, so you can cross that bridge once you get to it.

Regards,

Andrew Ardill

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