Hi Alexander, On Tue, 2013-03-19 at 02:31 +0400, Alexander Bezrukov wrote: [snip] > > > So, I need in raw dump of three segments #23443 (ss_seq = 305301, > > first block #48011264), #23444 (ss_seq = 305302, first block > > #48013312), #23445 (ss_seq = 305303, first block #48015360). > > Please, make raw dump from #48011264 till #48017408 (namely, > > 6144 blocks) > > A small note: 48017408-48011264+1 = 6145 > > > and share with me. Moreover, please, share dumpseg output > > for this segments. > > I prepared the dumpseg output for these segments. Please find it > at http://www.dragonworks.ru/nilfs2/dumpseg.log . > Thank you for dumpseg output. > As to the raw data, these blocks happened to contain some quite > sensitive information. I won't share this information > publicitly and would avoid leaking it as much as it seems > reasonable. If this data is of real and great help, please > let me know, I will prepare and send a link privately. > Sorry about that. > Ok. I see. But I really need to have for analysis as minimum last segment's raw content #23445 (ss_seq = 305303, first block #48015360). Because I need to conclude what the reason of failure with checkpoint attach. I can see from code analysis that only raw dump can give to me more hints than additional debug output. As I can see, the most part of last partial segment is contained by metadata files. Of course, you can share raw dump privately only with me. I need to understand the metadata state only. > > Tomorrow, I prepare patch with additional debug output for > > deeper investigation of the issue on your side. > > Is there any chance to register a different fs aside with > "official" nilfs2? Would such a simple change be sufficient? > > diff -ur org/super.c new/super.c > --- org/super.c 2013-03-19 02:17:23.922469000 +0400 > +++ new/super.c 2013-03-19 02:16:20.440634698 +0400 > @@ -1356,7 +1356,7 @@ > > struct file_system_type nilfs_fs_type = { > .owner = THIS_MODULE, > - .name = "nilfs2", > + .name = "nilfs2-dbg", > .mount = nilfs_mount, > .kill_sb = kill_block_super, > .fs_flags = FS_REQUIRES_DEV, > > What I want is to whenever possible avoid rebooting a machine > I am using for experimentation. It has /home on a nilfs2 > partition and there're usually open user files on it. > I think that you can have more simple solution. I suggest to have special experimental build of the kernel that you can choose in the grub menu. Moreover, debug output will be completely disabled by means of #undef macro. Anyway, I need to analyze raw dump before offering to you a patch with additional debug output. Thanks, Vyacheslav Dubeyko. > Thanks and regards. > Alexander Bezrukov. > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
