Re: Problem with file system on iSCSI FileIO

From: Christoph Hellwig <hch@infradead.org>
To: Slawomir Nowakowski <slawomir.nowakowski@open-e.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: Problem with file system on iSCSI FileIO
Date: Sat, 25 Sep 2010 11:56:12 -0400	[thread overview]
Message-ID: <20100925155611.GA21928@infradead.org> (raw)
In-Reply-To: <4C9C875D.9050308@open-e.com>

> So once again. We have created a RAID unit level 6. On the top of
> the unit there is an LVM architecture, I mean a volume group that
> contains logical volumes. The logical volume is formatted with XFS
> and it contains one big file that takes almost all of the space on
> the LV. There is some free space left in order to be able expand the
> LV and FS in the future. The LV is mounted and the file is served as
> iSCSI target. The iSCSI Initiator (MS Initiator from Windows 2k3)
> connects to iSCSI target. The iSCSI disk is formatted with the NTFS.

ok, so we have:

Linux Server

+----------------------+
|   hardware raid 6    |
+----------------------+
| lvm2 - linear volume |
+----------------------+
|          XFS         |
+----------------------+
|    iSCSI target      |
+----------------------+

Windows client:

+----------------------+
|    iSCSI initiator   |
+----------------------+
|        NTFS          |
+----------------------+

> But we believe the problem is with the XFS. With unknown reason we
> are not able to mount the LV and after running xfs_repair the file
> is missing from the LV. Do you have any ideas how we can try to fix
> the broken XFS?

This does not sound like a plain XFS issue to me, but an interaction
between components going completely wrong.  Normal I/O to a file
should never corrupt the filesystem around it to the point where
it's unusable, and so far I never heard reports about that.  The hint
that this doesn't happen with another purely userspace target is
interesting.  I wonder if SCST that you use does any sort of in-kernel
block I/O after using bmap or similar?  I've not seen that for iscsi
targets yet but for other kernel modules, and that kind of I/O
can cause massive corruption on a filesystem with delayed allocation
and unwritten extents.

Can any of the SCST experts on the list here track down how I/O for this
configuration will be issued?

What does happen if you try the same setup with say jfs or ext4 instead
of xfs?

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