Re: [PATCH take 2] UBIFS - new flash file system

[Artem Bityutskiy]

Christoph,

thanks for the review.

Christoph Hellwig wrote:
>  - the read dir implementation won't ever support nfs exporting
>    due to having to keep per open file state.  Nor would it support
>    thing like checkpoint and restart.

We keep full name of the last readdir()'ed direntry in file->private_data
and in file->f_pos we store the direntry hash value (32 bits). The only reason
we store full name in file->private_data is name hash collisions.

We are able to restart readdir()s, but only if there are no hash collisions.
Otherwise UBIFS will restart, but probably from the wrong directory entry
(the first one in the colliding sequence).

In other words, you may do readdir, telldir, close the directory, open it
again, seekdir, and continue readdir-ing. This will mostly work as expected
unless there was hash collision, in which case you will restart from the
first direntry in the colliding sequence. I.e., telldir/seekdir mostly
work, but not always.

We thought seekdir/telldir was considered as horrible interface anyway so
we assumed it is not that big deal if it occasionally does not work as
expected.

AFAIK there are other FSes which have similar issues. Do all of them solve
this in one way or another? We have an idea of storing collision
number in directory entries and return this number in the high 32 bits of
file->f_pos (the low contain hash value) to make readdir truly restartable.
But this requires some non-trivial changes and we'd want to realize if it
is really needed.

AFAIK, even ext3 may shrink directories and fail to support readdir
restarts occasionally, but I am not 100% sure.

Could you please elaborate some more why UBIFS won't ever support nfs export?
Does NFS export need correct readdir restarts?

>  - ubifs_bg_thread shouldn't set a nice level, especially when it's the
>    default one anyway.

Well, it is also doing write-buffer flushes, not only commits. And we were
planning to add background garbage collection there as well.

--
Best Regards,
Artem Bityutskiy (ÐÑÑÑÐ ÐÐÑÑÑÐÐÐ)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/