I''m using BTRFS_DIR_INDEX_KEY as suggested by Chris to find all updated directories. But I''m missing one: The directory has 3 entries deleted and stat shows different mtimes and ctimes for the directory in the two snapshots. The highest generation number in the older snapshot is 82623. But the generation number of the updated directory is 31758 in both snapshots. Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 27 March 2010, Dipl.-Ing. Michael Niederle wrote:> I''m using BTRFS_DIR_INDEX_KEY as suggested by Chris to find all updated > directories. > > But I''m missing one: > > The directory has 3 entries deleted and stat shows different > mtimes and ctimes for the directory in the two snapshots. > > The highest generation number in the older snapshot is 82623. > > But the generation number of the updated directory is 31758 in bothsnapshots.>I am not an export of the internal btrfs structure, but reading btrfs-print.c it seems to me: - the mtimes and ctimes are stored in the INODE_ITEM; - the INODE_ITEM has an own generator - the DIR_INDEX doesn''t have a own generator; they store only the filename, so it may be not updated if the inode is updated. - On the basis of what Chris said, it seems that the generator for this kind of object (DIR_INDEX) is the generator of the block which may included other changes.. The notes above may explain the observed behaviour. But these are only my hypothesis. Goffredo> Greetings, Michael > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Goffredo! I checked all btrfs-item types (changed sk->max_type to 255 and removed the filtering) connected with the updated directory''s inode. But none of them had got a new generation number. I found the missing directory only using a more conventional tool that checked all files and directories in both snapshots. Here the output from stat:>stat 2010-03-21/root/.googleearth/Temp/.kmztmp/File: `2010-03-21/root/.googleearth/Temp/.kmztmp/'' Size: 21340 Blocks: 0 IO Block: 4096 directory Device: 15h/21d Inode: 31757 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-02-19 22:12:25.339932662 +0100 Modify: 2009-11-18 13:45:52.000000000 +0100 Change: 2010-01-12 19:48:01.911913031 +0100>stat 2010-03-22/root/.googleearth/Temp/.kmztmp/File: `2010-03-22/root/.googleearth/Temp/.kmztmp/'' Size: 21268 Blocks: 0 IO Block: 4096 directory Device: 16h/22d Inode: 31757 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-02-19 22:12:25.339932662 +0100 Modify: 2010-03-21 21:49:16.512553912 +0100 Change: 2010-03-21 21:49:16.512553912 +0100 Greetings, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michael, it seems that the generation number of an inode is the generation number at creation time of the inode. I fear that even though is possible to detect an extent update, looking at the generation number, it is impossible to detect a inode update. Chris, could help us to understand better that ? Thanks BR Goffredo On Saturday 27 March 2010, Dipl.-Ing. Michael Niederle wrote:> Hi, Goffredo! > > I checked all btrfs-item types (changed sk->max_type to 255 and removed the > filtering) connected with the updated directory''s inode. > > But none of them had got a new generation number. > > I found the missing directory only using a more conventional tool thatchecked> all files and directories in both snapshots. > > Here the output from stat: > > >stat 2010-03-21/root/.googleearth/Temp/.kmztmp/ > File: `2010-03-21/root/.googleearth/Temp/.kmztmp/'' > Size: 21340 Blocks: 0 IO Block: 4096 directory > Device: 15h/21d Inode: 31757 Links: 1 > Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2010-02-19 22:12:25.339932662 +0100 > Modify: 2009-11-18 13:45:52.000000000 +0100 > Change: 2010-01-12 19:48:01.911913031 +0100 > > >stat 2010-03-22/root/.googleearth/Temp/.kmztmp/ > File: `2010-03-22/root/.googleearth/Temp/.kmztmp/'' > Size: 21268 Blocks: 0 IO Block: 4096 directory > Device: 16h/22d Inode: 31757 Links: 1 > Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 2010-02-19 22:12:25.339932662 +0100 > Modify: 2010-03-21 21:49:16.512553912 +0100 > Change: 2010-03-21 21:49:16.512553912 +0100 > > Greetings, Michael > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html