From: Chen Gang <gang.chen.5i5j@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, anthony@codemonkey.ws
Subject: Re: [Qemu-devel] [PATCH 4/5] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation
Date: Sun, 16 Mar 2014 21:32:32 +0800 [thread overview]
Message-ID: <5325A7F0.9000300@gmail.com> (raw)
In-Reply-To: <531B21F1.7030009@gmail.com>
On 03/08/2014 09:58 PM, Chen Gang wrote:
> OK, thanks.
>
> Next, I will/should continue to analyse the performance issue for 9pfs
> when users drop into a long directory path under bash shell.
>
After have a test, I am sure it is not 9pfs issue, either not Qemu's
issue, it's Linux kernel vfs or block sub-systems' issue. The related
test environments (originally, our 9pfs is upper on ext4):
- for ext4 file system under my Fedora laptop (Qemu does not start).
- for ntfs file system under my Fedora laptop (Qemu does not start).
- for ext4 file system under my Ubuntu in Qemu.
For a very long file name (e.g. > 3K long), all of them are very very
slow. (and I also tested the ext2 /boot partition under Ubuntu in Qemu,
it is not slow, I guess the reson is its partition size is small).
Next, I will/shall communicate with upstream kernel for it. :-)
> Although I am not quite sure, hope I can find the root cause within
> month (2014-03-31).
>
> Welcome any suggestions, discussions, and completions for it.
>
> Thanks.
>
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
next prev parent reply other threads:[~2014-03-16 13:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 15:16 [Qemu-devel] [PULL] VirtFS update Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 1/5] fsdev: Fix overrun after readlink() fills buffer completely Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 2/5] hw/9pfs/virtio-9p-local.c: move v9fs_string_free() to below "err_out:" Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 3/5] hw/9pfs/virtio-9p-local.c: use snprintf() instead of sprintf() Aneesh Kumar K.V
2014-03-07 15:16 ` [Qemu-devel] [PATCH 4/5] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation Aneesh Kumar K.V
2014-03-08 13:58 ` Chen Gang
2014-03-16 13:32 ` Chen Gang [this message]
2014-03-18 0:31 ` [Qemu-devel] [PATCH trivial] target-arm/gdbstub64.c: remove useless 'break' statement Chen Gang
2014-03-18 0:39 ` Peter Maydell
2014-03-18 0:53 ` Chen Gang
2014-03-18 5:14 ` Peter Crosthwaite
2014-03-19 3:25 ` Chen Gang
2014-03-23 13:27 ` [Qemu-devel] [PATCH 4/5] hw/9pfs: use g_strdup_printf() instead of PATH_MAX limitation Chen Gang
2014-03-07 15:16 ` [Qemu-devel] [PATCH 5/5] hw/9pfs: Include virtio-9p-device.o in build Aneesh Kumar K.V
2014-03-07 15:30 ` Andreas Färber
2014-03-07 17:07 ` Aneesh Kumar K.V
2014-03-08 12:52 ` [Qemu-devel] [PULL] VirtFS update Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5325A7F0.9000300@gmail.com \
--to=gang.chen.5i5j@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).