On Fri, Feb 09, 2018 at 16:22:33 +0100, Greg Kurz wrote:
> On Thu, 8 Feb 2018 19:00:19 +0100
> <antonios.mota...@huawei.com> wrote:
(snip)
> > /* stat_to_qid needs to map inode number (64 bits) and device id (32 bits)
> > * to a unique QID path (64 bits). To avoid having to map and keep track
> > * of up to 2^64 objects, we map only the 16 highest bits of the inode plus
> > @@ -646,6 +695,10 @@ static int stat_to_qid(V9fsPDU *pdu, const struct stat
> > *stbuf, V9fsQID *qidp)
> >
> > /* map inode+device to qid path (fast path) */
> > err = qid_path_prefixmap(pdu, stbuf, &qidp->path);
> > + if (err == -ENFILE) {
> > + /* fast path didn't work, fal back to full map */
> > + err = qid_path_fullmap(pdu, stbuf, &qidp->path);
>
> Hmm... if we have already generate QIDs with fast path, how
> can we be sure we won't collide with the ones from the full
> map ?
>
> IIRC, Emilio had suggested to use bit 63 to distinguish between
> fast and slow path.
Yep. Antonios: did you consider that approach? For reference:
https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg05084.html
That would make the fast path faster by just using bit masks, which I
think it's a superior approach if indeed the assumption about top bits
being zero in most cases is accurate.
Emilio
