2011/8/1 Sage Weil <sage@xxxxxxxxxxxx>: > On Mon, 1 Aug 2011, Theodore Tso wrote: >> On Jul 31, 2011, at 4:42 PM, Sage Weil wrote: >> >> > This is link(2) >> > >> >> 2011-07-31 23:06:50.114316 7f23c048c700 filestore(/osd.0) collection_remove >> >> temp/10000000483.000005d6/head = 0 >> > >> > This is unlink(2) >> > >> >> 2011-07-31 23:06:50.114384 7f23c048c700 filestore(/osd.0) setattrs >> >> 0.69_head/10000000483.000005d6/head '_' len 161 = 161 >> > >> > The xattr names are prefixed with 'user.ceph.' >> > >> >> 2011-07-31 23:06:50.114406 7f23c048c700 filestore(/osd.0) setattrs >> >> 0.69_head/10000000483.000005d6/head 'snapset' len 26 = 26 >> >> 2011-07-31 23:06:50.114413 7f23c048c700 filestore(/osd.0) setattrs >> >> 0.69_head/10000000483.000005d6/head = 26 >> > >> > Does that tell you what to need, Ted? >> >> So let me make sure I understand what happened. Ceph made sure no file existed with this name, and created with the first write log entry: >> >> 2011-07-31 23:06:49.173941 7f23c048c700 filestore(/osd.0) write temp/10000000483.000005d6/head 0~1048576 = 1048576 > > The fd was actually closed here. > >> It then linked it into this directory: >> >> 2011-07-31 23:06:50.114287 7f23c048c700 filestore(/osd.0) collection_add 0.69_head/10000000483.000005d6/head temp/10000000483.000005d6/head = 0 >> >> ? and removed it from the temp directory: >> >> 2011-07-31 23:06:50.114316 7f23c048c700 filestore(/osd.0) collection_remove temp/10000000483.000005d6/head = 0 >> >> and then created three inodes that totaled approximately 240 bytes in length or so (including the name and headers) > xattrs >> >> 2011-07-31 23:06:50.114384 7f23c048c700 filestore(/osd.0) setattrs 0.69_head/10000000483.000005d6/head '_' len 161 = 161 >> 2011-07-31 23:06:50.114406 7f23c048c700 filestore(/osd.0) setattrs 0.69_head/10000000483.000005d6/head 'snapset' len 26 = 26 >> 2011-07-31 23:06:50.114413 7f23c048c700 filestore(/osd.0) setattrs 0.69_head/10000000483.000005d6/head = 26 >> >> ? and then presumably the file was closed and that would have been the >> end of this file being touched by ceph, correct? > > Yep! I tried to reproduce this without ceph, but wasn't able to... In the meantime it seams, that I can also see the side effects on the librbd side: I get an "librbd: data error!" when I do an "rbd copy". When I look at the librbd code this is related to a sparse_read not returning the right size of the object. I don't know if it helps, but I think that the problem is also related to sparse file usage. Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
