Can't seem to fill up my RFS filesystem

Mohammed Saeed Khoory Mohammed.Khoory at eiast.ae
Sun Apr 19 06:47:02 UTC 2015


Hi,

I'm using RTEMS 4.10.2 with a LEON3-FT, and I've noticed a strange issue with my RFS-formatted RAMDisk. My RAMDisk has a total capacity of 6MB, and I'm using default values for formatting it with RFS. It seems that at some point, I cannot open or write to files, with write() and open() returning ENOSPC. However, statvfs tells me that I have around 2MB left, so this shouldn't happen.

While investigating, I wrote a small test with my code, where it opens a file, writes 8000 bytes to it, then closes it, and repeats, until it encounters an error. In between, I print out the results of the shell command "debugrfs group". This is what I got

Writing file 960 of 100000 with 8000 bytes, size free: 1995264
    0: base=1       size=4096   blocks=4096  (100%) inode=369   (100%)
    1: base=4097    size=4096   blocks=4096  (100%) inode=136   ( 36%)
    2: base=8193    size=4095   blocks=216   (  5%) inode=0     (  0%)
Writing file 961 of 100000 with 8000 bytes, size free: 1986560
    0: base=1       size=4096   blocks=4096  (100%) inode=369   (100%)
    1: base=4097    size=4096   blocks=4096  (100%) inode=137   ( 37%)
    2: base=8193    size=4095   blocks=233   (  5%) inode=0     (  0%)
Writing file 962 of 100000 with 8000 bytes, size free: 1977856
    0: base=1       size=4096   blocks=4096  (100%) inode=369   (100%)
    1: base=4097    size=4096   blocks=4096  (100%) inode=138   ( 37%)
    2: base=8193    size=4095   blocks=250   (  6%) inode=0     (  0%)
Writing file 963 of 100000 with 8000 bytes, size free: 1969152
open_mod: cannot initially open file, path=/ram:0/00000962.TST, flags=512, errno=28

I've been reading about the structure of RFS at the same time, and while I don't fully understand it, I do understand that the filesystem is divided into groups, each group having a certain number of blocks that could be allocated to files. From the output it seems that the last group isn't being used up at all, and allocating space for new files fails, even though there's a good amount left.

I've noticed that there's a bug that I thought might've been related to this issue, located here: https://lists.rtems.org/pipermail/bugs/2013-December/004658.html . I've patched the 4.10.2 source, however this didn't solve the problem. I'm also not sure if this problem exists in 4.11

Is there any explanation for this?

Best Regards,
Mohammed Saeed Khoory



More information about the users mailing list