Amir Goldstein wrote:
Whiteout certainly shouldn't appear that way.
(thank goodness!)
The reason it does is that your upper fs does not support
"d_type" (see below).
It's a "known" issue, but don't know where/if it is documented.
I expect if you look in dmesg, you will see this warning:
"overlayfs: upper fs needs to support d_type."
----
Yup...found that.
We also do not check for lower fs d_type support.
That can also expose old whiteouts in certain setups.
----
*ouch*. I wonder if d_type can be set for existing file systems.
I easily have some file systems that date back more than a few years.
I then created a new xfs file system and mounted it on '/edge';
Ishtar:/edge> xfs_info ....
naming =version 2 bsize=4096 ascii-ci=0
Your problem is that you do not have "ftype" feature in directory
name format, like this:
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
---
My mkfs.xfs is a few (3) years old.
Perhaps you have an old version of mkfs.xfs, not sure when
ftype=1 became the default format, but you can try to
mkfs.xfs -n ftype=1
and follow the breadcrumbs from there.
...
BTW -- is the setup in that bug report even "valid"? I.e. using
the same single-underlying file system for all 4 directories?
Yes. Actually your setup uses 2 different file system instances
for lower and upper, which is fine, but it is perfectly valid, quite
common and even has some advantages to use upper/lower
on the same underlying filesystem instance.
----
I was referring to the RH bug report where they had created
everything on 1 FS. I wondered about upper+lower overlap problems
on the same fs. I'd think that could get a bit tangled
Thanks... will look for a newer mkfs.xfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
