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

[Victor V. Vengerov]

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.

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)
>
>


-- 
Victor V. Vengerov
OKTET Ltd.
Ulianovskaya st., 1, office 533, St.-Petersburg 198504 Russia
phone: +7 812 4284384 (work), +7 812 9389372 (mobile), +7 812 4281653 (home)