linux-unionfs mirror
 help / color / mirror / Atom feed
From: Yuriy Belikov <yuriybelikov1@gmail.com>
To: linux-unionfs@vger.kernel.org
Subject: Question regarding internals of metacopy=on feature
Date: Mon, 15 Apr 2024 15:55:08 +0300	[thread overview]
Message-ID: <29C3102E-08CC-43D6-BCC0-2CA588A3C5B1@gmail.com> (raw)

Dear UnionFS team,

My name is Yuriy, and I am currently an intern at CERN, working on the CernVM Filesystem (CVMFS) project. Our objective is to enhance the performance of the cvmfs_server utility, which is crucial for publishing file updates. Given that CVMFS fundamentally relies on union filesystems, we are exploring various features of OverlayFS to achieve this, specifically considering the metacopy=on option.

I have encountered a scenario that is not explicitly covered in the OverlayFS documentation: If metadata (e.g., permissions set by chmod) are modified for a file that exists only in the lower-layer (and thus appears in the union directory but not in the upper-layer), what is the type of the filesystem object in the upper layer under these conditions? From preliminary tests with metacopy=on, it appears that such files are visible in the terminal using the ls command. However, as there were no modifications to the file content, a copy-up was not triggered. This leads to my question about the type of filesystem object represented in the upper-layer directory when only metadata is modified.  


I would greatly appreciate any clarification or additional documentation you could provide regarding this matter.


Best regards,  
Yuriy Belikov

             reply	other threads:[~2024-04-15 12:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 12:55 Yuriy Belikov [this message]
2024-04-15 13:27 ` Question regarding internals of metacopy=on feature Amir Goldstein
2024-04-15 13:37 ` Miklos Szeredi

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=29C3102E-08CC-43D6-BCC0-2CA588A3C5B1@gmail.com \
    --to=yuriybelikov1@gmail.com \
    --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 read-only IMAP folder(s) and NNTP newsgroup(s).