* invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again
@ 2016-06-08 11:16 Nigel Tamplin
2016-06-08 11:49 ` Carlos Maiolino
0 siblings, 1 reply; 3+ messages in thread
From: Nigel Tamplin @ 2016-06-08 11:16 UTC (permalink / raw)
To: xfs
Hello,
I have a drive with a partition containing an XFS file system.
This drive normally resides in a Linux 2.6.32 (Debian 6) server, which
is also where the file system was created many months ago.
Last week I removed this drive from it's usual 2.6.32 server and for a
few hours it was attached to an alternative Linux 3.16.0 (Debian 8)
server, where the XFS file system was mounted and during this time I
created /modified / deleted some files.
Later the drive was moved back to the normal Linux 2.6.32.
I've noticed something strange has happened.
Some (maybe all) of the files worked on whilst the drive was in the
Linux 3.16.0 are not accessible when the file system is mounted on the
Linux 2.6.32.
If I put the drive back in the 3.16.0 server, all files are again
accessible.
The few files which are inaccessible on 2.6.32 seem to have no inodes
when viewed under 2.6.32 but look ok when the drive is in 3.16.0
"ls -li" on 3.16.0
7249604387 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 01
104207 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 02
101524 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 03
2220005080 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 06
5637828101 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 07
1344499710 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 09
2958135019 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 0b
7516254020 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 0c
5905580833 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 0f
3494120096 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 10
1988369908 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 12
2446706848 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 13
2446706832 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 14
5905580836 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 16
807056393 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 17
2688006922 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 18
"ls -li" on 2.6.32
? ?????????? ? ? ? ? ? 01
104207 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 02
101524 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 03
2220005080 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 06
? ?????????? ? ? ? ? ? 07
1344499710 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 09
2958135019 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 0b
? ?????????? ? ? ? ? ? 0c
? ?????????? ? ? ? ? ? 0f
3494120096 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 10
1988369908 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 12
2446706848 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 13
2446706832 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 14
? ?????????? ? ? ? ? ? 16
807056393 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 17
2688006922 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 18
I notice that the files created on 3.16.0 which cannot be accessed on
2.6.32, seem to have much higher inode numbers than those which can be
accessed on both systems. Could the numbers chosen by 3.16.0 be
overflowing on 2.6.32 ? I experimented on another almost empty file
system, and this seems fine in both systems, but this has very low inode
numbers, hence my inode number idea.
I can attach the drive to either system and run diagnostic commands if
more information is required.
Regards,
Nigel
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again
2016-06-08 11:16 invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again Nigel Tamplin
@ 2016-06-08 11:49 ` Carlos Maiolino
2016-06-08 12:31 ` Nigel Tamplin
0 siblings, 1 reply; 3+ messages in thread
From: Carlos Maiolino @ 2016-06-08 11:49 UTC (permalink / raw)
To: Nigel Tamplin; +Cc: xfs
On Wed, Jun 08, 2016 at 12:16:10PM +0100, Nigel Tamplin wrote:
> Hello,
>
> I have a drive with a partition containing an XFS file system.
> This drive normally resides in a Linux 2.6.32 (Debian 6) server, which is
> also where the file system was created many months ago.
> Last week I removed this drive from it's usual 2.6.32 server and for a few
> hours it was attached to an alternative Linux 3.16.0 (Debian 8) server,
> where the XFS file system was mounted and during this time I created
> /modified / deleted some files.
> Later the drive was moved back to the normal Linux 2.6.32.
>
Linux 3.16 has inode64 mount option enabled by default, which will cause inodes
to be spread along the whole disk, causing some inodes (those allocated on disk
blocks beyond 1TB offset) to have 64bit numbers.
2.6.32 doesn't use inode64 option by default, and so, files with inodes > 2^32
will not be accessible by the kernel 2.6.32, but, you can use `mount -o inode64`
mount option in the old system and then be able to access these inodes again.
> I've noticed something strange has happened.
> Some (maybe all) of the files worked on whilst the drive was in the Linux
> 3.16.0 are not accessible when the file system is mounted on the Linux
> 2.6.32.
>
> If I put the drive back in the 3.16.0 server, all files are again
> accessible.
>
> The few files which are inaccessible on 2.6.32 seem to have no inodes when
> viewed under 2.6.32 but look ok when the drive is in 3.16.0
>
>
> "ls -li" on 3.16.0
>
> 7249604387 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 01
> 104207 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 02
> 101524 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 03
> 2220005080 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 06
> 5637828101 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 07
> 1344499710 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 09
> 2958135019 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 0b
> 7516254020 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 0c
> 5905580833 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 0f
> 3494120096 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 10
> 1988369908 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 12
> 2446706848 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 13
> 2446706832 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 14
> 5905580836 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 16
> 807056393 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 17
> 2688006922 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 18
>
>
> "ls -li" on 2.6.32
>
> ? ?????????? ? ? ? ? ? 01
> 104207 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 02
> 101524 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 03
> 2220005080 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 06
> ? ?????????? ? ? ? ? ? 07
> 1344499710 drwxrwxr-x 2 nigel users 118 Jun 2 16:40 09
> 2958135019 drwxrwxr-x 2 nigel users 62 Jun 2 16:39 0b
> ? ?????????? ? ? ? ? ? 0c
> ? ?????????? ? ? ? ? ? 0f
> 3494120096 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 10
> 1988369908 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 12
> 2446706848 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 13
> 2446706832 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 14
> ? ?????????? ? ? ? ? ? 16
> 807056393 drwxrwxr-x 2 nigel users 4096 Jun 2 16:40 17
> 2688006922 drwxrwxr-x 2 nigel users 62 Jun 2 16:40 18
>
>
> I notice that the files created on 3.16.0 which cannot be accessed on
> 2.6.32, seem to have much higher inode numbers than those which can be
> accessed on both systems. Could the numbers chosen by 3.16.0 be overflowing
> on 2.6.32 ? I experimented on another almost empty file system, and this
> seems fine in both systems, but this has very low inode numbers, hence my
> inode number idea.
>
> I can attach the drive to either system and run diagnostic commands if more
> information is required.
>
> Regards,
> Nigel
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again
2016-06-08 11:49 ` Carlos Maiolino
@ 2016-06-08 12:31 ` Nigel Tamplin
0 siblings, 0 replies; 3+ messages in thread
From: Nigel Tamplin @ 2016-06-08 12:31 UTC (permalink / raw)
To: Carlos Maiolino; +Cc: xfs
On 08/06/16 12:49, Carlos Maiolino wrote:
> On Wed, Jun 08, 2016 at 12:16:10PM +0100, Nigel Tamplin wrote:
>> Hello,
>>
>> I have a drive with a partition containing an XFS file system.
>> This drive normally resides in a Linux 2.6.32 (Debian 6) server, which is
>> also where the file system was created many months ago.
>> Last week I removed this drive from it's usual 2.6.32 server and for a few
>> hours it was attached to an alternative Linux 3.16.0 (Debian 8) server,
>> where the XFS file system was mounted and during this time I created
>> /modified / deleted some files.
>> Later the drive was moved back to the normal Linux 2.6.32.
>>
>
> Linux 3.16 has inode64 mount option enabled by default, which will cause inodes
> to be spread along the whole disk, causing some inodes (those allocated on disk
> blocks beyond 1TB offset) to have 64bit numbers.
>
> 2.6.32 doesn't use inode64 option by default, and so, files with inodes > 2^32
> will not be accessible by the kernel 2.6.32, but, you can use `mount -o inode64`
> mount option in the old system and then be able to access these inodes again.
>
Excellent explanation Carlos.
This exactly explains what had happened, the partition being moved
between systems is 2TB in size.
As you suggested, remounting on the older systems with option inode64
resolved it.
Thank you.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-06-08 12:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-08 11:16 invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again Nigel Tamplin
2016-06-08 11:49 ` Carlos Maiolino
2016-06-08 12:31 ` Nigel Tamplin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox