From: Atom2 <ariel.atom2@web2web.at>
To: linux-unionfs@vger.kernel.org
Subject: stat inconsistency with overlayfs
Date: Fri, 20 Feb 2015 19:15:23 +0100 [thread overview]
Message-ID: <54E779BB.8030209@web2web.at> (raw)
I am using find with its printf "%D" option (provides the same
information as stats device information "%d" - device number in decimal)
to figure out whether a file system entry resides in the r/o lowerdir or
the r/w upperdir of an overlayfs mounted filesystem. I distinguish
between the two by getting the device number from a (plain) file know to
be in the upperdir.
The use case behind that is to be able to backup only files from the
upperdir for several systems sharing a common lowerdir filesystem. I
have used that (scripted approach via rsync) now for quiet some time and
a few kernels back and it seemed to have worked very well.
Currently I am using kernel 3.17.7 on gentoo and I seem to observe a
strange behaviour (which I do not recall to have seen before on 3.13 and
3.11) with my approach as follows:
.) plain files still work and the device number is correct
.) directories, however, always seem to reside in the lowerdir - even
thoguh they do not exist there; in fact there's not a single file in the
whole filesystem hierarchy that, according to stat/find, seems to reside
in the upperdir:
please see the stat output for a file and a directory, both residing in
the same (parent) directory which is completely located in the upperdir
(and does not at all exist in the lowerdir):
# stat serial
File: ‘serial’
Size: 17 Blocks: 8 IO Block: 4096 regular file
Device: ca03h/51715d Inode: 88 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-02-19 19:01:56.278161346 +0100
Modify: 2014-02-19 19:01:56.278161346 +0100
Change: 2014-02-19 19:01:56.278161346 +0100
Birth: -
#
# stat certs/
File: ‘certs/’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: dh/13d Inode: 331140 Links: 2
Access: (0700/drwx------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-04-26 14:08:47.337968562 +0200
Modify: 2014-02-19 18:55:58.458161346 +0100
Change: 2014-02-19 18:55:58.458161346 +0100
Birth: -
For comparision, please see the stat of /bin which only resides in the
lowerdir and does not exist in the upperdir:
# stat /bin
File: ‘/bin’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: dh/13d Inode: 401777 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-02-20 17:50:24.066368607 +0100
Modify: 2015-02-09 17:51:18.000000000 +0100
Change: 2015-02-09 23:58:06.011825328 +0100
Birth: -
I do not think that this is the expected behaviour and I am pretty
confident that this was different on older kernels - or am I missing
anything/doing anything wrong here?
Thanks and regards Atom2
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2015-02-20 18:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 18:15 Atom2 [this message]
2015-02-26 5:25 ` stat inconsistency with overlayfs hujianyang
2015-02-26 6:45 ` Xu Wang
2015-03-02 20:45 ` Atom2
2015-03-03 15:14 ` Miklos Szeredi
2015-03-03 17:12 ` Atom2
2015-03-04 2:24 ` hujianyang
2015-03-04 11:06 ` Miklos Szeredi
2015-03-02 20:45 ` Atom2
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=54E779BB.8030209@web2web.at \
--to=ariel.atom2@web2web.at \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.