Message-ID: <4270218E.80708@activestate.com>
Date: Wed, 27 Apr 2005 16:34:38 -0700
From: David Sparks <daves@activestate.com>
Reply-To: daves@activestate.com
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330)
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: SAN resizing disk, no LVM
References: <21114.1114643772@ocs3.ocs.com.au>
In-Reply-To: <21114.1114643772@ocs3.ocs.com.au>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 1118
Lines: 32

>>Is using /dev/sdb instead of /dev/sdb1 for a fs safe to do?  (I've never
>>read anything authoritative on this subject)
> 
> 
> A block device is a block device is a ...  It is safe, as long as no
> other tool tries to access /dev/sdb.  In particular, if anything tries
> to partition /dev/sdb or to install a boot loader on /dev/sdb then it
> will overwrite the first superblock of the XFS partition.  You are
> gaining a little extra space, at the risk that some other disk tool
> will accidentally destroy your filesystem.

The main idea is that LVM isn't required to resize the disk.  A
`xfs_growfs /mnt/sdb` is sufficient

Is there a simple way to resize a partition with a fs inside it?


I do appreciate the warning, I see this every time I load fdisk:

 Warning: invalid flag 0x0000 of partition table 4 will be corrected by
w(rite)


I tried to "correct" the invalid flag once and the fs was unmountable.
It did get fixed from a xfs_repair but I don't know if there was any
actual damage to the fs?  It is only a test fs at the moment and mostly
empty so there was no indication of data loss.

Cheers,

ds