<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 24, 2018 at 11:34 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Tue, Jul 24, 2018 at 10:46 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Tue, Jul 24, 2018 at 9:24 AM, Udit agarwal <<a href="mailto:dev.madaari@gmail.com">dev.madaari@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Jul 24, 2018 7:45 PM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Tue, Jul 24, 2018 at 10:12 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>> > On Tue, Jul 24, 2018 at 4:48 AM, Udit agarwal <<a href="mailto:dev.madaari@gmail.com">dev.madaari@gmail.com</a>><br>
>> > wrote:<br>
>> >> Hi all,<br>
>> >> I've been trying to use IMFS with a ramdisk on BBB. Here's what i did:<br>
>> >><br>
>> >> After creating a ram disk (block size:512, block count:262144), i used<br>
>> >><br>
>> >> mount_and_make_target_path("/<wbr>dev/rda","/mnt",RTEMS_<wbr>FILESYSTEM_TYPE_IMFS,RTEMS_<wbr>FILESYSTEM_READ_WRITE,NULL)<br>
>> >><br>
>> >> There is no error during bootup, but when allocating a file(in the /mnt<br>
>> >> directory) of size 10MB(or even of 1MB) it gives a file too large<br>
>> >> error.<br>
>> >> I've used similar config for RFS too and that did worked, so probably<br>
>> >> there's no issue while setting up the RAM disk.<br>
>> >><br>
>> >> I've also tried testsuite/fstests/imfs_support setup, but looks like<br>
>> >> similar<br>
>> >> method doesn't work with ram-disks<br>
>> ><br>
>> > What did you get back from mount_and_make_target_path()? Did it<br>
>> > succeed? I'm pretty sure this method should not be used for imfs, see<br>
>> > fstests/imfs_support/fs_<wbr>support.c<br>
>> ><br>
>><br>
>> Oh, I take that back. Sebastian's comment is accurate. You can<br>
>> probably make your approach work by replacing "/dev/rda" with NULL I<br>
>> would guess. The IMFS doesn't need a source, since it is backed by the<br>
>> heap.<br>
>><br>
>> Yes, Sebastian's approach worked. I'm able to generate some benchmarking<br>
>> stats on IMFS too.<br>
><br>
><br>
> I would expect the tuning parameter CONFIGURE_IMFS_MEMFILE_BYTES_<wbr>PER_BLOCK<br>
> to have a significant impact on the performance of the IMFS. The default<br>
> size is 128.<br>
> There is a block comment in cpukit/libfs/src/imfs/imfs.h which shows the<br>
> possible values.<br>
> Since the file blocks are malloc'ed, the blocks default small-ish to avoid<br>
> wasting<br>
> memory for small files.<br>
><br>
> The IMFS uses an inode structure based on that of the original UNIX<br>
> filesystem.<br>
> So as the block size goes up, you can have more and more blocks in the<br>
> maximum file size.<br>
><br>
> * The data structure for the in-memory "memfiles" is based on classic UNIX.<br>
> *<br>
> * block_ptr is a pointer to a block of IMFS_MEMFILE_BYTES_PER_BLOCK in<br>
> * length which could be data or a table of pointers to blocks.<br>
> *<br>
> * Setting IMFS_MEMFILE_BYTES_PER_BLOCK to different values has a<br>
> significant<br>
> * impact on the maximum file size supported as well as the amount of<br>
> * memory wasted due to internal file fragmentation. The following<br>
> * is a list of maximum file sizes based on various settings<br>
> *<br>
> * @code<br>
> * max_filesize with blocks of 16 is 1,328<br>
> * max_filesize with blocks of 32 is 18,656<br>
> * max_filesize with blocks of 64 is 279,488<br>
> * max_filesize with blocks of 128 is 4,329,344<br>
> * max_filesize with blocks of 256 is 68,173,568<br>
> * max_filesize with blocks of 512 is 1,082,195,456<br>
><br>
><br>
> If a system has lots of memory and wants to store larger files with lower<br>
> malloc<br>
> overhead, then the default size should be increased.<br>
><br>
> NOTE: The IMFS silently ignores requests which are not power of<br>
> 2 and are < 16 or greater than 512. See IMFS_determine_bytes_per_<wbr>block()<br>
> and its use in imfs_initsupp.c.<br>
><br>
> For the purposes of benchmarking and since the 512 upper<br>
> block size (plus implied max file size) was determined so long<br>
> ago that a 1G RAM file seemed impossible, it probably makes sense<br>
> to let people configure up to 4K or 8K as the IMFS bytes per block.<br>
><br>
</div></div>A 1 GiB RAM is still not that practical in an IMFS.<br>
<br>
What would be the maximum file sizes if we did increase it? From the<br>
above, the trend appears to be an increase by a factor of 2^4 each<br>
time, so I'd guess the max file size with blocks of 1024 would be<br>
about 16 GB, 2048 about 256 GB, and 4096 about 4 TB.<br>
<br>
There is for sure no practical reason to consider an IMFS to support<br>
file sizes larger than 16 GB for the near future...<br></blockquote><div><br></div><div>The math is in macros in imfs.h. </div><div><br></div><div>The "inode" has direct, doubly indirect, and triply indirect blocks and<br></div><div>there are (block size/ sizeof(void *)) blocks pointed to. .This is how</div><div>the original unix filesystem was done. The RFS should be similar</div><div>but I don't recall the details. This is shown here.</div><div><br></div><div><a href="https://cs.nyu.edu/courses/spring09/V22.0202-002/lectures/lecture-24.html">https://cs.nyu.edu/courses/spring09/V22.0202-002/lectures/lecture-24.html</a><br></div><div><br></div><div>We could follow the macros and compute it but I would let a computer </div><div>calculate the maximum size. Probably easier to either fix the code</div><div>and then use a small program to print the maximum size. Or hack</div><div>the macros out into a simple test program. :)</div><div><br></div><div>And hacking the macros into a simple test program is what I did. :)</div><div>See if I got the attached program right. It has one hack to account<br></div><div>for 32-bits for a pointer and not 64-bits like a native program.</div><div>64-bit pointers significantly reduce the maximum size which might</div><div>be a good reason to have larger blocks.</div><div><br></div><div><div>16 ==> 1328 or < 1MB</div><div>32 ==> 18656 or < 1MB</div><div>64 ==> 279488 or < 1MB</div><div>128 ==> 4329344 or 4MB</div><div>256 ==> 68173568 or 65MB</div><div>512 ==> 1082195456 or 1032MB</div><div>1024 ==> 17247239168 or 16448MB</div><div>2048 ==> 275415824384 or 262656MB</div></div><div><br></div><div>for 32-bit pointers. For 64-bit pointers:</div><div><br></div><div><div>16 ==> 208 or < 1MB</div><div>32 ==> 2656 or < 1MB</div><div>64 ==> 37312 or < 1MB</div><div>128 ==> 558976 or < 1MB</div><div>256 ==> 8658688 or 8MB</div><div>512 ==> 136347136 or 130MB</div><div>1024 ==> 2164390912 or 2064MB</div><div>2048 ==> 34494478336 or 32896MB</div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> And we should consider whether mis-configuring the bytes per block<br>
> in the IMFS should result in a silent defaulting or a fatal error. I know<br>
> I was surprised the last time I ran into this.<br>
><br>
</span>I filed a ticket for both.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
>><br>
>><br>
>> >> --<br>
>> >> Regards,<br>
>> >> Udit kumar agarwal<br>
>> >> <a href="http://uditagarwal.in/" rel="noreferrer" target="_blank">http://uditagarwal.in/</a><br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> users mailing list<br>
>> >> <a href="mailto:users@rtems.org">users@rtems.org</a><br>
>> >> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> users mailing list<br>
>> <a href="mailto:users@rtems.org">users@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>