[9fans] reuse of values of qid.path

[9fans] reuse of values of qid.path

[philw]

the namespace code in the kernel will not work
unless qid.path is unique for a given mounted
connection. I suggest you don't reuse them.

phil

[9fans] reuse of values of qid.path

[Srinivas.Narendula]

How important is it to not reuse old values of qid.path?

The current fileserver uses sb->qidgen to give a new file/dir
a new path value, but allows duplicates since there is no
handling of overflow.  There is a "check" command option called
"setqid" to resequence the qids if qidgen is in danger of overflow,
but was not implemented.

Having two files/directories with the same qid.path is a "bad thing",
but is possible in the current system.

It seems that qid.path is used like an inode number (and in fact is
the device and inode number in u9fs).  If that is the case, then
instead of using qidgen, use the block address of the directory
block shifted by the size of the slot and or'ed with the slot.

qid.path = (p->addr << log2(DIRPERBUF)) | (slot % DIRPERBUF);

The only problem is that the sequence:

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x a

would result in the two files having the same qid and so would

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x b

but

    cp file_of_size_x a
    cp different_file_of_size_x a

would not (since cp does a truncate before a create).

So again, how important is that?

David Butler
gdb@dbSystems.com

[9fans] reuse of values of qid.path

[Srinivas.Narendula]

How important is it to not reuse old values of qid.path?

The current fileserver uses sb->qidgen to give a new file/dir
a new path value, but allows duplicates since there is no
handling of overflow.  There is a "check" command option called
"setqid" to resequence the qids if qidgen is in danger of overflow,
but was not implemented.

Having two files/directories with the same qid.path is a "bad thing",
but is possible in the current system.

It seems that qid.path is used like an inode number (and in fact is
the device and inode number in u9fs).  If that is the case, then
instead of using qidgen, use the block address of the directory
block shifted by the size of the slot and or'ed with the slot.

qid.path = (p->addr << log2(DIRPERBUF)) | (slot % DIRPERBUF);

The only problem is that the sequence:

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x a

would result in the two files having the same qid and so would

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x b

but

    cp file_of_size_x a
    cp different_file_of_size_x a

would not (since cp does a truncate before a create).

So again, how important is that?

David Butler
gdb@dbSystems.com

[9fans] reuse of values of qid.path

[Srinivas.Narendula]

How important is it to not reuse old values of qid.path?

The current fileserver uses sb->qidgen to give a new file/dir
a new path value, but allows duplicates since there is no
handling of overflow.  There is a "check" command option called
"setqid" to resequence the qids if qidgen is in danger of overflow,
but was not implemented.

Having two files/directories with the same qid.path is a "bad thing",
but is possible in the current system.

It seems that qid.path is used like an inode number (and in fact is
the device and inode number in u9fs).  If that is the case, then
instead of using qidgen, use the block address of the directory
block shifted by the size of the slot and or'ed with the slot.

qid.path = (p->addr << log2(DIRPERBUF)) | (slot % DIRPERBUF);

The only problem is that the sequence:

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x a

would result in the two files having the same qid and so would

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x b

but

    cp file_of_size_x a
    cp different_file_of_size_x a

would not (since cp does a truncate before a create).

So again, how important is that?

David Butler
gdb@dbSystems.com

[9fans] reuse of values of qid.path

[G.David]

How important is it to not reuse old values of qid.path?

The current fileserver uses sb->qidgen to give a new file/dir
a new path value, but allows duplicates since there is no
handling of overflow.  There is a "check" command option called
"setqid" to resequence the qids if qidgen is in danger of overflow,
but was not implemented.

Having two files/directories with the same qid.path is a "bad thing",
but is possible in the current system.

It seems that qid.path is used like an inode number (and in fact is
the device and inode number in u9fs).  If that is the case, then
instead of using qidgen, use the block address of the directory
block shifted by the size of the slot and or'ed with the slot.

qid.path = (p->addr << log2(DIRPERBUF)) | (slot % DIRPERBUF);

The only problem is that the sequence:

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x a

would result in the two files having the same qid and so would

    cp file_of_size_x a
    rm a
    cp different_file_of_size_x b

but

    cp file_of_size_x a
    cp different_file_of_size_x a

would not (since cp does a truncate before a create).

So again, how important is that?

David Butler
gdb@dbSystems.com