Re: Question regarding internals of metacopy=on feature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Apr 15, 2024 at 4:16 PM Yuriy Belikov <yuriybelikov1@xxxxxxxxx> wrote:
> 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.

Hi Yuri,

It is a regular file that contains no data (a.k.a sparse file) with an
xattr “trusted.overlay.metacopy” that is used
as an indication that this upper file contains no data and that data
copy-up should still be performed
before the overlayfs file is opened for write.

Patches to clarify the documentation are welcome:


[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux