sf...@users.sourceforge.net: > Kirill Kolyshkin: > > The only way to make sure is to retry reading /proc/mounts. Or, do > > stat+statfs > > (exactly as you suggested below) to check that this is indeed the aufs root > > directory (and then you still need to retry reading /proc/mounts). > > Give me some more time about this topic. I will consider again.
Reading the code for reading /proc/mounts, - There are two internal read buffers. One in the kernel-space, and the other is in user-space. - The size of the kernel buffer is PAGE_SIZE(4K) by default. Issueing read(2), kernel generates the readable strings from the mounts in that buffer. When the buffer becomes full, read(2) returns. In this case, it is "short-read". - The size of user buffer is the one in stdio FILE* which you are very familiar. Even if we enlarge the user buffer, the size of the kernel buffer is still 4K and we have to issue read(2) again. - Every time when we read(2) /proc/mounts, the kernel aquires a lock to prohibit a new mount/unmount and make the list of current mounts stable and reliable. - Returning read(2), the lock is released. Then other waited mount/unmount tasks wake up and re-start their job. - And the list of current mounts becomes inconsistency. The date which second read(2) gets is not the continuous data from the first read(2). As a small experiment, I have succeeded your github.com/kolyshkin/procfs-test after increasing both buffers to 8K. Now I am refining my experimental code to make it generic. If it succeeds, I will suggest it to LKML. Give me some more time. If we have a patch to the kernel-space, will it help you? Or is it unusable for you? J. R. Okajima
