On Thu, 25 Jan 2018 17:08:40 +0100 Veaceslav Falico <veaceslav.fal...@huawei.com> wrote:
> On 1/25/2018 3:46 PM, Veaceslav Falico wrote: [...] > > > > I've reproduced it today without fscache: > > > > host: > > mount -o bind /tmp/mounted t1 > > mount -o bind /tmp/mounted t2 > > > > guest: > > / # tail -f t1/file & > > / # 321 > > > > / # cat t2/file > > 321 > > / # > > > > host: > > mv t1/file t1/file_moved > > > > guest: > > / # cat t2/file > > cat: can't open 't2/file': No such file or directory > > / # mount | grep fscache > > / # > > Sorry, disregard this test case, it's operating normally - > when we move the t1/file, we also move the t2/file, as they're > the same directory... Sorry, it's a brainfart after a long > discussion about the issue :). > No problem :) > So, it's still not reproducible without (fs)cache guest-side. > > > Anyway, the question below still stands - is the guest > allowed to re-use the FIDs for the files with same QIDs? > AFAIU FIDs have a 1:1 relation to either a path in the file hierarchy or to an open file. I don't think they can be re-used. > > > > Also, per internal discussions, we're not sure if the guest side > > is allowed to reuse the FIDs opened previously for same QID.paths. > > > > QEMU holds FID.path for each FID, which contains the actual FS path, > > i.e. "/path/to/file". > > > > So, if we (guest) have two "identical" (per QID.path and RFC) files > > (f1 and f2), though in different directories (host and guest), and > > we've accessed f1 once (FID 10, for example) - are we allowed to > > re-use FID 10 for f2, if f1's QID.path == f2's QID.path ? > > > >> > >>> > >>>> > >>>> Thanks, > >>>> Eduard. > >>>> > >>>>> > >>>>>>> > >>>>>>>> With our proof of concept patch, the issues caused by qid path > >>>>>>>> collisions go away, so it can be seen as an interim solution of > >>>>>>>> sorts. However, the chance of collisions is not eliminated, we are > >>>>>>>> just replacing the current strategy, which is almost guaranteed to > >>>>>>>> cause collisions in certain use cases, with one that makes them more > >>>>>>>> rare. We think that a virtio feature flag for longer qid paths is > >>>>>>>> the only way to eliminate these issues completely. > >>>>>>>> > >>>>>>>> This is the extent that we were able to analyze the issue from our > >>>>>>>> side, we would like to hear if there are some better ideas, or which > >>>>>>>> approach would be more appropriate for upstream. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> > >>>>>>> -- > >>>>>>> Greg > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> . > >>>> > >>> > >>> > >> > >> . > >> > > > >