The stdio buffer size is 1024 bytes, and hasn't changed since at least 6.3.0.

________________________________
From: David Sarrazin
Sent: Friday, May 18, 2018 6:03 PM
To: general-filesystems
Subject: Re: QNX 7 Ramdisk Caching Question

Tim,

That sounds more like fwrite buffering, so MyApp isn't even sending the data to the FS.  The redirect causes studio to 
become fully buffered, which means it will only flush to the filesystem once the internal stream buffer is full, or an 
fflush() is called.   This is POSIX behaviour so will not have changed since 6.3.2.   I'll check if the buffer size 
changed between that version and 7.0.

If you can change the code, adding

setvbuf(stdout, NULL, _IOLBF);

In your program startup will force stdout to flush after every newline, instead of when the buffer is full.

David

Sent from my BlackBerry - the most secure mobile device
From: community-noreply@qnx.com
Sent: May 18, 2018 5:27 PM
To: general-filesystems@community.qnx.com
Reply-to: general-filesystems@community.qnx.com
Subject: Re: RE: QNX 7 Ramdisk Caching Question


David,

Thanks for the fast reply!

>  These include deferring I/O to the "disk" as long as possible.

Is there a way to turn this off? I'd like to get the same behavior I have under 6.3.2. I only used all the extra options
 in the wiki page because it said it was the fastest way to write data. I don't mind slightly slower writes (it is RAM 
after all so it's already lightning fast) if they occur immediately.

I can 100% reliably produce the problem where data is not available in the RAM log.
Normally I start my app as ./myApp >/fs/ram/myLogFile to redirect stdout to log file.
If I just start ./myApp I see everything printed immediately as the code executes.
If I do the redirect to the log file on the RAM disk I do not get anything in the file until a certain amount of data is
 logged. It appears at a glance to be probably pretty close to that 512 value (bytes?). So roughly every 512 characters 
sent to the file tends to get the next block write to occur to update the file.

So would changing that cache size from 512 matter or is there some other option to look at?

Tim

> Tim,
>
> devb-ram looks and behaves like a real disk, as far as the io-blk layer and
> filesystem are concerned.  The io-blk internal ramdisk which you are now using
> , is understood by the io-blk caching layer to be a transient RAM disk, and
> some optimizations are made.  These include deferring I/O to the "disk" as
> long as possible.
>
> With that said, if you write to a file, and then read the file back, you
> should absolutely see the data that you wrote, immediately.  The power-safe
> filesystem itself still does not realize that the underlying device is a RAM
> disk, and doesn't take any special action.
>
> David




_______________________________________________

General
http://community.qnx.com/sf/go/post118833
To cancel your subscription to this discussion, please e-mail general-filesystems-unsubscribe@community.qnx.com<mailto:
general-filesystems-unsubscribe@community.qnx.com>;