On Sep 11, 2014, at 07:47 , Peter Dufault <dufa...@hda.com> wrote: > So currently: > - I/O is not limited to the file system block size; > - The mounted block size is ignored and nfsStBlksize is used, which defaults > to 4K.
I meant 8K above. Anyway, looking through the code and the associated change log this behavior is intentional, apparently the newlib file system blocksize used to default to something small like 512 bytes and increasing the default reported size to 8K improved performance (no buffer cache on NFS). The value I'm getting now is a 4K file system blocksize on my NFS file system, I'm not sure if that's in newlib or somewhere in the NFS code, I don't see 4K there. Changing the code to go back to using the file system block size would hurt performance for everyone unless more work is done to get the default to 8K for NFS mounts. I'm just going to change the code to limit it to nfsStBlksize and put a comment about why it is the way it is. If someone understands the state of the file system code today and how it's changed over the years and wants to suggest a better fix I'll listen. So: - Default for nfsStBlksize will be 8192. - Default behavior is to ignore the file system block size (nfsStBlksize not 0), nfsStBlksize will be reported. - nfsStBlksize set to 0 will pay attention to the file system block size and limit I/O at that. I think that's the author's original intention. Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
