[Bug 1705] RFS directory entry create and removal error

Tue Oct 5 08:54:58 UTC 2010

https://www.rtems.org/bugzilla/show_bug.cgi?id=1705

Chris Johns <chrisj at rtems.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Chris Johns <chrisj at rtems.org> 2010-10-05 03:54:57 CDT ---
Enable trace in rtems-rfs-trace.h and rebuild. The root inode is always 1:

[/] # debugrfs /ram inode 1
     1: pos=000003:0000 A links=000 mode=41c9 (DIR/711) bo=0000 bc=0002 b=[42
195 0 0 0]

The second block is 195 and a directory dump is:

[/] # debugrfs /ram dir 195
   195: block allocated
     1: 0000 inode=40     hash=b4f3ab79 name[003]=f39
     2: 000d inode=41     hash=500c591a name[003]=f40
     3: 001a inode=42     hash=b0d50979 name[003]=f41
     4: 0027 inode=43     hash=2e7b7aff name[003]=f42
     5: 0034 inode=44     hash=5fe59d40 name[003]=f43
     6: 0041 inode=45     hash=dc37771f name[003]=f44
     7: 004e inode=46     hash=386f88d9 name[003]=f45
     8: 005b inode=47     hash=8b7bee8e name[003]=f46
     9: 0068 inode=48     hash=b82d60e1 name[003]=f47
    10: 0075 inode=49     hash=41b86ef3 name[003]=f48
    11: 0082 inode=50     hash=efa30681 name[003]=f49
    12: 008f inode=51     hash=07abbd32 name[003]=f50
    13: 009c inode=52     hash=f7134dbb name[003]=f51
    14: 00a9 inode=53     hash=bf9b61d5 name[003]=f52
    15: 00b6 inode=54     hash=6b9452d2 name[003]=f53
    16: 00c3 inode=55     hash=5ac140c2 name[003]=f54
    17: 00d0 inode=56     hash=0dea6eca name[003]=f55
    18: 00dd inode=57     hash=03749ac1 name[003]=f56
    19: 00ea inode=58     hash=e350086c name[003]=f57
    20: 00f7 inode=59     hash=9d25a5e5 name[003]=f58
    21: 0104 inode=60     hash=5d572cca name[003]=f59
    22: 0111 inode=61     hash=2088a2ed name[003]=f60

Tracing the rm command:

[/] # rfs set all
[/] # rm /ram/f60
rtems-rfs: inode-open: ino: 1
rtems-rfs: inode-load: ino=1 loads=0 loaded=no 
rtems-rfs: buffer-request: block=3
rtems-rfs: buffer-request: block=3 bdbuf-read=3 refs=1
rtems-rfs: dir-lookup-ino: lookup ino: root=1, path=f60, len=3
rtems-rfs: inode-load: ino=1 loads=1 loaded=yes
rtems-rfs: inode-unload: ino=1 loads=2 loaded=yes
rtems-rfs: buffer-request: block=42
rtems-rfs: buffer-scan: count=1, block=42: 3 : not found
rtems-rfs: buffer-request: block=42 bdbuf-read=42 refs=1
rtems-rfs: buffer-request: handle has buffer: 42
rtems-rfs: buffer-release: block=42  refs=1
rtems-rfs: buffer-request: block=195
rtems-rfs: buffer-scan: count=1, block=195: 3 : not found
rtems-rfs: buffer-scan: count=1, block=195: 42 : not found
rtems-rfs: buffer-request: block=195 bdbuf-read=195 refs=1
rtems-rfs: dir-lookup-ino: checking entry for ino 1: off=0111 length:13 ino:61
rtems-rfs: dir-lookup-ino: entry found in ino 1, ino=61 offset=273

The directory look up returns an offset of 273 which is the offset in the block
how-ever this is the 2nd block and so it should be 512 + 273. It seems the
block map seek is not incrementing the block number correctly in the map's
block position when moving of the 0 position. This offset is used in the unlink
(rm) path to save the unlink code needing to scan the directory again. The code
currently works because the directory entry removal code in the RFS uses the
offset to get the block and then scans the block. If the inode is not found in
that block it searches the remainder of the directory including the remaining
blocks. When deleting from the first entry to the last the entry the removal
work because the block is empty and so you move onto the next block how-ever
deleting from the other direction fails because the wrong block is selected.

The fix is to find out why the block number in the map seek (find) is not
updating the position correctly and fix. The second part is to fix the
directory removal to seek to the correct location.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.