All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.