[PATCH 1/3] Filesystem: PR1398: Fix lseek() mechanic
chrisj at rtems.org
Tue May 8 23:53:44 UTC 2012
On 9/05/12 5:17 AM, Sebastian Huber wrote:
> On 08/05/12 08:43, Chris Johns wrote:
>> On 8/05/12 3:34 PM, Sebastian Huber wrote:
>>> Is the complex rtems_rfs_rtems_file_lseek() really necessary? What
>>> happens if we simply change the iop->offset? Will the read and write
>>> handler cope with that?
>> I do not know. The current file seek code plays with buffers. I am not
>> sure what effect this may have if the code was removed. I can see
>> moving this code would make the seek cheaper and if someone is seeking
>> with no I/O there is a cost.
>> Is there another issue I am missing ?
> I only wondered why the [PATCH 2/3] Filesystem: PR1871: Fix O_APPEND
> works (mrfs_fsrdwr test case).
Ah ok. I have taken a look at your repo in more detail and I do not
think the RFS change will work as is.
I think order for this approach to work you need to perform an RFS file
layer seek call (rather than the RFS RTEMS layer) if the iop->offset
does not match the RFS handle's position.
You could add a check in the RFS file layer seek call to see if the
handle matches the new position and do nothing if it does. This should
be light weight.
The important path here is not seeking, it is the write and read path
and the common case is repeated operations so for performance reasons it
is assumed the buffering is set up and ready and these path only do any
extra work when moving to a new block. If a seek happens it resets the
buffering so the next read or write call will move to the correct file
I am also not certain we should capture the O_APPEND open state in the
RFS RTEMS layer. It should be in the RFS file layer. I was not aware of
the requirement in append mode that all writes must append. I had
assumed this only positioned the write pointer to the end of the file
when opening. I understand if you do not wish to make this change
how-ever could you please raise a PR to have the code moved.
More information about the devel