(anonymous) wrote: > [...]
> FWIW, the inode numbers are consecutive (but I don't know if > they are real of faked): >> platonides@tools-login:/data/project/geograph2commons$ stat * >> File: `access.log' >> Size: 242241 Blocks: 480 IO Block: 8192 regular file >> Device: 1ch/28d Inode: 33523251 Links: 1 >> Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: >> (50543/local-geograph2commons) >> Access: 2013-07-01 17:03:21.362360427 +0000 >> Modify: 2013-07-23 10:23:13.028532144 +0000 >> Change: 2013-07-23 10:23:13.028532144 +0000 >> Birth: - >> File: `cgi-bin' >> Size: 0 Blocks: 0 IO Block: 8192 regular empty file >> Device: 1ch/28d Inode: 33523252 Links: 1 >> Access: (0644/-rw-r--r--) Uid: ( 1090/russblau) Gid: ( 550/ svn) >> Access: 2013-07-01 17:03:21.362360427 +0000 >> Modify: 2013-04-16 18:38:09.000000000 +0000 >> Change: 2013-08-12 15:07:28.685378243 +0000 >> Birth: - > [...] To me, this suggests the corruption was present prior to the XFS -> ext4 copying. Otherwise, cgi-bin would have been created prior to access.log and thus (/probably/) have a lower inode number. So, I think this is residue of the XFS error we have seen earlier and not something new. Tim _______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
