On Sun, Apr 6, 2025 at 3:35 AM Magnus Askholm wrote: > > Some places, I see people say, that nilfs is a copy-on-write filesystem. > But when I try to copy a file inside nilfs, using reflinks, this happens: > > $ cp --reflink=always README.txt README2.txt > cp: failed to clone 'README2.txt' from 'README.txt': Operation not supported > > Normal copying works fine: > $ cp --reflink=never README.txt README2.txt > > So it looks like nilfs doesn't support copy-on-write, where you can copy > a file > without using extra space. E.g. copying a 5 GB file won't take 5 GB of > free space. > > Is this a bug or just a missing feature, that could be implemented in > the future? Thank you for your interest. In conclusion, this is not a bug, and nilfs does not currently support reflink. Reflink is a feature that allows file block areas to be shared on a block device, enabling copy-on-write on a per-file basis. It is a new form of copy-on-write implemented by slightly extending the file system interface. Nilfs is a copy-on-write file system, but its mechanism is based on a legacy method called a log-structured file system, which does not overwrite any existing blocks in the file system but appends them in the underlying block device, leaving a history of files and namespaces. (With nilfs, you can mount past snapshots of a file system as read-only mounts by specifying checkpoint numbers listed by the lscp command of nilfs-utils.) I think reflink is an excellent and useful feature, but nilfs' current design (format and on-memory structure) does not allow sharing of part of a file's block area between multiple files (inodes) that exist simultaneously, so we have not added the feature and there are no plans to implement it in the near future. The current design of nilfs' block management has various design flaws, such as inability to implement such shared structures, the inability to support the extent method for efficiently managing large files, and the degradation of I/O performance due to an increase in the number of indirect references. I would like to improve these flaws by replacing the design. However, this requires a certain amount of development effort, which is difficult at the moment when we need to focus on maintenance, so I'm sorry, but please understand that it is difficult to support it in the near future due to design bottlenecks. Thanks, Ryusuke Konishi
