* Re: [Qemu-devel] virtfs/9p duplicate inodes
@ 2019-04-20 22:41 ` Christian Schoenebeck via Qemu-devel
0 siblings, 0 replies; 5+ messages in thread
From: Christian Schoenebeck @ 2019-04-20 22:41 UTC (permalink / raw
To: qemu-devel; +Cc: Antonios Motakis, Greg Kurz
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] virtfs/9p duplicate inodes
@ 2019-04-20 22:41 ` Christian Schoenebeck via Qemu-devel
0 siblings, 0 replies; 5+ messages in thread
From: Christian Schoenebeck via Qemu-devel @ 2019-04-20 22:41 UTC (permalink / raw
To: qemu-devel; +Cc: Greg Kurz, Antonios Motakis
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] virtfs/9p duplicate inodes
2019-04-20 22:41 ` Christian Schoenebeck via Qemu-devel
(?)
@ 2019-04-23 11:44 ` Greg Kurz
2019-04-23 14:40 ` Christian Schoenebeck via Qemu-devel
-1 siblings, 1 reply; 5+ messages in thread
From: Greg Kurz @ 2019-04-23 11:44 UTC (permalink / raw
To: Christian Schoenebeck; +Cc: qemu-devel, Antonios Motakis
Hi Christian,
Sorry for the late response. I'm quite busy on other topics these days...
On Sun, 21 Apr 2019 00:41:01 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> 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 have not checked.
> 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.
>
Hmm... why would you do that ? Even if some filesystems do have persistant
inode numbers, it isn't mandatory AFAIK.
> 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.
>
The unrealize function is called when the device is unplugged from
it's parent bus. It isn't related to guest shutdown.
> Is there any callback that is guaranteed to be called on guest shutdowns?
>
There's no such thing.
> Best regards,
> Christian Schoenebeck
Cheers,
--
Greg
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] virtfs/9p duplicate inodes
@ 2019-04-23 14:40 ` Christian Schoenebeck via Qemu-devel
0 siblings, 0 replies; 5+ messages in thread
From: Christian Schoenebeck @ 2019-04-23 14:40 UTC (permalink / raw
To: qemu-devel; +Cc: Greg Kurz, Antonios Motakis
On Dienstag, 23. April 2019 13:44:42 CEST Greg Kurz wrote:
> Hi Christian,
>
> Sorry for the late response. I'm quite busy on other topics these days...
Absolutely no problem. We probably all share the same fate of constant work
load on endless battle fields popping up everywhere. :-)
> > 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.
>
> Hmm... why would you do that ? Even if some filesystems do have persistant
> inode numbers, it isn't mandatory AFAIK.
Mja, unfortunately I found that necessary, see my comment in patch 3 for the
background / reason:
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg03755.html
And sorry that my patch set did not go out as one thread today. I vow
emendation. ;-)
Best regards,
Christian Schoenebeck
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] virtfs/9p duplicate inodes
@ 2019-04-23 14:40 ` Christian Schoenebeck via Qemu-devel
0 siblings, 0 replies; 5+ messages in thread
From: Christian Schoenebeck via Qemu-devel @ 2019-04-23 14:40 UTC (permalink / raw
To: qemu-devel; +Cc: Greg Kurz, Antonios Motakis
On Dienstag, 23. April 2019 13:44:42 CEST Greg Kurz wrote:
> Hi Christian,
>
> Sorry for the late response. I'm quite busy on other topics these days...
Absolutely no problem. We probably all share the same fate of constant work
load on endless battle fields popping up everywhere. :-)
> > 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.
>
> Hmm... why would you do that ? Even if some filesystems do have persistant
> inode numbers, it isn't mandatory AFAIK.
Mja, unfortunately I found that necessary, see my comment in patch 3 for the
background / reason:
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg03755.html
And sorry that my patch set did not go out as one thread today. I vow
emendation. ;-)
Best regards,
Christian Schoenebeck
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-04-23 14:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3205397.r2gctG0f81@silver>
[not found] ` <20190330174751.1eb8e298@bahia.lan>
[not found] ` <3754934.J2WuGLFlGG@silver>
2019-04-20 22:41 ` [Qemu-devel] virtfs/9p duplicate inodes Christian Schoenebeck
2019-04-20 22:41 ` 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
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.