2009/7/16 Vladislav Bolkhovitin <vst@xxxxxxxx>:Ronald Moesbergen, on 07/16/2009 11:32 AM wrote:2009/7/15 Vladislav Bolkhovitin <vst@xxxxxxxx>:Yes, pleaseOk. Should I still use the file-on-xfs testcase for this, or should IThe drop with 64 max_sectors_kb on the client is a consequence of how
CFQ
is working. I can't find the exact code responsible for this, but from
all
signs, CFQ stops delaying requests if amount of outstanding requests
exceeds
some threshold, which is 2 or 3. With 64 max_sectors_kb and 5 SCST I/O
threads this threshold is exceeded, so CFQ doesn't recover order of
requests, hence the performance drop. With default 512 max_sectors_kb
and
128K RA the server sees at max 2 requests at time.
Ronald, can you perform the same tests with 1 and 2 SCST I/O threads,
please?
go back to using a regular block device?
As in: Yes, go back to block device, or Yes use file-on-xfs?
The file-over-iscsi is quiteNo, files are common. The main reason why people use direct block devices is
uncommon I suppose, most people will export a block device over iscsi,
not a file.
a not supported by anything believe that comparing with files they "have
less overhead", so "should be faster". But it isn't true and can be easily
checked.
Well, there are other advantages of using a block device: they are
generally more manageble, for instance you can use LVM for resizing
instead of strange dd magic to extend a file. When using a file you
have to extend the volume that holds the file first, and then the file
itself.
And you don't lose disk space to filesystem metadata twice.
Also, I still don't get why reads/writes from a blockdevice are
different in speed than reads/writes from a file on a filesystem.
I
for one will not be using files exported over iscsi, but blockdevices
(LVM volumes).
Ronald.--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/