diff options
| author | Alan Cudmore <alan.cudmore@gmail.com> | 2013-12-18 12:00:42 -0500 |
|---|---|---|
| committer | Chris Johns <chrisj@rtems.org> | 2013-12-19 11:07:47 +1100 |
| commit | a9619f3cb6b181f781aaf1f77931b32d0137145f (patch) | |
| tree | a372ca2a520dd44d087ecfc70d7bf97a68e8d38c | |
| parent | For PR 2162 - RFS File System - statvfs reports 1 block free (diff) | |
| download | rtems-a9619f3cb6b181f781aaf1f77931b32d0137145f.tar.bz2 | |
For PR 2164 - RFS File System - fix bitmap_create_search loop bug
This is for the RFS file system. There is a bug in the
rtems_rfs_bitmap_create_search loop. It is supposed to iterate
over the range of bits in a search element ( usually 32 bits ),
so it should loop through bits 0 through 31. Instead it loops
through 0 - 32, causing some blocks not to be allocated. As in
PR 2163, this depends on the block size and number of blocks in
a file system. Block sizes and group sizes that are powers of 2
seem to work fine ( 512 byte blocks, 4096 block groups, etc ).
When the block sizes are not powers of 2, then this loop error
causes some of the blocks at the end of a group to be skipped,
preventing 100% of the blocks from being used. A simple test
for this and PR2163 is to create a RAM disk with block size
3900 and at least 1 full group ( 31200 blocks ). A file system
with these sizes will not be able to allocate 100% of the blocks.
| -rw-r--r-- | cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c index c4050b2da8..b8bd0b3386 100644 --- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c +++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c @@ -599,7 +599,8 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* control) size -= available; - if (bit == rtems_rfs_bitmap_element_bits ()) + /* Iterate from 0 to 1 less than the number of bits in an element */ + if (bit == (rtems_rfs_bitmap_element_bits () - 1)) { bit = 0; search_map++; |