Messages in this thread | | | Date | Fri, 22 Apr 2022 11:10:28 +0800 | Subject | Re: [PATCH v9 08/21] cachefiles: document on-demand read mode | From | JeffleXu <> |
| |
Hi David, thanks for polishing the documents. It's a detailed and meticulous review again. Really thanks for your time :) I will fix all these in the next version.
On 4/21/22 10:47 PM, David Howells wrote: > Jeffle Xu <jefflexu@linux.alibaba.com> wrote: > >> +The essential difference between these two modes is that, in original mode, >> +when a cache miss occurs, the netfs will fetch the data from the remote server >> +and then write it to the cache file. With on-demand read mode, however, >> +fetching the data and writing it into the cache is delegated to a user daemon. > > The starting sentence seems off. How about: > > The essential difference between these two modes is seen when a cache miss > occurs: In the original mode, the netfs will fetch the data from the remote > server and then write it to the cache file; in on-demand read mode, fetching > data and writing it into the cache is delegated to a user daemon.
Okay, it sounds better.
>> the devnode ('/dev/cachefiles') to check if >> +there's a pending request to be processed. A POLLIN event will be returned >> +when there's a pending request. >> + >> +The user daemon then reads the devnode to fetch a request and process it >> +accordingly. > > Reading the devnode doesn't process the request, so I think something like: > > "... and process it accordingly" -> "... that it can then process." > > or: > > "... and process it accordingly" -> "... to process."
Yeah the original statement is indeed misleading.
>> Each cache file has a unique object_id, while it >> +may have multiple anonymous fds. The user daemon may duplicate anonymous fds >> +from the initial anonymous fd indicated by the @fd field through dup(). Thus >> +each object_id can be mapped to multiple anonymous fds, while the usr daemon >> +itself needs to maintain the mapping. >> + >> +With the given anonymous fd, the user daemon can fetch data and write it to the >> +cache file in the background, even when kernel has not triggered a cache miss >> +yet. >> + >> +The user daemon should complete the READ request > > READ request -> OPEN request?
Good catch. Will be fixed.
>> in the READ request. The ioctl is of the form:: >> + >> + ioctl(fd, CACHEFILES_IOC_CREAD, msg_id); >> + >> + * ``fd`` is one of the anonymous fds associated with the given object_id >> + in the READ request. > > the given object_id in the READ request -> object_id > >> + >> + * ``msg_id`` must match the msg_id field of the previous READ request. > > By "previous READ request" is this referring to something different to "the > READ request" you mentioned against the fd parameter?
Actually it is referring to the same thing (the same READ request). I will change the statement simply to:
``msg_id`` must match the msg_id field of the READ request.
-- Thanks, Jeffle
| |