From: L A Walsh <lkml@tlinx.org>
To: linux-unionfs@vger.kernel.org
Subject: Bug? or normal behavior? if bug, then where? overlay, vfs, xfs, or ????
Date: Wed, 01 Nov 2017 15:03:05 -0700 [thread overview]
Message-ID: <59FA4499.2030502@tlinx.org> (raw)
Trying the overlay fs for first time and am wondering about normal behavior.
After modifying file 'noise' and deleting "file1" in a merged directory, I
get:
> ls -lgG
ls: cannot access 'file1': No such file or directory
total 26858576
?????????? ? ? ? file1
-rwxrwxr-x 1 9167721042 Oct 4 09:45 file2*
-rwxrwxr-x 1 9167721042 Oct 5 20:09 file3*
-rwxrwxr-x 1 9167721042 Nov 13 2011 file4*
-rwxrwxr-x 1 496 Oct 28 15:13 noise*
-rwxrwxr-x 1 452 Oct 5 20:08 noise.orig*
drwxrwxr-x 2 18 Oct 4 09:41 src/
I'm a bit concerned about the "white-out" for "file1".
Is this how it is supposed to appear? Should I file
a bug in the kernel's bugzilla-db?
How I got here:
My kernel from "uname -a" is:
Linux Ishtar 4.13.9-Isht-Van #1 SMP Thu Oct 26 16:41:08 PDT 2017 x86_64
GNU/Linux
I used a pre-existing directory "/local/test" as a 'lower':
> /bin/ls -lgGR /local/test
/local/test:
total 35811432
-rwxrwxr-x 1 9167721042 Nov 13 2011 file1
-rwxrwxr-x 1 9167721042 Oct 4 09:45 file2
-rwxrwxr-x 1 9167721042 Oct 5 20:09 file3
-rwxrwxr-x 1 9167721042 Nov 13 2011 file4
-rwxrwxr-x 1 452 Oct 5 20:08 noise
-rwxrwxr-x 1 420 Oct 5 19:57 noise.orig
drwxrwxr-x 2 18 Oct 4 09:41 src
/local/test/src:
total 8952856
-rwxrwxr-x 1 9167721042 Nov 13 2011 file1
in a pre-existing 'xfs' file system:
> xfs_info /local/test
meta-data=/dev/Data/Local isize=256 agcount=32,
agsize=12582896 blks = sectsz=4096 attr=2
data = bsize=4096 blocks=402652672,imaxpct=10
= sunit=16 swidth=16 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=32768, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
I then created a new xfs file system and mounted it on '/edge';
Ishtar:/edge> xfs_info .
meta-data=/dev/Data/Edge isize=256 agcount=32,
agsize=16777200 blks = sectsz=4096 attr=2
data = bsize=4096 blocks=536870400, imaxpct=5
= sunit=16 swidth=64 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=262143, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
created directories in it;
> cd /edge
> mkdir merged overlays overlays/upper work
and mounted an overlay fs on "/edge/merged" with:
sudo mount -t overlay none -olowerdir=/local/test,\
upperdir=/edge/overlays/upper,\
workdir=/edge/work /edge/merged
After editing 'noise' and removing 'file1', I got the listing
at the top. The 'file1' in the top listing can't be deleted.
It is only present/visible in the 'merged' directory, but
does seem to make the "overlayfs" unusable for general
purposes, so I'm guessing it's a bug?
Of note: a **likely** Red-Herring, is this RH bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1319507
(I say red-herring, as I'm not using RH, and there is
no real data in the bug other than similar symptoms
running over xfs).
BTW -- is the setup in that bug report even "valid"? I.e. using
the same single-underlying file system for all 4 directories?
Thanks!
-linda
next reply other threads:[~2017-11-01 22:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 22:03 L A Walsh [this message]
2017-11-02 7:03 ` Bug? or normal behavior? if bug, then where? overlay, vfs, xfs, or ???? Amir Goldstein
2017-11-02 21:57 ` L A Walsh
2017-11-03 6:45 ` Amir Goldstein
2017-11-05 8:17 ` L A Walsh
2017-11-05 8:55 ` Amir Goldstein
2017-11-05 22:34 ` Dave Chinner
2017-11-08 21:21 ` L A Walsh
2017-11-09 1:47 ` Dave Chinner
2017-11-09 7:51 ` L A Walsh
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=59FA4499.2030502@tlinx.org \
--to=lkml@tlinx.org \
--cc=linux-unionfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).