[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegtLsnDFwMFMMxUf2yUcr2AG57PgUZSAR7M8gzbOEp16Mg@mail.gmail.com>
Date: Thu, 27 Jul 2017 21:36:20 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Tahsin Erdogan <tahsin@...gle.com>
Cc: "Theodore Ts'o" <tytso@....edu>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>
Subject: Re: xattr hash error in 4.13-rc with overlayfs over ext4
On Thu, Jul 27, 2017 at 9:28 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Thu, Jul 27, 2017 at 8:20 PM, Tahsin Erdogan <tahsin@...gle.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
Powered by blists - more mailing lists