All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Antonios Motakis <antonios.motakis@huawei.com>,
	Greg Kurz <groug@kaod.org>
Subject: Re: [Qemu-devel] virtfs/9p duplicate inodes
Date: Sun, 21 Apr 2019 00:41:01 +0200	[thread overview]
Message-ID: <1736754.y8mDa9Bjs0@silver> (raw)
In-Reply-To: <3754934.J2WuGLFlGG@silver>

On Samstag, 30. März 2019 21:01:28 CEST Christian Schoenebeck wrote:
> On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> > Maybe have a look at this tentative to fix QID collisions:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
[snip]
> Question: so far I just had a look at that patch set, but haven't tried it
> yet. Am I correct that the inode numbers (of the same file) would actually
> change on guest side with every reboot (i.e. depending on the precise
> sequence individual files would be accessed by guest after each reboot)?

I intended to extend Antonios' patch set regarding 9p QID collisions with the 
goal to make the ids constant beyond reboots by storing the qpp_table as fs 
xattr.

My plan was to load the qpp_table in v9fs_device_realize_common() and save the 
table only once in v9fs_device_unrealize_common(), instead of storing the 
table on every new insertion. The problem though is that none of the 9p 
unrealize functions is called on guest shutdowns.

Is there any callback that is guaranteed to be called on guest shutdowns?

Best regards,
Christian Schoenebeck

WARNING: multiple messages have this Message-ID (diff)
From: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>,
	Antonios Motakis <antonios.motakis@huawei.com>
Subject: Re: [Qemu-devel] virtfs/9p duplicate inodes
Date: Sun, 21 Apr 2019 00:41:01 +0200	[thread overview]
Message-ID: <1736754.y8mDa9Bjs0@silver> (raw)
Message-ID: <20190420224101.PdFIT18KZBjwx73oYIk1NwpRrDOC3f4Rss5Y1kyVGmU@z> (raw)
In-Reply-To: <3754934.J2WuGLFlGG@silver>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1156 bytes --]

On Samstag, 30. März 2019 21:01:28 CEST Christian Schoenebeck wrote:
> On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> > Maybe have a look at this tentative to fix QID collisions:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
[snip]
> Question: so far I just had a look at that patch set, but haven't tried it
> yet. Am I correct that the inode numbers (of the same file) would actually
> change on guest side with every reboot (i.e. depending on the precise
> sequence individual files would be accessed by guest after each reboot)?

I intended to extend Antonios' patch set regarding 9p QID collisions with the 
goal to make the ids constant beyond reboots by storing the qpp_table as fs 
xattr.

My plan was to load the qpp_table in v9fs_device_realize_common() and save the 
table only once in v9fs_device_unrealize_common(), instead of storing the 
table on every new insertion. The problem though is that none of the 9p 
unrealize functions is called on guest shutdowns.

Is there any callback that is guaranteed to be called on guest shutdowns?

Best regards,
Christian Schoenebeck


       reply	other threads:[~2019-04-20 22:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3205397.r2gctG0f81@silver>
     [not found] ` <20190330174751.1eb8e298@bahia.lan>
     [not found]   ` <3754934.J2WuGLFlGG@silver>
2019-04-20 22:41     ` Christian Schoenebeck [this message]
2019-04-20 22:41       ` [Qemu-devel] virtfs/9p duplicate inodes Christian Schoenebeck via Qemu-devel
2019-04-23 11:44       ` Greg Kurz
2019-04-23 14:40         ` Christian Schoenebeck
2019-04-23 14:40           ` Christian Schoenebeck via Qemu-devel

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=1736754.y8mDa9Bjs0@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=antonios.motakis@huawei.com \
    --cc=groug@kaod.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.