xfs
[Top] [All Lists]

Re: Problem with file system on iSCSI FileIO

To: Slawomir Nowakowski <slawomir.nowakowski@xxxxxxxxxx>
Subject: Re: Problem with file system on iSCSI FileIO
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sat, 25 Sep 2010 11:56:12 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4C9C875D.9050308@xxxxxxxxxx>
References: <4C9B5786.4010205@xxxxxxxxxx> <20100923143221.GA1989@xxxxxxxxxxxxx> <4C9B6B27.5050606@xxxxxxxxxx> <20100924075505.GA24664@xxxxxxxxxxxxx> <4C9C875D.9050308@xxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-08-17)
> 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?

<Prev in Thread] Current Thread [Next in Thread>