Re: [Qemu-devel] virtfs/9p duplicate inodes

Re: [Qemu-devel] virtfs/9p duplicate inodes

[Christian Schoenebeck]

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

Re: [Qemu-devel] virtfs/9p duplicate inodes

[Christian Schoenebeck via Qemu-devel]

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

Re: [Qemu-devel] virtfs/9p duplicate inodes

[Greg Kurz]

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

Re: [Qemu-devel] virtfs/9p duplicate inodes

[Christian Schoenebeck]

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

Re: [Qemu-devel] virtfs/9p duplicate inodes

[Christian Schoenebeck via Qemu-devel]

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