Messages in this thread | | | Date | Mon, 19 May 2008 14:30:58 +0300 | From | Artem Bityutskiy <> | Subject | Re: [PATCH take 2] UBIFS - new flash file system |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |