From: Carlos Maiolino <cmaiolino@redhat.com>
To: Nigel Tamplin <ntamplin@codefaber.co.uk>
Cc: xfs@oss.sgi.com
Subject: Re: invalid inode numbers ? after drive moved from Linux 2.6.32 to Linux 3.16.0 then back again
Date: Wed, 8 Jun 2016 13:49:07 +0200 [thread overview]
Message-ID: <20160608114907.GC8987@redhat.com> (raw)
In-Reply-To: <5757FE7A.8020504@codefaber.co.uk>
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
next prev parent reply other threads:[~2016-06-08 11:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2016-06-08 12:31 ` Nigel Tamplin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160608114907.GC8987@redhat.com \
--to=cmaiolino@redhat.com \
--cc=ntamplin@codefaber.co.uk \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox