Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1697941 > unrolled thread

xattr hash error in 4.13-rc with overlayfs over ext4

Back to article view | Back to linux.kernel

Contents

  xattr hash error in 4.13-rc with overlayfs over ext4 Miklos Szeredi <miklos@szeredi.hu> - 2017-07-27 14:40 +0200
    Re: xattr hash error in 4.13-rc with overlayfs over ext4 Tahsin Erdogan <tahsin@google.com> - 2017-07-27 20:30 +0200
      Re: xattr hash error in 4.13-rc with overlayfs over ext4 Miklos Szeredi <miklos@szeredi.hu> - 2017-07-27 21:30 +0200
        Re: xattr hash error in 4.13-rc with overlayfs over ext4 Miklos Szeredi <miklos@szeredi.hu> - 2017-07-27 21:40 +0200
          Re: xattr hash error in 4.13-rc with overlayfs over ext4 Tahsin Erdogan <tahsin@google.com> - 2017-07-27 23:00 +0200

#1697941 — xattr hash error in 4.13-rc with overlayfs over ext4

I get the following error on fsck:

Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 3093 has a hash (2257320705) which is invalid
Clear<y>? yes
Inode 3093, i_blocks is 16, should be 8.  Fix<y>? yes

To reproduce:

[mount ext4 image]
mkdir xattrhashtest
cd xattrhashtest/
mkdir upper lower work mnt
cd lower/
echo foo > bar
ln bar baz
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work mnt
cd mnt/
echo xxx >> bar
[umount and fsck]

Reverting commit daf8328172df ("ext4: eliminate xattr entry e_hash
recalculation for removes") fixes it.

Might be an ext4 or overlayfs bug.  Let me know what you think.

Thanks,
Miklos

[toc] | [next] | [standalone]

#1698235

Hi Miklos,
I made a first attempt to reproduce the failure but did not get lucky.

> Inode 3093, i_blocks is 16, should be 8.  Fix<y>? yes
Does this inode correspond to foo, bar or a preexisting file?

Do you mind sharing the output of the following command?
debugfs -R "stat <3093>" /dev/${ext4_dev}

thanks

[toc] | [prev] | [next] | [standalone]

#1698264

On Thu, Jul 27, 2017 at 8:20 PM, Tahsin Erdogan <tahsin@google.com> wrote:
> Hi Miklos,
> I made a first attempt to reproduce the failure but did not get lucky.
>
>> Inode 3093, i_blocks is 16, should be 8.  Fix<y>? yes
> Does this inode correspond to foo, bar or a preexisting file?
>
> Do you mind sharing the output of the following command?
> debugfs -R "stat <3093>" /dev/${ext4_dev}

Inode: 17093   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 2184376062    Version: 0x00000000:00000001
User:     0   Group:     0   Project:     0   Size: 8
File ACL: 65561    Directory ACL: 0
Links: 2   Blockcount: 16
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x597a3e23:7d3fc138 -- Thu Jul 27 19:25:23 2017
 atime: 0x597a3dfc:a80bc138 -- Thu Jul 27 19:24:44 2017
 mtime: 0x597a3e23:7d3fc138 -- Thu Jul 27 19:25:23 2017
crtime: 0x597a3e23:787b0938 -- Thu Jul 27 19:25:23 2017
Size of extra inode fields: 32
EXTENTS:
(0):142340

Resulting fsck output:

Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 17093 has a hash (2257320705) which is invalid
Clear<y>? yes
Inode 17093, i_blocks is 16, should be 8.  Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -65561
Fix<y>? yes
Free blocks count wrong for group #2 (13797, counted=13798).
Fix<y>? yes
Free blocks count wrong (86361, counted=86362).
Fix<y>? yes

[toc] | [prev] | [next] | [standalone]

#1698269

On Thu, Jul 27, 2017 at 9:28 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Thu, Jul 27, 2017 at 8:20 PM, Tahsin Erdogan <tahsin@google.com> wrote:
>> Hi Miklos,
>> I made a first attempt to reproduce the failure but did not get lucky.
>>
>>> Inode 3093, i_blocks is 16, should be 8.  Fix<y>? yes
>> Does this inode correspond to foo, bar or a preexisting file?

The inode in question corresponds to the copy-up of bar into upper.

There's quite a lot overlayfs does in this apparently simple
operation, and that's probably why I've not been able to reproduce
without overlayfs (although admittedly I didn't try very hard).

It's basically the following:

 - create tempfile
 - copy data from lower/bar to work/index/XXX  using reflink
 - copy metadata
 - set trusted.overlay.origin xattr
 - set trusted.overlay.nlink xattr
 - hardlink index file to upper/bar
 - overwrite trusted.overlay.nlink with different value

And ther's also some attr and xattr setting going on for the upper directory.

Thanks,
Miklos

[toc] | [prev] | [next] | [standalone]

#1698315

Still no luck reproducing the error. I am using the test script below
at v4.13-rc2. Do you mind checking my script to see what I am missing?

#!/bin/bash
set -ex

while grep /dev/sdb /proc/mounts;do umount /dev/sdb; done
mke2fs -F -t ext4 /dev/sdb
mount /dev/sdb /mnt/sdb
cd /mnt/sdb

mkdir xattrhashtest
cd xattrhashtest/
mkdir upper lower work mnt
cd lower/
echo foo > bar
ln bar baz
cd ..
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work mnt
cd mnt/
echo xxx >> bar

cd /root
umount overlay
umount /dev/sdb

e2fsck -f -n /dev/sdb
echo done

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web