On Jun 23, 1:27 pm, Mike Christie <[EMAIL PROTECTED]> wrote: --snip-- > 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 mounted. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
