Re: Bug : reuse same inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 8 Feb 2011 21:32:37 +0100, Philippe CHATAIGNON wrote:
> Le Tue, 08 Feb 2011 20:42:30 +0900 (JST),
> Ryusuke Konishi <ryusuke@xxxxxxxx> a écrit :
> 
> > Hi,
> > 
> > Thank you for the detail report!  It's really helpful.
> > 
> > I understood the zero link count inode was causing a chain reaction.
> > 
> > And the inode in question at cp15731 also seems to be overridden
> > because gid, size, and timestamp all differs from that file at
> > cp15730.
> > 
> > > cp15730
> > > -------
> > > mnt/snap5/cut:
> > > total 4
> > > 14 -rw-r--r-- 1 philippe 1000 47 25 janv. 22:33
> > > f5_20110125_202053.ts(0).Xcl
> > 
> > > cp15731
> > > -------
> > > mnt/snap7/cut:
> > > total 9223372036848683032
> > > 14 -rw-r--r-- 0 philippe users 6214528000 24 janv. 01:30
> > > f5_20110125_202053.ts(0).Xcl
> > 
> > Can't you find another file with the inode number 14 in the snapshot
> > cp15731 or cp15730 ?
> > 
> > I reviewed back unlink() implementation, but haven't found any issues
> > so far.  The problem may be rooted much deeper.
> > 
> > 'stat' command may give us much information than 'ls -l' in this case.
> 
> Hi,
> in my previous mail, ls -li ** give all the files in the filesystem (directory capture has inode 12 and cut 13). In
> cp15730 and cp15731, there's only one file with inode 14.

O.K. so, it seems like something happened at the checkpoint 15731
according to your information.

One thing wired is that the timestamp (mtime) looks to be rewinded
at cp15731.

>   File: « mnt/snap6/cut/f5_20110125_202053.ts(0).Xcl »
>   Size: 6214528000	Blocks: 18446744073697366064 IO Block: 4096   fichier
> Device: fe00h/65024d	Inode: 14          Links: 0
> Access: (0644/-rw-r--r--)  Uid: ( 1000/philippe)   Gid: (  100/   users)
> Access: 2011-01-24 01:30:02.260271565 +0100
> Modify: 2011-01-24 01:30:02.260271565 +0100
> Change: 2011-01-25 20:28:48.894851740 +0100

Do you have any ideas on this timestamp ?

Then, let's look back in a different perspective.

As you know, the lscp command displays the total number of inodes (ICNT).
Does it match the actual number of files and directories ?

Thanks,
Ryusuke Konishi

> Heres's the 3 stat outputs :
> philippe@micro11:~$ sudo mount -t nilfs2 -r -o cp=15730 /dev/mapper/vg11a-video mnt/snap5
> philippe@micro11:~$ sudo mount -t nilfs2 -r -o cp=15731 /dev/mapper/vg11a-video mnt/snap6
> philippe@micro11:~$ sudo mount -t nilfs2 -r -o cp=15732 /dev/mapper/vg11a-video mnt/snap7
> 
> philippe@micro11:~$ stat mnt/snap5/cut/f5_20110125_202053.ts\(0\).Xcl 
>   File: « mnt/snap5/cut/f5_20110125_202053.ts(0).Xcl »
>   Size: 47        	Blocks: 8          IO Block: 4096   fichier
> Device: fe00h/65024d	Inode: 14          Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/philippe)   Gid: ( 1000/ UNKNOWN)
> Access: 2011-01-25 22:33:34.914556435 +0100
> Modify: 2011-01-25 22:33:34.914556435 +0100
> Change: 2011-01-25 22:33:34.914556435 +0100
>  Birth: -
> 
> philippe@micro11:~$ stat mnt/snap6/cut/f5_20110125_202053.ts\(0\).Xcl
>   File: « mnt/snap6/cut/f5_20110125_202053.ts(0).Xcl »
>   Size: 6214528000	Blocks: 18446744073697366064 IO Block: 4096   fichier
> Device: fe00h/65024d	Inode: 14          Links: 0
> Access: (0644/-rw-r--r--)  Uid: ( 1000/philippe)   Gid: (  100/   users)
> Access: 2011-01-24 01:30:02.260271565 +0100
> Modify: 2011-01-24 01:30:02.260271565 +0100
> Change: 2011-01-25 20:28:48.894851740 +0100
>  Birth: -
> 
>   File: « mnt/snap7/cut/f5_20110125_202053.ts(0).Xcl »
>   Size: 0         	Blocks: 0          IO Block: 4096   fichier vide
> Device: fe00h/65024d	Inode: 14          Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1000/philippe)   Gid: (  100/   users)
> Access: 2011-01-29 18:19:51.719138031 +0100
> Modify: 2011-01-29 18:19:51.719138031 +0100
> Change: 2011-01-29 18:19:51.719138031 +0100
>  Birth: -
> 
> PhC
> --
> 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


[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux