Missing entry for updated directory

Missing entry for updated directory

[Dipl.-Ing. Michael Niederle]

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

Re: Missing entry for updated directory

[Goffredo Baroncelli]

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 both 
snapshots.
> 


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

Re: Missing entry for updated directory

[Dipl.-Ing. Michael Niederle]

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

Re: Missing entry for updated directory

[Goffredo Baroncelli]

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 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
> 


-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512