Re: [RESEND] [PATCH] readahead:add blk_run_backing_dev

From: Vladislav Bolkhovitin
Date: Thu Jul 16 2009 - 12:04:32 EST



Ronald Moesbergen, on 07/16/2009 06:54 PM wrote:
2009/7/16 Vladislav Bolkhovitin <vst@xxxxxxxx>:
Ronald Moesbergen, on 07/16/2009 11:32 AM wrote:
2009/7/15 Vladislav Bolkhovitin <vst@xxxxxxxx>:
The 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?
Ok. Should I still use the file-on-xfs testcase for this, or should I
go back to using a regular block device?
Yes, please

As in: Yes, go back to block device, or Yes use file-on-xfs?

File-on-xfs :)

The file-over-iscsi is quite
uncommon I suppose, most people will export a block device over iscsi,
not a file.
No, files are common. The main reason why people use direct block devices is
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.

Files also have advantages. For instance, it's easier to backup them and move between servers. On modern systems with fallocate() syscall support you don't have to do "strange dd magic" to resize files and can nearly instantaneously make them bigger. Also with pretty simple modifications scst_vdisk can be improved to make a single virtual device from several files.

And you don't lose disk space to filesystem metadata twice.

This is negligible (0.05% for XFS)

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.

Me too and I'd appreciate if someone explain it. But I don't want to introduce one more variable in the task we are solving (how to make 100+MB/s from iSCSI on your system).

I
for one will not be using files exported over iscsi, but blockdevices
(LVM volumes).

Are you sure?

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/

--
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/