On Jun 23, 1:27 pm, Mike Christie <[EMAIL PROTECTED]> wrote:
> However, there is issue outstanding I think. I think you then need a new
> a newer kernel (like 2.6.26 or something) so that the block layer can
> see the changes and pick up the scsi layer changes. Also see my comment
> on FSs picking tihs up below.

This could very well be the issue. I'm running 2.6.18 and can't really
upgrade since this is a Xen kernel.

> > Having manually resized the filesystem on the target end, I now get
> > errors on the initiator since the filesystem extents are outside of
> > the apparent device extents.
> I did not get what you said here? So do you have a FS mounted on the
> initiator, then you resize and the FS on the target end (how do you do
> that, do you mount it locally on the target)?
> I think you have to unmount the FS when you resize the disk. I think we
> can only handle the resizing at the disk level. The FS may not handle
> this dynamically.

What I originally tried to do was to umount the fs on the target and
then resize it, but this fails because the block device's size hasn't
been updated. So instead, I removed the LUN in question from the
initiator. I then resized the fs on the intiator and then recreated
the LUN. The target still hadn't picked up the new size of the block
device, so the filesystem failed a basic sanity check and failed to
mount. (fs size > block device size)

Some filesystems, namely XFS, can support on-line resizing. Actually,
with XFS, in order to use the xfs_growfs utility the fs *must* be
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to