Cursor in readdir
Hi Miklos,
Sorry for disturb you. I'm confused with *cursor* in struct ovl_dir_file. I know this struct ovl_cache_entry *cursor* is presented to indicate current pos when performing readdir at a MERGE type directory.
Why this additional entry is needed? Can't we use a pointer to record which entry is read or is ready for reading? After finish reading lower and upper directories, entries in struct ovl_dir_cache is stabilized. Changing of directories will cause the later .readdir() to create a new ovl_dir_cache but the old cache will not be released until all the holders of it call .release().
So I think a pointer points to an entry in the entry list of ovl_dir_cache is enough to each process sharing the access of the same cache. We don't need to keep and move an special entry, *cursor*. That's my thought.
I've considered a lot and googled some key words but found nothing. Did I miss something important?
It will be fine if you'd like to explain the requirement of *cursor* in readdir. Thanks a lot~!
Hu
Quoted 15 lines · hujianyang
Hi Miklos,
Sorry for disturb you. I'm confused with *cursor* in struct
ovl_dir_file. I know this structovl_cache_entry*cursor* is presented to indicate current pos when performing readdir at a MERGE type directory.Why this additional entry is needed? Can't we use a pointer to record which entry is read or is ready for reading? After finish reading lower and upper directories, entries in struct
ovl_dir_cacheis stabilized. Changing of directories will cause the later .readdir() to create a newovl_dir_cachebut the old cache will not be released until all the holders of it call .release().
Quoted 4 lines
So I think a pointer points to an entry in the entry list of
ovl_dir_cacheis enough to each process sharing the access of the same cache. We don't need to keep and move an special entry, *cursor*. That's my thought.
Cursors are safe against removal of current entry. However, we don't
do that here, AFAICS, so I think you are correct in that the cursor is not actually needed here.
Thanks,
Miklos
Quoted 16 lines · Miklos Szeredi
Quoted 15 lines · hujianyang
Hi Miklos,
Sorry for disturb you. I'm confused with *cursor* in struct
ovl_dir_file. I know this structovl_cache_entry*cursor* is presented to indicate current pos when performing readdir at a MERGE type directory.Why this additional entry is needed? Can't we use a pointer to record which entry is read or is ready for reading? After finish reading lower and upper directories, entries in struct
ovl_dir_cacheis stabilized. Changing of directories will cause the later .readdir() to create a newovl_dir_cachebut the old cache will not be released until all the holders of it call .release().
Quoted 9 lines
Quoted 4 lines
So I think a pointer points to an entry in the entry list of
ovl_dir_cacheis enough to each process sharing the access of the same cache. We don't need to keep and move an special entry, *cursor*. That's my thought.Cursors are safe against removal of current entry. However, we don't
do that here, AFAICS, so I think you are correct in that the cursor is not actually needed here.
Thanks~!
Do you think it's valuable to discard the using of *cursor* and use a pointer instead? Or maybe we will enable some remove operations for ovl_dir_cache in the future so we should keep this mechanism.
What's your opinion? I'd like to change this part and see if the usage of a pointer could speed up .readdir() on a merged directory.
Cheers,
Hu
Quoted 6 lines · hujianyang
On 2014/12/1 23:26, Miklos Szeredi wrote:
Do you think it's valuable to discard the using of *cursor* and use a pointer instead? Or maybe we will enable some remove operations for
ovl_dir_cachein the future so we should keep this mechanism.
Will probably need to do remove operations on merged layers as whiteouts anyway, which does not involve actual removal of entry. So I guess the cursor won't be needed.
Quoted 3 lines
What's your opinion? I'd like to change this part and see if the usage of a pointer could speed up .readdir() on a merged directory.
If it's a cleanup (removes more complexity than it adds) then a patch is welcome.
Thanks,
Miklos