On Mar 3, 2012, Sage Weil <[email protected]> wrote:
> On Sat, 25 Feb 2012, Alexandre Oliva wrote:
>> On Feb 23, 2012, Sage Weil <[email protected]> wrote:
>> > On Tue, 21 Feb 2012, Alexandre Oliva wrote:
>> >> This was supposed to fix bug 1946, and likely bug 1849 too, but it looks
>> >> like something's still missing for a complete fix.
>> create snapshot
>> check timestamps -> baseline
>> unmount
>> mount again
>> check timestamps -> same
>> restart mds
>> check timestamps -> same
>> unmount
>> mount again
>> check timestamps -> same
>> moved a tree into dir
>> check timestamps -> dir changed and snapshot unchanged, as expected
>> unmount
>> mount again
>> check timestamps -> same
>> restart mds
>> check timestamps -> snapshot changed to dir's; its size too!
> It looks like the problem is that CInode::first isn't being journaled.
I see old_inodes are being journalled properly now. I've looked further
into this tonight, and I found out what modifies the timestamps in the
inode is (re)issuing caps to a client. I had a hw watchpoint on the
timestamp in old_inodes, and it hit when I accessed the directory from a
client, with this stack trace:
#0 0x0000000000668e1d in operator= (this=0x7fffb5513370)
at ../../src/mds/mdstypes.h:375
#1 CInode::cow_old_inode (this=0x7fffe09f6630, follows=..., cow_head=true)
at ../../src/mds/CInode.cc:2035
#2 0x000000000066972e in CInode::pre_cow_old_inode (this=0x7fffe09f6630)
at ../../src/mds/CInode.cc:2058
#3 0x00000000005dac8b in Locker::scatter_writebehind (this=0x1277500,
lock=0x7fffe09f6d78) at ../../src/mds/Locker.cc:3583
#4 0x00000000005e5bac in Locker::eval_gather (this=0x1277500,
lock=0x7fffe09f6d78, first=true, pneed_issue=0x7ffff4fc4f3f,
pfinishers=0x0) at ../../src/mds/Locker.cc:686
#5 0x00000000005e993e in eval_any (need_issue=0x7ffff4fc4f3f,
lock=<optimized out>, this=0x1277500) at ../../src/mds/Locker.h:103
#6 eval_any (need_issue=0x7ffff4fc4f3f, lock=0x7fffe09f6d78, this=0x1277500)
at ../../src/mds/Locker.cc:763
#7 Locker::eval (this=0x1277500, in=0x7fffe09f6630, mask=<optimized out>)
at ../../src/mds/Locker.cc:783
#8 0x00000000005f9ff9 in Locker::handle_client_caps (this=0x1277500,
m=0x7fff683e8620) at ../../src/mds/Locker.cc:2340
#9 0x00000000004ba900 in MDS::handle_deferrable_message (this=0x1272d70,
m=0x7fff683e8620) at ../../src/mds/MDS.cc:1742
#10 0x00000000004cddae in MDS::_dispatch (this=0x1272d70, m=<optimized out>)
at ../../src/mds/MDS.cc:1833
---Type <return> to continue, or q <return> to quit---
old_inodes looks like this:
std::map with 1 elements = {[{val = 5}] = {first = {val = 2}, inode = {
ino = {val = 1099511627776}
follows is 5 and first is 2 within CInode::pre_cow_old_inode.
So, how can we stop pre_cow_old_inode from messing with the old_inode?
Any suggestions?
Thanks in advance,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
