(Fwd) Re: DOSFS bug fixes, IDE drivers and sample released

[Angelo Fraietta]

Victor V. Vengerov wrote:

> Angelo,
>
> I beleive, you need to use fflush(fp) before fsync.
> libc has own buffers associated with stream. These
> buffers need to be flushed to the disk buffers before
> disk buffers actually written to the disk.

This worked

>
> Alternatively, you may use setvbuf() to disable libc
> buffering.
>
> Regards,
> Victor
>
> Angelo Fraietta wrote:
>
>> fsync does not seem to be working as I think it should.
>>
>> I have a large file that already exists on the drive.
>>
>> I do the following:
>> File* fp = fopen (filename, "w+b");
>>
>> if (fp)
>> {
>>     char c = 'a';
>>     fwrite (&a, 1, 1, fp);
>>     fsync(fileno(fp));
>>     fclose (fp);
>>     restartRtems();
>> }
>>
>> The file on disk remains unchanged
>>
>> Eugeny S. Mints wrote:
>>
>>> On Wed, 16 Apr 2003, Joel Sherrill wrote:
>>>
>>>  
>>>
>>>> "Eugeny S. Mints" wrote:
>>>>   
>>>>
>>>>> On Wed, 16 Apr 2003, Joel Sherrill wrote:
>>>>>
>>>>>     
>>>>>
>>>>>> Chris Caudle wrote:
>>>>>>
>>>>>>       
>>>>>>
>>>>>>>> I have found that listing the directory after closing the file
>>>>>>>> seems to do the trick. It must purge the buffers to the disk.
>>>>>>>>
>>>>>>>>
>>>>>>>>           
>>>>>>>
>>>>>>> I haven't looked at the DOSFS code yet, does it have a sync() or 
>>>>>>> fsync() function?
>>>>>>> If the file system keeps the allocation table cached in memory, 
>>>>>>> you may need to flush the allocation table to the storage 
>>>>>>> device, especially if you are shutting down power on the RTEMS 
>>>>>>> system and moving the storage device to a different machine (or 
>>>>>>> just re-booting into Windows, Linux, MacOS etc. on the same 
>>>>>>> machine).
>>>>>>>
>>>>>>>
>>>>>>>         
>>>>>>
>>>>>> Or at least a flush() on the file itself?
>>>>>>       
>>>>>
>>>>> Sorry, that I was silent for a long time but I was away from
>>>>> my  mail box.
>>>>>
>>>>> As to sync/fsync/flush - sync call is implemented in DOSFS.
>>>>> I suppose that Angelo needs UNmount the volume to achieve
>>>>> his  goals. During 'unmount' a volume is automatically
>>>>> syncronized.
>>>>>     
>>>>
>>>> I understand that it has to sync when unmounting but shouldn't
>>>> sync work even with it staying mounted?  I think the issue here
>>>> was simply that he was surprised it wasn't written until he closed.
>>>> [NOTE: This is standard behavior for many systems so is not 
>>>> unexpected.]
>>>>
>>>> So the question is.. if I have an open file and want to ensure its
>>>> contents are written to disk, is it sufficient to sync() or should
>>>> it flush() and sync() and what?  I think unmounting is a bit too
>>>> heavy handed because it potentially impacts other tasks.
>>>>   
>>>
>>>
>>> If you have an open file and want to ensure its
>>> contents are written to disk you shoul sync() it - and this
>>> sync call is implemented in DOSFS.
>>>
>>>  
>>>
>>>>>> Not to get me started on a tangent but my disertation included some
>>>>>> thought on the idea
>>>>>> that different embedded systems needed different disk caching and
>>>>>> scheduling algorithms.
>>>>>> Ideally those should be selectable on a per-file basis but at a
>>>>>> partition level would be
>>>>>> acceptable.  For example, a write-only log file should have data 
>>>>>> kept
>>>>>> only long enough to
>>>>>> get it to disk but a sequentially read file could use read-ahead and
>>>>>> discard as soon as
>>>>>> the application read the data.  With some (intelligent) hints 
>>>>>> from the
>>>>>> application,
>>>>>> the algorithms could be better selected.
>>>>>>
>>>>>>       
>>>>>>
>>>>>>> -- Chris Caudle
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>         
>>>>>>
>>>>>>       
>>>>>
>>>>> -- 
>>>>> Eugeny S. Mints
>>>>> OKTET Ltd.
>>>>> 1 Ulianovskaya st., Petergof, St.Petersburg, 198904 Russia
>>>>> Phone: +7(812)428-4384 Fax: +7(812)327-2246
>>>>> mailto:Eugeny.Mints at oktet.ru
>>>>>     
>>>>
>>>
>>>  
>>>
>>
>> -- 
>> Angelo Fraietta
>>
>> PO Box 859
>> Hamilton NSW 2303
>>
>> Home Page
>>
>>
>> http://www.users.bigpond.com/angelo_f/
>>
>> There are those who seek knowledge for the sake of knowledge - that 
>> is CURIOSITY
>> There are those who seek knowledge to be known by others - that is 
>> VANITY
>> There are those who seek knowledge in order to serve - that is LOVE
>>    Bernard of Clairvaux (1090 - 1153)
>>
>>
>
>

-- 
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page


http://www.users.bigpond.com/angelo_f/

There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)